der Mouse <mouse@Rodents-Montreal.ORG> writes: >> If we're going to make this change, could we also consider moving >> *all* ciphers to nonencrypted lengths? This currently requires >> horribly complex code to process, > >That wasn't my experience as an implementor. Perhaps you're trying to (ab) >use cryptosystem interfaces not designed for that style of use? No, just doing it properly. >I would suggest creating new packet type for negotiating options like this. >As a strawman: > > byte SSH_MSG_OPTION (value = 7) > string option name > ... option-specific data Actually that would have been my preference as well, at the moment SSH has no facility for interoperable extensibility beyond defining entire new message types via (presumably) standards-track RFCs. Having an extension mechanism like TLS would greatly assist in introducing new features, or enhancing existing ones. >SSH_MSG_OPTION may be sent at any time, except that specific option >definitions may impose additional restrictions for packets naming that >option. Ugh, I would restrict this to specific places, e.g. right after the KEXINIT and and couple of other well-defined redezvous points, not at any time. If you allow either side to set protocol behaviour-changing options at any point you're going to end up with a huge interop headache. >I propose the option name "cleartext-packet-lengths". > >[Multi-page description of incredibly complex negotiation snipped] Again, this is never going to work if you expect different implementations to interoperate cleanly. What's wrong with "if both sides send 'cleartext- packet-lengths' then you continue with unencrypted lengths, otherwise you don't"? Peter.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.