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

[Damien Miller <djm%mindrot.org@localhost>]

On Thu, 16 Apr 2009, Peter Gutmann wrote:

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

OpenSSH will treat additional data at the end of a kex packet as
a fatal error. It ignores unknown values of the "reserved" field though,
so it could be used to signal that additional data follows in a different
packet, or that the failure of a kex method is non-terminating.

-d