On Saturday, February 17, 2007 09:42:54 PM +0000 Ben Harris <bjh21%bjh21.me.uk@localhost> wrote:
I've just uploaded an internet-draft that would allocate an SSH message number to be used for named message types, where the names work like all the other names in SSH. This should make it easier to extend the SSH transport layer in ways that need new message types, as it appears might be necessary to produce a race-free version of zlib%openssh.com@localhost. Named packet types aren't right for everything, of course, but they seem sensible for packets that are only likely to be sent a few times per connection. What do people think of this idea? <http://www.ietf.org/internet-drafts/draft-bjh21-ssh-transport-extension- 00.txt>
Sounds like a good idea. I can't find evidence of any reason to restrict allocation of transport-level message numbers other than the extreme scarcity of the namespace, so opening it up in the way you describe seems reasonable.
I think it is probably worth noting that anyone defining a standards-track extension requiring a new transport-level message would now have a choice as to whether to allocate a new message type number or used a named type. This decision would presumably be made on the basis of whether there are performance implications which make it a good idea to consume a number.
I think the advice you give in the security considrations section is misplaced. The question of whether to send a message prior to completion of the initial key exchange depends on the semantics of the message in question and whether it can live with the lack of integrity protection. While it's pretty likely that the number of such messages is small and they have all already been defined, there is no guarantee of that. In any event, the question is unrelated to the use of named message types; it would apply equally to messages using new numbers.
At a minimum, this text should be reworded as advice to designers as future extensions, without use of RFC2119 keywords which appear to specify behavior for implementations.
-- Jeff