Subject: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

From: Ryan Carboni <[email-masked]>
Date: Tue, 16 Sep 2014 12:08:13 -0700

I read the discussion on it. The sorts of attacks on cryptographic block
ciphers that are less than brute force don't even apply to the typical
short messages typically transferred over the internet. Even then, MAC than
encrypt doesn't reduce security substantially since even the MAC is
encrypted.

Oh, BTW, thanks guys for making the internet work.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 16 Sep 2014 21:11:54 +0000

Ryan,

The RFC is less clear than it could be about the specific attacks of concern that motivated this document. These are (primarily) Vaudenay's padding oracle attack from 2002 and its reincarnation in the form of Lucky 13 in 2013. These attacks both recover plaintext, not keys. And the message length is irrelevant to their success.  

I'm actually a bit surprised the relevant research papers are not informative references - they ought to be, precisely to preempt the need for this kind of educative dialogue. 

Cheers,

Kenny

> On 16 Sep 2014, at 20:09, "Ryan Carboni" <[email-masked]> wrote:
> 
> I read the discussion on it. The sorts of attacks on cryptographic block ciphers that are less than brute force don't even apply to the typical short messages typically transferred over the internet. Even then, MAC than encrypt doesn't reduce security substantially since even the MAC is encrypted.
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ryan Carboni <[email-masked]>
Date: Tue, 16 Sep 2014 14:51:40 -0700

Hmm, the 2013 attack would be later than the discussions I did read.

If you're upgrading specifications, why not switch to SHA-3, which is
constant time (AFAIK)?

That way the number of TLS options in my browser doesn't /double./

On Tue, Sep 16, 2014 at 2:11 PM, Paterson, Kenny <[email-masked]>
wrote:

> Ryan,
>
> The RFC is less clear than it could be about the specific attacks of
> concern that motivated this document. These are (primarily) Vaudenay's
> padding oracle attack from 2002 and its reincarnation in the form of Lucky
> 13 in 2013. These attacks both recover plaintext, not keys. And the message
> length is irrelevant to their success.
>
> I'm actually a bit surprised the relevant research papers are not
> informative references - they ought to be, precisely to preempt the need
> for this kind of educative dialogue.
>
> Cheers,
>
> Kenny
>

---

From: Adam Langley <[email-masked]>
Date: Tue, 16 Sep 2014 14:57:36 -0700

> If you're upgrading specifications, why not switch to SHA-3, which is

All hash functions used in TLS are constant-time (unless you try very
hard to implement them badly).

Cheers

AGL

---

From: Ryan Carboni <[email-masked]>
Date: Tue, 16 Sep 2014 15:00:14 -0700

Modulo isn't constant time, but XOR, ROT, NOT, AND are.

---

From: Adam Langley <[email-masked]>
Date: Tue, 16 Sep 2014 15:09:23 -0700

> Modulo isn't constant time, but XOR, ROT, NOT, AND are.

That's true in general, but the MD/SHA family of hashes only use mod
2^32 or 2^64 which is just a truncation and thus constant time on any
CPU I can think of.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Bodo Möller <[email-masked]>
Date: Wed, 17 Sep 2014 00:26:21 +0200

> If you're upgrading specifications, why not switch to SHA-3, which is

Part of the problem is that in TLS MAC-then-Encrypt, the position of the
MAC tag depends on the amount of padding -- so *nothing* is constant-time
without considerable effort.

(It's funny that one of the references provided in the new RFC shows how
MAC-then-Encrypt in TLS is supposedly secure, when the RFC came to be
because actually it isn't.)

Bodo

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 18 Sep 2014 09:18:31 -0400

What that reference shows is that for authenticate-then-encrypt mode to be
secure with cbc and otp encryption (or stream cipher), you must apply the
MAC to the plaintext after any encoding (including padding) and, in the
case of cbc, in full blocks (and, of course, with unpredictable IVs).
Unfortunately, TLS did not do it this way for cbc and that's why all these
attacks were possible. The example in the paper, while artificial, explains
well why authenticate-then-encrypt with unauthenticated encoding can go
wrong. So the math in the paper is correct - the conclusion that TLS does
it right is wrong. It doesn't.

Hugo