Fixing exchange of host keys in the SSH key exchange

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

Hello everyone,

I’m wondering if anyone - OpenSSH and PuTTY in particular? - would be 
interested in implementing an extension to the way the initial SSH handshake 
is done, in a way that would allow the SSH server to require the client to 
communicate one or more fingerprints of the server’s host key(s), before 
exchanging KEXINIT.

This would have multiple benefits:

(1) Security benefit: although the client could still not verify the server’s 
signature during key exchange, or could do any number of other things 
incorrectly; under reasonable assumptions, if the client has to communicate 
one or more fingerprints of the server’s host key(s) before KEXINIT, this 
prevents the situation where the client will present the user with a host 
key verification dialog, and the user will just click through it.

(2) Security benefit: on servers that enable this policy, and prevent 
connections where the client does not communicate a correct server host key, 
drive-by password guessing becomes largely impossible, since unknown 
attackers do not know the server’s host key.

(3) Practical benefit: the server knows which ones of its host keys the 
client trusts, and can avoid the situation where introduction of a new host 
key, with no change to previous host keys, would break connections for 
existing clients that prefer to negotiate the algorithm of the new host key, 
but do not actually trust it. The server can avoid this by restricting its 
list of host key algorithms presented in KEXINIT to match what the client 
already trusts.

Implementation:

We have room for textual data that can be sent before the SSH version 
string. To implement this, the client would send one or more lines such as:

Expect-Key: <base64-sha256-fingerprint>\r\n

A server that implements this as a requirement would wait for the 
“Expect-Key” lines before sending its KEXINIT. If the client just sends a 
version string, without at least one correct Expect-Key, the server could 
disconnect - perhaps with an informative SSH_MSG_DISCONNECT message.

The rest of the protocol could remain unchanged. Server implementations that 
do not know about this extension, but correctly implement the spec, would 
ignore the unknown lines, and would be unaffected.

If the rest of the protocol is unchanged, the Expect-Key lines will NOT be 
verified as part of the SSH key exchange hash, which means a "helpful" 
man-in-the-middle (such as a proxy) could insert Expect-Key lines and cause 
the connection to work, when it otherwise wouldn't. This might be a feature, 
or a misfeature.

However, we could also change the protocol to include the Expect-Key lines 
in the SSH key exchange hash. In this case, the client would signal support 
by sending at least one Expect-Key line, and the server would signal support 
in another way. One way would be to include the name "expect-key" among its 
host key algorithms in KEXINIT.

If the client has sent at least one Expect-Key line, and the server includes 
the name "expect-key" in its host key algorithms, the Expect-Key lines would 
become part of the SSH key exchange hash.

denis