Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!

> Broken software will probably always be with us.

That's theoretically true but practically unhelpful. :) In practice, it
matters how much broken software there is. One obscure implementation
failing at something is a minor issue, but one major one or several minor
ones means a practical implementation which aims for widespread
compatibility can't use the feature.

Therefore it's important to exercise the protocol abilities we want to
preserve to keep the number of broken implementations low, rather than high.

> Speaking of which, and I recognize it's possible nobody
> here is in a position to answer this, why does EXT_INFO
> exist, rather than just using the DNS extensibility
> mechanism, with global requests if necessary?

I do believe I'm in a position to answer this. I offer two reasons, one
from each category:

(I) Reason of principle: before EXT_INFO, the SSH protocol lacked
extensibility beyond that permitted by adding individual algorithms,
without raising the protocol version number. Changing the protocol version
number is incompatible with current widespread deployment. In the interest
of future extensibility, a generic extension mechanism was needed which is
fully compatible with the installed base that does not support it.

This is a SSH-specific instantiation of a generic need for extension
negotiation that has identified by most popular internet protocols. ESMTP
has this, FTP has this, TLS has this, even SFTP has this. Now SSH has it.
It fills a retroactively obvious gap that wasn't covered previously.

(II) Reason of practical need: SSH needed to transition from RSA signatures
with SHA-1 to RSA signatures with SHA-2. This could have been done without
EXT_INFO by creating a new key format, but then all existing host key and
client public key associations would break, and it would take a decade and
lots of difficulty and coaxing to upgrade users.

To preserve existing host key and client public key associations, it was
desirable to preserve the same public key format ("ssh-rsa") but introduce
new signature algorithms ("rsa-sha2-256" and "rsa-sha2-512"). But now
there's a problem - during client authentication, the client needs to
discover which signature algorithms the server supports without risking a
lockout due to an authentication penalty. So the server needs some way to
announce this.

It would have been possible to come up with an ad-hoc kludge mechanism
specific for this, but then this would cost us 1 kludge and it would gain
only 1 solution. Instead, I thought it was desirable to expend the cost of
this kludge, and gain instead a general solution. EXT_INFO is this general
solution. It solves the problem of advertising RSA signature algorithms
supported by the server, while at the same time adding a extension
negotiation to SSH.

So now we have this one kludge (it works by adding "ext-info-c" or
"ext-info-s" to a KEXINIT field not originally intended for this), but we
gain a general extension mechanism so that, IF WE DON'T LOSE IT, we don't
need any more kludges in the future.

Why not DNS...? Because the extension mechanism in a protocol should be
self-contained. I mean, it would be possible for FTP, ESMTP, TLS or SFTP to
have an extension mechanism based on DNS, yes - in principle. Does that
seem a good idea to anyone...? It seems an obvious can of worms to me.

denis