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

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Apr 15, 2009 at 04:28:47PM -0400, der Mouse wrote:
> > I'm strongly against adding new general option or negotiation
> > frameworks just to support aead.  That's simply not worth the effort.
> 
> The point is that they _aren't_ "just to support aead".  If they were,
> yes, it would not be worth the bother.  They are to support aead _and_
> whatever other now-unforeseen issues arise down the line -
> future-proofing, if you will.  Trying to solve the immediate problem

The original designers of the SSHv2 kex clearly didn't have the right
vision of the future, but, then again, their design mistakes haven't
stopped us.  I don't believe we can do much better now as, like them
then, we cannot necessarily predict the future.

Thus I'd rather do the simplest possible solution, which solution I
think I've stated something like four or five times today.

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.  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 treat the reserved uint32 field as a flags
    field and might specify flags that, when set, indicate that
    additional data may be found between the reserved field and the end
    of the KEXINIT packet, and/or that additional new key exchange
    protocol packets may follow.

Nico
--