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.
No, I think the right thing is for the SSH_MSG_OPTION message itself to be permitted at any time, and leave it to the definitions of individual options to specify when an option may be negotiated and when the results of that negotiation take effect.
FWIW, while there's nothing wrong protocol-wise with negotiating the cleartext-packet-lengths option immediately after KEXINIT, I think it's cleaner (and probably easier for some implementations) to do it just _before_ KEXINIT. After all, you probably don't want to renegotiate the option every time a new key exchange happens, but it does have to be negotiated before NEWKEYS, since some encryption algorithms will only work with plaintext lengths.
With regard to the negotiation itself, I think it might be cleaner to have three separate messages:
byte SSH_MSG_OPTION_REQUEST (value = 7) string option name ... option-specific data byte SSH_MSG_OPTION_REPLY (value = 8) string option name string response ... option-specific data byte SSH_MSG_OPTION_DATA (value = 9) string option name ... option-specific data_REQUEST is used to request support for an option, with optional option-specific data.
_REPLY is sent in response to _REQUEST; it identifies the option in question and gives one of the following responses:
"ack" - The option is supported and has now been successfully negotiated. Its features may be used immeiately, by the sender of the _REPLY starting with its next packet, and by the receiver of the _REPLY as soon as it has seen the ack. Note that an option like cleartext-packet-lengths makes a non-self-describing change to the packet format and so will still require an indicator.
"nak" - The option is supported but negotiation failed, presumably because option-specific parameters proposed by the requestor are not acceptable. The option-specific data may carry information that would help a later attempt succeed.
"unimplemented" - The option is unrecognized or not supported.Once an option has been successfully negotiated (i.e. _REPLY with ack), additional option-specific data may be sent in either direction according to the _DATA message; this is basically a mechanism to allow options to define new packet types without allocating message numbers.
The above may still be slightly too complex, but I'm not sure how to simplify it without losing too much generality. Suggestions welcome.
In the case of the cleartext-packet-lengths option, the option data in the _REQUEST must be empty, and any implemention supporting the option MUST respond to the _REQUEST with an ack; that is, the nak response may not be sent for this option. Once the option has been negotiated, either side may switch between sending cleartext and encrypted lengths whenever it wants, by sending SSH_MSG_OPTION_DATA with option "cleartext-packet-lengths" and data "on" to indicate lengths will be cleartext starting with the next packet, or "off" to indicate they will be encrypted (when encryption is in effect). The side sending the _REPLY message may begin using cleartext lengths immediately by including option data of "on" in the _REPLY packet.
I think this is cleaner than the approach der Mouse suggested, because it allows either side to switch modes at any time and makes it clear what the new mode will be on every switch. It does this at the expense of eliminating the ability of the peer to accept or reject any mode change, instead requiring that once the option has been negotiated, each peer be willing to accept either encrypted or unencrypted lengths at any time (though an encryption algorithm may require the option be enabled). It does still allow cleartext lengths to be negotiated separately in each direction, which I think is appropriate given that SSH requires negotiation of encryption algorithms separately in each direction.
-- Jeff