Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis

[Michael Clark <[e-mail]>]

On 24/12/14 4:58 pm, Michael Clark wrote:
> On 24/12/14 2:15 pm, Peter Gutmann wrote:
>> Michael Clark <[e-mail]> writes:
>>
>>> I have been doing some independent research on TLS AEAD ciphers and decided
>>> to share a meta-analysis on AES-GCM versus AES-EAX/AES-CCM
>>
>> If you're going to look at these, what about also looking at encrypt-then-MAC,
>> which is another AEAD mechanism?

CBC is MAC-then-encrypt in TLS1.2, however encrypt-then-MAC is the
current best practice? encrypt-then-MAC allows you to verify message
integrity before decryption and abort sessions after a (small) error
count to mitigate any brute forcing over the wire (without cost of
decryption). With MAC-then-encrypt you need to decrypt before you can
verify the MAC.

Also from TLSv1.2 6.2.3.3. "No MAC key is used." with AEAD.


If you replaced MAC-then-encrypt with encrypt-then-MAC in TLSv1.3 then
you could alter the behavior of the new encrypt-then-MAC to make it work
for non AEAD ciphers like CBC as well to (optionally) augment the
message authentication bits for AEAD ciphers that are currently limited
to 128 bits. I'm not talking about the common case where AES_128_GCM and
128-bit tags is a good start for SSL everywhere. I'm talking about cases
where the overhead of 3 passes may be acceptable. Also consider this a
pencil sketch. Of course servers that want to maintain backwards
compatibility would need to keep encrypt then Mac. These are just ideas.


A TLSv1.3 ClientHello and ServerHello extensions could advertise
something like this this:

enum { AuthBits128, AuthBits256, AuthBits384, AuthBits512}
MessageAuthenticationBits;

struct {
  MessageAuthenticationBits minimum_authentication_bits;
  MessageAuthenticationBits preferred_authentication_bits;
} MessageAuthSecurity;


The client and server choose a MacAlgorithm based on the combination of
the negotiated cipher's authentication tag bits (0 bits for non AEAD
ciphers) and the bits of the mac algorithms present in
SecurityParameters.mac_algorithms. A (null) MacAlgorithm may be chosen
if the cipher's AEAD tag bits meets the minimum or preferred
authentication bits or a suitable MacAlgorithm could be chosen to
provide the remaining bits. For non AEAD ciphers a MacAlgorithm would be
chosen that matches the minimum or preferred authentication bits. The
policy over the the choice of minimum or preferred message
authentication bits would need to be considered.

A negotiated MessageAuthenticationBits message_authentication_bits could
be added to the TLSv1.3 SecurityParameters along with MACAlgorithm
mac_algorithm which may or may not be (null) with an AEAD cipher.


If the client or server wanted 128 message authentication bits:

* AEAD cipher with 128 bit auth tag, (null) MacAlgorithm and no
encrypt-then-MAC at the TLS layer. AD would be be passed to the AEAD cipher.

* non AEAD cipher, hmac_sha128 with encrypt-then-MAC at the TLS layer.
AD would be prefixed in the MAC in the TLS layer encrypt-then-MAC when a
non AEAD cipher was used (currently the MAC is a suffixed in the
MAC-then-encrypt scheme in TLSv1.2).


If the client or server wanted 256 message authentication bits

* AEAD cipher with 128 bit auth tag, hmac_sha128 MacAlgorithm with
encrypt-then-MAC at the TLS layer. AD would be be passed to the AEAD cipher.

* non AEAD cipher, hmac_sha256 with encrypt-then-MAC at the TLS layer.
AD would be prefixed in the MAC in the TLS layer encrypt-then-MAC when a
non AEAD cipher was used (currently the MAC is a suffixed in the
MAC-then-encrypt scheme in TLSv1.2).


This is based on the observation that SHA1 is being phased out; however
it may well be that based on the nonce lifetime this is not needed. That
said some applications may like the idea of having Cipher based MAC in
an AEAD cipher combined with a PRF based MAC as they both have different
properties

And when I refer to the collision properties of Cipher based MACs I'm
referring to one block of course (the size of the tag).

Michael.