VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30

[Tomas Mraz]

On Wed, 2011-10-12 at 18:17 -0400, Paul Wouters wrote: 
> On Wed, 12 Oct 2011, Tomas Mraz wrote:
> 
> > Except nobody says or said that DNS without DNSSEC leads to the
> > automatic connection with such setting.
> 
> I answered that multiple times, including today with a vast amount of screen pasting
> into https://bugzilla.redhat.com/show_bug.cgi?id=180277 to show you that
> DNS without DNSSEC does NOT lead to automatic connection in ANY case other then
> you already having the key in known_hosts, which is the same behaviour as without
> any SSHFP record in DNS.

You seem to not understand that NEVER said that DNS without DNSSEC leads
to automatic connection with the setting. That is not and never was the
problem. You're just repeating things I know and knew at that time very
well.

> > The objection (upstream one that
> > is) is that setting VerifyHostKeyDNS yes ultimately sets you to depend
> > on the DNSSEC security for your SSH connection security
> 
> It does not add any new dependancies. If there is no DNSSEC, you are told the SSHFP
> is in the DNS, shown the fingerprint like there is no SSHFP record, and asked if
> you really want to continue. If there is DNSSEC, no entries to known_hosts are added
> so whenever DNSSEC is not there, you fall back to exactly what you have now.
> 
> Also, ssh already "depends" on DNSSEC to get a trustworth A/AAAA record with an RRSIG
> from DNSSEC. The dependancy is there whether upstream likes it or not.

Nope, you do not understand what the dependency is. Of course you depend
on the DNS to not be compromised to get the IP address of the host but
you still can verify the fingerprint on the first connection if you got
it by other means. And in case you already have it in known_hosts it
will explicitly disallow connection if the DNS gives you false answer
and you'll connect to a different host. With 'VerifyHostKeyDNS yes' if
there is a malicious DNS administrator, you will not have a chance to
verify the fingerprint, you will be directly connected to a false server
immediately compromising your password if password auth is used. And if
this malicious DNS administrator controls the caching nameserver you're
using for DNS queries, he can present you ANY data even 'valid' fake
DNSSEC data.

> > and that is
> > something we will never make default if upstream does not.
> 
> If upstream deems this so bad, why does upstream offer the option? I don't see them
> offering 1des or rot13 cipher either. Apparently, upstream is somewhat divided?
> 
> > Setting it to 'VerifyHostKeyDNS ask' by default is another matter and I
> > am OK with that.
> 
> Thank you, it's good enough for me and a happy end of a 5 year old bug.
Feature request that is. And a change that is not to be taken lightly.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb