Re: applying AES-GCM to secure shell: proposed "tweak"

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

Nicolas Williams <Nicolas.Williams%sun.com@localhost> writes:

>    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.

I'm not sure that this length-extension will work.  The spec has always said
that the packet ends at the reserved field, but this would change it to say
that it can now continue more or less arbitrarily beyond this point.  What
will existing implementations do if they see garbage beyond this point? 

I'd also rephrase the above a bit to say:

    When a KEXINIT is received that has a non-zero value in the KEXINIT
	reserved uint32 field and the receiver can't process a non-zero value then
	it MUST ignore it.

The original text seems to say "this value must always be ignored", the new
text says "if you don't know what the significance of the flags are, ignore
them".  Well OK, it says it rather badly, I'm open to suggestions for better
phrasings.

Peter.