Re: Fixing exchange of host keys in the SSH key exchange

["denis bider \(Bitvise\)" <ietf-ssh3%denisbider.com@localhost>]

Peter:


> https://www.usenix.org/system/files/login/articles/
> 105484-Gutmann.pdf

This article is actually a strong argument in favor of Expect-Key, or 
something like it.

What you found is NOT that people use TOFU (Trust On First Use). They use 
TWAT - Trust Whatever, Any Time:


> I asked the IT support staff how many users had called
> or emailed to verify the SSH server key whenever it had
> changed in the past several years. They were unable to
> recall a single case, or locate any records, of any user
> ever verifying any SSH server key out-of-band

This is highly problematic because it means that, while SSH is supposed to 
defend against MITM in theory, it does not defend in practice.

OpenSSH already addresses this in their client, I believe, by making it 
really quite hard to verify a changed key. Many users further configure the 
OpenSSH client to require a key to be set up for the first connection, to 
begin with.

Expect-Key just extends that - which I think is a good practice - to all 
clients, in general, enforceable as a server-side policy. It defeats TWAT.


> Conversely, it means the vast majority won't use it.

Users will use what administrators set up for them. If admins don't want to 
set up Expect-Key, fine. But this gives them a tool.

denis



----- Original Message -----
From: Peter Gutmann
Sent: Sunday, March 26, 2017 02:53
To: Mouse ; ietf-ssh%NetBSD.org@localhost
Subject: Re: Fixing exchange of host keys in the SSH key exchange

Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

> As far as I can see, this affects the user only in that "pick up the host 
> key
> on first connect" no longer works.

It breaks TOFU.  Since this is how the vast majority of all users use SSH
(ref: 
https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf),
it means it would break SSH for them.  Conversely, it means the vast 
majority
won't use it.

> Then this suggestion has the additional feature that it will smoke out such
> bugs!

Trying to smoke out non-standards-compliant implementations at this point,
about twenty-odd after SSH2 started getting deployed, is probably a bit late
in the game.

Also, does this mean any implemenation that doesn't correctly implement a 
MUST
or MUST NOT can regarded as broken and discarded?

Peter.