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

>> I can't help wondering if perhaps this is time to use the uint32 in
>> SSH_MSG_KEXINIT that is "0 (reserved for future extension)",
> Unfortunately, there exist implementations that disconnect, or
> generate an invalid key exchange hash, if that value is not zero.

I'm not sure what my stance is on that.

In general, I take the stand that if there are implementations that
don't implement the spec correctly, that's their problem, not a reason
to avoid using that part of the spec.  But, here, I don't think there's
any current spec for what an implementation should do if it finds a
nonzero value there, so I'm not sure to what extent _any_ behaviour in
response to that constitutes misbehaviour.  In retrospect, I think
specifying that RFU zero without giving any explicit guidance for
behaviour upon finding it nonzero was a mistake.

>> Also, 4253 says the server MAY send text before its version number,
>> but is silent on the question of whether the client also may.
> Of course, even if it did say otherwise, there could exist server
> implementations that do not handle this properly.

Of course - but then it would clearly be a case of the servers in
question being broken (and my stance would be that it's the server's
problem - see above).  As it is, it's not clear.

> It seems that testing would be in order.

Probably.  But it seems to me that any implementation SHOULD have
client configuration knobs so that Expect-Key: is not sent unless the
server is expected to be prepared to handle it.

> Or maybe the server sends something like "Expect-Key:
> support|require".  The format can vary between client and server.
> That might still not work if there are clients that violate 4253,
> though.

That's the problem of any such clients.  IMO.  (As I think I said
upthread, I've encountered servers that misbehave - crash or something
equivalent from the client's point of view - when faced with the
string@domainname extension feature.  Is that a reason to not use it?)

> Another way that would work for sure would be:

> - The server includes "expect-key" among its host key algorithms.
> [...]

> - If client sees "expect-key" among server's host key algorithms,
> [...]

Yesss...though there may exist implementations that misbehave upon
seeing a non-extension algorithm name they do not recognize.  (My
stance, as above, would be that such implementations are broken and
deserve nothing but ridicule, but your remarks above seem to imply you
don't take that stance, or at least not as much as I do.)

> This approach has downsides compared to Expect-Key before version
> string: [...]

Both true, though the second one (that it interferes with guessed kex)
is weak in that all it means is that clients and servers using this
extension can't really do guessed kex.  But all guessed kex really buys
you is one network roundtrip fewer, and I submit that if that matters
then either you have a _really_ laggy network or your PK crypto is so
weak that your security is questionable anyway. :-)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B