Integrity protection of fetches

[Steve Bonneville]

i.grok at 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