Re: Transport I-D: KEXINIT reserved field needs description

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Nicolas Williams wrote:

> The transport I-D defines the SSH_MSG_KEXINIT message:
>
>     byte      SSH_MSG_KEXINIT
>     byte[16]  cookie (random bytes)
>     string    kex_algorithms
>     string    server_host_key_algorithms
>     string    encryption_algorithms_client_to_server
>     string    encryption_algorithms_server_to_client
>     string    mac_algorithms_client_to_server
>     string    mac_algorithms_server_to_client
>     string    compression_algorithms_client_to_server
>     string    compression_algorithms_server_to_client
>     string    languages_client_to_server
>     string    languages_server_to_client
>     boolean   first_kex_packet_follows
>     uint32    0 (reserved for future extension)
>
> Nothing is said about the semantics of the last field.
>
> Can implementors describe how they handle non-zero values for the last
> field of SSH_MSG_KEXINIT?
Currently, debug builds of VanDyke's implementation ASSERT that the 
value is 0,
but since these builds are not shipped (as a general rule), I believe we 
are okay with
the value being changed.

> I propose the following change:
>
> - Name the last field of KEXINIT "extensions":
>
>     byte      SSH_MSG_KEXINIT
>     byte[16]  cookie (random bytes)
>     string    kex_algorithms
>     string    server_host_key_algorithms
>     string    encryption_algorithms_client_to_server
>     string    encryption_algorithms_server_to_client
>     string    mac_algorithms_client_to_server
>     string    mac_algorithms_server_to_client
>     string    compression_algorithms_client_to_server
>     string    compression_algorithms_server_to_client
>     string    languages_client_to_server  
>     string    languages_server_to_client
>     boolean   first_kex_packet_follows 
>     uint32    extensions
>
> - Describe the 'extensions' field and the semantics of extensions
>   negotiation:
>
>      extensions
> 	 Currently MUST always be set to zero (0).  If set to zero this
> 	 is the last item in this packet.  Future extensions to
> 	 SSH_MSG_KEXINIT may be defined by IETF RFCs which specify
> 	 non-zero values for this field and add fields to the end of the
> 	 packet.  Receipients MUST ignore any items in SSH_MSG_KEXINIT
> 	 packets past this field that if they do not know the extensions
> 	 value.
>
> 	 ["Implementations must be careful to include the entire
> 	   SSH_MSG_KEXINIT packets in the session ID hash, not just the
> 	   fields they know about." ??]
>  
I do think we want the sentance clarifying that the entire KEX packet must
be included in session id hash.  Should it say key exchange hash instead?
Since only the first key exchange hash becomes the session id.

I assume we don't want to define the extension format now because of 
last call?

We might be able to use the extensions field as a count field:

    boolean   first_kex_packet_follows 
    uint32    extension_count
    string    extension_name[1]
    string    extension_data[1]
    string    extension_name[2]
    string    extension_data[2]
    string    extension_name[...]
    string    extension_data[...]
    string    extension_name[extension_count]
    string    extension_data[extension_count]

And give extension name the same semantics that is used else where in the
document-- @dns name extendable.

Remember, what is being extended here is algorithm negotiation, not
(as the packet name might have you think) key exchange (well, key exchange
algorithm is part of what is being negotiated.)

So I think a flexible extension mechanism is called for.  I.e., some of 
the things
that might be negotiated here in the future might be:

- hash algorithm for failed kex packets.
- compatibility work arounds (My implementation is vandyke.com, and
 I've fixed bugs 1 & 2; if you were working around this bugs, please
 don't anymore.)
- Capabilities announcement (I support packets > 35K; I support key 
exchange retry; etc., etc.)

I wouldn't want to assume we are smart enough to anticipate all future 
needs, or
that everyone's needs will actually need to be standardized by the 
IETF.  By allowing
extensibility, we prevent those people that have needs not met by the 
IETF from
producing broken, non-complaint implementations.  (I believe that people 
will produce
implementations that meet their needs, whether they can do it and comply
with the RFC or not.)

But this is all probably discussion for a new I-D.

Joseph