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

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

On Thu, Apr 16, 2009 at 11:13:01AM -0400, der Mouse wrote:
> >> To improve the situation we need to twist the KEXINIT abstraction a
> >> bit more [...]  IF a non-AEAD cipher is chosen AND there was no
> >> common MAC AND there was a common AEAD cipher THEN re-compute the
> >> cipher selection ignoring all non-AEAD ciphers.
> 
> This rule interacts very badly with the implementation of
> any other encryption algorithm that similarly wants to ignore MACs,
> especially if it defines an analogous rule.

Surely such an encryption algorithm would be an AEAD algorithm,
therefore there is no such interaction (since the rule still applies).

You're making this more complicated than it has to be.

> > Ugh.  This is starting to get complicated.
> 
> Indeed.  My "next special case" has shown up already and the first one
> hasn't even been settled yet.  I stand by my stance that this approach
> will rapidly turn kex into an incomprehensible (and, of course,
> unmaintainable) mess of cross-linked dependencies.

"Incomprehensible", no, "complex", yes.  But that's what we have to work
with.  I don't see Jeff's proposal for a KEX_OPTION packet type as
making any of this less complex now, but it is a way forward the next
time we need it.

Of course, Jeff's KEX_OPTION packet type needs negotiation too!  Jeff
proposed using the comment field of the SSH version message.  But I
think I will not be alone in rejecting that idea.  We can only really
use the reserved uint32 field for the KEX_OPTION packet type.  Which
means that we MUST first fix the handling of the reserved uint32 field.
Which means we can only really use alg names for AEAD negotiation right
now, and must also fix the reserved uint32 field now so we can use it
the next time around.

It's not how I'd design the protocol from scratch, y'know.  It's what
we've got to work with.

Nico
--