Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 3 Dec 2013 19:12:21 +0000

Hi Martin,

> -----Original Message-----
> From: Martin Rex
> Sent: 29 November 2013 20:17
> To: Juho Vähä-Herttua
> Cc: <[email-masked]>; Peter Gutmann
> Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
> 
> >
> > I'm sure you have good reasons for this opposition, so could you
> > please explain them in one or two sentences. This excluding the
> > "encrypting the HMAC makes it safer" argument, which might be true but
> > as I understand is not well proven.
> 
> The fact that GHASH must be encrypted is sufficient proof that an encrypted
> MAC provides a better safety margin than a plaintext MAC.
> 

You seem to be making the assumption that GHASH is a MAC algorithm. It's not.
It's a universal hash function, that is, a function designed so that a particular bound on the 
probability of collision holds when the hash key is chosen uniformly at random, quantified over
all possible pairs of input messages. See

http://en.wikipedia.org/wiki/Universal_hashing

for definitions.

GHASH is not itself intended to provide the unforgeability properties that we expect from a MAC.

In more detail, this kind of hash function can serve as the basis for building a MAC, but cannot be 
used alone for that purpose. A fairly standard construction that uses a universal hash function like 
GHASH to build a MAC is to mask the GHASH output using a pseudorandom value computed using 
a (second) secret key.  

In AES-GCM, the security proof allows this pseudorandom value to be generated using the
encryption key with counter mode of AES, which happens to be the same mode used for 
encryption of the plaintext. This is convenient for implementation, but not a necessary 
feature for building a MAC from a universal hash function.

So I don't believe it is either helpful or correct to cite GHASH as evidence that 
MAC-then-encrypt provides a better safety margin than a plaintext MAC.

> MAC in the clear is only safe when the MAC algorithm is sufficiently close to
> perfect.  We know painfully well that our hash algorithms are *not* perfect, so
> I'm against taking chances, in particular for the GenericBlockCipher PDU.

Here you first refer to MAC algorithms needing to be perfect, then hash algorithms 
not being perfect. But these are different things. And all the evidence from the cryptographic
literature suggests that attacks on hash functions do not tidily convert into attacks on MAC
algorithms built from these hash functions (I refer here to the significant body of research on this
topic, including but not limited to: Fouque et al at Crypto 2007, L. Wang et al. at Eurocrypt 2008, 
X. Wang et al. at Eurocrypt 2009, and more recent work, e.g. Peyrin et al. at Asiacrypt 2012).

Cheers

Kenny

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 5 Dec 2013 03:24:21 +0000

Eric Rescorla <[email-masked]> writes:

>This topic was discussed at the TLS WG meeting in Vancouver (since you 
>declined to attend, 

So by cleverly choosing a forum that you knew I couldn't attend (and that 
others who were interested in it, e.g. WG members from Europe, couldn't 
attend either) you managed to manufacture consent and perpetuate your 
refusal to address the issue.  

In any case the WG consists of people on this mailing list, not a select 
few folks in some back-room in Vancouver.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 5 Dec 2013 03:35:34 +0000

Martin Rex <[email-masked]> writes:

>TLSv1.2 is a royal PITA for TLS clients, because it requires a reconnect
>fallback facility to be implemented by ***EVERY*** application caller client 
>on top of TLS, ***PLUS*** every application caller will have to memorize the 
>fallback for every destination or the latency will be a royal pain for every 
>new handshake after the TLS session expires from the client-side TLS session 
>cache (when client-side session caching is used at all.  

It's a PITA in general because it introduces a bunch of unexplained and more
or less arbitrary restrictions and silly-walk requirements (e.g. if you do
X with algorithm Y then you also need to do Z) which have no effect except to 
break interoperability.  Things mostly work at the moment because by mutual
unspoken consensus implementers ignore some of the sillier requirements, or
because there's a common mode like using SHA-256 everywhere that seems to 
work OK for all implementations.  At some point in the future though this is 
going to cause headaches when other implementations that don't know how to
interpret the spec in order to make things work come along.

Peter.