Markus Friedl wrote:
On Tue, Jul 22, 2003 at 03:44:42PM -0700, Nicolas Williams wrote:I think the fact that some implementations do not tolerate KEXINIT "extensions" should not precluse the proposed change. Several implementations already map the peer's version string to compatibility notes and react accordingly. While I hope that we can put stop adding to this database of compatibility notes I think that this particular issue (KEXINIT extensibility) is worth the trouble to fix.I don't think it's a good idea to break the protocol at this point. This compatibility database is always a pain and you always miss some implementations. I think you could only assume that the peer is able to deal with the extension if it sends a non-zero value in the reserved field, but I doubt this helps for what you want. On the other hand, you could send the extension data in an extra packet if the reserved byte is not zero.
If you wanted to get really hacky about it, you could put the additional data in the padding part of the SSH packet. This restricts you to 251 bytes of data (255 bytes max padding - 4 bytes of real padding) but should retain compatibility with all current clients. Of course, it's also a truly unpleasant hack and probably messy to implement for everyone concerned. But it's possible...
Overall, my personal opinion (FWIW) is: a) using an extra packet would be best, andb) implementations should ignore additional data within packets, or at least within packets with reserved fields allowing for extensions. Not ignoring additional data basically means reserved fields are useless, since in every case the only decent solution will be a) above, and if that was the desired extensibility mechanism, one could just rely on sending new packet types, receiving SSH_MSG_UNIMPLEMENTED from old clients and then sending the old packet type in order to extend things.
I'm curious as to why OpenSSH does refuse extra packet data - this goes against the general liberal-in-what-you-receive principle, which makes me interested in the thinking behind doing things this way.
-- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com