SSH_MSG_KEXINIT extensions field [was Re: applying AES-GCM to secure shell: proposed "tweak"]

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I'd also like us to clarify how implementors should deal with that
> reserved uint32 field in KEXINIT today as a way of buying ourselves
> room for future extensions.

That, I totally agree with.  The current situation doesn't really give
us any way to use that field for anything.

> For that I propose this:

>     The reserved uint32 field in KEXINIT MUST be set to 0; future
>     specs may specify the meaning of non-zero values and when they
>     may be sent.

>     When a KEXINIT is received that has a non-zero value in the
>     KEXINIT reserved uint32 field, then the receiver MUST ignore
>     both, the reserved uint32 field and any additional bytes in the
>     packet beyond it.

>     Future extensions might [...]

(I'd also make explicit the implied change to SSH_MSG_KEXINIT, adding
optional additional data of unspecified size after the uint32 in
question, with the restriction that if the value is zero there must be
no additional data.)

This sounds good to me.  I support this proposal, in case anyone cares
what I think.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B