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

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

On Thu, Apr 16, 2009 at 10:22:03AM +0200, Niels Möller wrote:
> Nicolas Williams <Nicolas.Williams%sun.com@localhost> writes:
> > But not simpler than my proposal:
> >
> >    IF an AEAD cipher is selected THEN no MAC alg is selected (since the
> >    cipher provides integrity protection all by its lonesome).
> 
> To be precise, does this mean that the mac-list is ignored, or that
> the *result* of that selection is ignored? Consider the following
> advertised lists:
> 
>   Client:   enc="aead", mac="hmac-sha1"
>   Server:   enc="aead", mac="hmac-md5"
> 
> Should the algorithm selection succeed, settling on aead and no
> additional mac, or fail because there's no common mac?

The former.

> Or to make it more complicated, what should be the result of:
> 
>   Client:   enc="3des-cbc,aead", mac="hmac-sha1"
>   Server:   enc="3des-cbc,aead", mac="hmac-md5"
> 
> We can either fail, since is 3des-cbc selected for encryption, but
> there's no common mac, or succeed if we notice that there's no common
> mac, and then filter out all non-AEAD options for encryption.

This is a separate issue.  Remove AEAD and you don't interop.  Add AEAD
with my rule and you still don't interop.  To improve the situation we
need to twist the KEXINIT abstraction a bit more (no objections from
me): 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.

Nico
--