> 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