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

[nisse%lysator.liu.se@localhost (Niels Möller)]

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?

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 kind-of contradicts Jeffrey Hutzelman's wish

: In the case of encryption and MAC algorithms, I don't think we should
: have this sort of bidirectional dependency.

and without thinking deeply, I suspect the situation is quite similar
to the keyexchange/hostkey dependency, and that we should make about
the same level of effort to find a working combination in both cases.
I don't implement any keyexchange method that requires encryption,
maybe someone that does and understands this better can enlighten me?

Regards,
/Niels