i.grok(a)comcast.net wrote:
openssh is more paranoid than that. An unsigned, unvalidated SSHFP
record will be treated just like the server response is today -- the
user will be shown the fingerprint and asked if it's correct.
Only if the response is marked with the AD flag (indicating that the
resolver has checked the signature and it's ok) does openssh trust it
automatically. I know this because I've tried all three: unsigned,
signed but no AD flag on the response, signed with AD flag.
If you really want to argue about security, I'll point out that this
isn't completely bulletproof the way Fedora works today. The host (your
computer) runs a stub resolver that communicates with the recursive DNS
server (typically another computer) over an unauthenticated connection.
The stub resolver trusts the recursive resolver to only set the AD flag
in its response when the answer is trusted, and to not set it when it's
not. If you're talking directly to the authoritative nameserver, it's
not allowed to validate its own response, so it'll never set the AD
flag.
Well, it's the authoritative server; if you trust it to tell you if
something is AD or not, you should trust it if it says it's AA for
something. That having been said, except for stuff like localhost,
why is your recursive nameserver authoritative for anything? :)
Ideally (from this perspective), the host would validate the response
itself.
Exactly, if sshd is sufficiently paranoid it should make a query with
CD set in the request and do all the validation client-side. If you let
your nameserver do the validation, I think it's still possible to MITM
this by messing with the communication between the stub resolver and the
name server, which isn't secured.
-- Steve