Subject: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 16 Mar 2016 10:52:48 -0400

This has been bugging me for a long time and I've talked to some here about
it in person, but this report;

https://www.teamupturn.com/static/reports/2016/what-isps-can-see/files/Upturn%20-%20What%20ISPs%20Can%20See%20v.1.0.pdf

provokes me to bring it up. Here's the crux of it; is it really a security
win to recommend the AEAD cipher suites for TLS 1.2 users?

The AEAD cipher suites as-implemented are byte-for-byte mappable to
response sizes, with no padding for any kind of length hiding. This makes
passive size analysis attacks quite a lot easier than they could be (a
quick sample of wikipedia page sizes suggests that even 16 byte blocks
raise the difficulty by orders of magnitude). The search hints attack
outline in the paper may not even work with 16-byte padding. I want to
emphasize that the attack here is passive, undetectable to servers or
clients, and realistic - it's likely happening today.

On the other side of the trade-off is that the AEAD mode ciphers are not
susceptible to mac-then-encrypt issues, such as Lucky13. Some time ago I
wrote up some detail on the Lucky13 attack:
https://blogs.aws.amazon.com/security/post/TxLZP6HNAYWBQ6/s2n-and-Lucky-13
, and my take here is that the scenario is so unrealistic that the attack
is simply impractical against TLS - even unmitigated. In any event, TLS CBC
implementations have been mitigated and patched. Here I also want to
emphasize that the attack is active - it generates lots of noisy signals -
and may never have happened.

Is it wise to make the real-world attack cost less, to mitigate the
theoretical one? I also think AEAD mode is awesome: it's how crypto should
be used, and want to give it a strong endorsement, but not at the cost of
making on-the-wire data meaningfully less secure.

At a minimum: could we agree that if a service/site is sensitive to privacy
- it's reasonable for them to prefer AES-CBC; should they be penalized in
SSL health analysis tools/reports for that configuration? it's not as
flexible or useful as the padding in TLS1.3, but it's what we have.

-- 
Colm

---

From: Tom Ritter <[email-masked]>
Date: Wed, 16 Mar 2016 11:45:55 -0500

> flexible or useful as the padding in TLS1.3, but it's what we have.

If a site wants to actively do something to make length-hiding harder
- to the point where they're go in and prefer CBC ciphersuites - why
not just add 5 lines of code to a header template, to insert some
random data in a HTML comment?

I'm one of the biggest proponents for padding in TLS 1.3... and hope
to see it used to make deployments of length-hiding and traffic
analysis harder, so the HTML comment or similar tricks would be
easier, more robust, and not require site modifications.  But I don't
think going back to CBC mode is a good idea.

-tom

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 16 Mar 2016 12:54:05 -0400

> random data in a HTML comment?

Length hiding is a game of costs, doing more can always help. But one of
the benefits of being able to do it at the TLS layer  is that it also helps
you hide the length of the request.

> think going back to CBC mode is a good idea.

Why?

-- 
Colm

---

From: Alexandre Anzala-Yamajako <[email-masked]>
Date: Wed, 16 Mar 2016 17:58:51 +0100

IMO, the layer creating the plaintext shouldn't have to pad it for security
that's the job of the TLS layer.
the TLS library should be parameterized by a size range and any plaintext
larger than the range would get chunked up to smaller pieces while anything
smaller would be padded.
The actual value of the range could then be left to be chosen by the caller
since this has an impact not only in security but also in performance.
IIRC this how things are done in MiTLS (https://mitls.org/)

-- 
Alexandre Anzala-Yamajako

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 16 Mar 2016 18:14:37 +0000

Hi Colm,

On 16/03/2016 14:52, "TLS on behalf of Colm MacCárthaigh"
<[email-masked] on behalf of [email-masked]> wrote:
>
>This has been bugging me for a long time and I've talked to some here
>about it in person, but this report;
>
>https://www.teamupturn.com/static/reports/2016/what-isps-can-see/files/Upt
>urn%20-%20What%20ISPs%20Can%20See%20v.1.0.pdf
>
>provokes me to bring it up. Here's the crux of it; is it really a
>security win to recommend the AEAD cipher suites for TLS 1.2 users?
>
>
>quick sample of wikipedia page sizes suggests
> that even 16 byte blocks raise the difficulty by orders of magnitude).
>The search hints attack outline in the paper may not even work with
>16-byte padding. I want to emphasize that the attack here is passive,
>undetectable to servers or clients, and realistic
> - it's likely happening today.
>
> , and my take here is that the scenario is so unrealistic that the
>attack is simply impractical against TLS - even unmitigated. In any
>event, TLS CBC implementations have been mitigated and patched. Here I
>also want to emphasize that the attack is active -
> it generates lots of noisy signals - and may never have happened.

Well, you know already that we disagree on this :-)

For everyone else's benefit, let me say the following:

- Attacks only ever get better.

- The Lucky 13 timing signal can be amplified for DTLS using packet trains
(see this NDSS 2012 paper for the techniques:
http://www.internetsociety.org/plain-text-recovery-attacks-against-datagram
-tls).

- As your blog nicely explains, AWS's s2n implementation chose to mitigate
Lucky 13 using a bespoke solution. This code was found to be vulnerable to
attack shortly after the code was released
(https://eprint.iacr.org/2015/1129). The initial patch to the code was
also insecure (https://eprint.iacr.org/2015/1241). Readers can draw their
own conclusions from this. Mine is that even gifted programmers get TLS's
MtE construction wrong.

I feel strongly that going back to MtE would be a retrograde step.

Much better would be implementing an optional padding feature for the AEAD
modes. Something like this draft proposes:

https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02

Cheers

Kenny 

>theoretical one? I also think AEAD mode is awesome: it's how crypto
>should be used, and want to give it a strong endorsement, but not at the
>cost of making on-the-wire data meaningfully
> less secure. 
>
>
>At a minimum: could we agree that if a service/site is sensitive to
>privacy - it's reasonable for them to prefer AES-CBC; should they be
>penalized in SSL health analysis tools/reports for that configuration?
>it's not as flexible or useful as the padding
> in TLS1.3, but it's what we have.
>
>
>-- 
>Colm
>

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 Mar 2016 18:30:03 +0000

>>security win to recommend the AEAD cipher suites for TLS 1.2 users?

I'm skeptical about the benefit of padding to 16 bytes. While it does
increase the size classes in your Wikipedia example, Wikipedia pages
trigger subresource loads, which also have a size and page-to-page
navigation leaks more information. My takeaway from reading
traffic-analysis papers over the years is that countermeasures are
surprisingly difficult.

On the other hand, the CBC cipher suites are fundamentally broken,
rather slow and, in an attempt to fix them, are now very complex. So I
don't believe that the benefits of padding to 16 bytes comes close to
justifying the use of the CBC modes. Over the coming years I hope that
CBC modes are killed off in the same fashion that RC4 now has been in
several browsers.

Padding at the application-level (e.g. HTTP) is probably the easiest,
reasonable place to add padding (if there's a scheme with solid
justification). Sure, one doesn't get "automatic" padding that using
CBC modes might (somewhat) get you, but I still don't think CBC is a
good tradeoff.

Cheers

AGL

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 16 Mar 2016 14:32:34 -0400

> - Attacks only ever get better.

This applies to the passive size side-channel ones too though; and we're
seeing credible evidence that they're already happening today. I think
anything we can do here to raise costs for the attackers is worthwhile.

> http://www.internetsociety.org/plain-text-recovery-attacks-against-datagram

That's true, but I don't think it's all that relevant to the security of
TLS as used. In general DTLS has been more vulnerable to all sorts of
active protocol level attacks because of the weaker guarantees it can
provide.

> own conclusions from this. Mine is that even gifted programmers get TLS's

Well as the blog also explains, at no time was s2n succeptible to a Lucky13
vulnerability. In fact; as-it-was s2n did considerably better than
alternatives widely used in production. And that's my point here; we may be
over-indexing on the issue itself. Programmers certainly get things wrong -
though in this case the decision to use the hmac() construction as it is
specified (so that it can be formally verified against the specification)
was intentional.

But I take the point that AEAD modes are harder for programmers to screw
up; and that does have value. But my experience is that folks are pretty
good about keeping software up-to-date with patches and so on, and less
good about keeping configuration settings and protocol choices safe. As we
broaden the use of AEAD, more traffic becomes more susceptible to the very
real-world attacks above, and it's a "stickier" problem that will stay in
place.

I don't like MtE one bit, but I also don't like zero length hiding one bit.
So it's a complicated nuanced trade-off.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 16 Mar 2016 14:42:57 -0400

> traffic-analysis papers over the years is that countermeasures are

16-bytes is small, I wish it were much bigger, but it may elevate things to
where you even need to form a sub resource attack and increases the size of
the graph/fingerprint that you need to maintain to form the sub-resource
attack. I doubt it would thwart a large actor for very long, but it would
help against smaller ones and I'm guessing that it might block some
specific attacks like the autocompletion one mentioned in the paper.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 16 Mar 2016 14:49:47 -0400

> https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02

I hadn't seen that! I wonder is there an appetite here for including more
robust LH in TLS1.2 in some form? I mean a real one; as in - let's it get
it into servers and browsers sooner than TLS1.3.

-- 
Colm

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Mar 2016 19:01:27 +0000

> I hadn't seen that! I wonder is there an appetite here for including more robust LH in TLS1.2 in some form? I mean a real one; as in - let's it get it into servers and browsers sooner than TLS1.3. 

H2 has padding; put it there.

There is probably zero interest in adding padding to TLS 1.2, especially since the record type is plaintext and could easily be bypassed.

---

From: Benjamin Beurdouche <[email-masked]>
Date: Wed, 16 Mar 2016 20:27:42 +0100

Hi all !

> On 16 Mar 2016, at 19:49, Colm MacCárthaigh <[email-masked]> wrote:
> 
> On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny <[email-masked] <mailto:[email-masked]>> wrote:
> https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02 <https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02>
> 
> I hadn't seen that! I wonder is there an appetite here for including more robust LH in TLS1.2 in some form? I mean a real one; as in - let’s it get it into servers and browsers sooner than TLS1.3. 

FYI, the experimental length-hiding feature from miTLS described by Alexandre earlier implements the draft specification linked by Kenny…

Best, 
B.

---

From: [email-masked] (Martin Rex)
Date: Fri, 18 Mar 2016 18:08:54 +0100 (CET)

Colm MacCárthaigh wrote:
> up; and that does have value.

Though it is a pretty flawed assumption.

I've seen an AEAD cipher implementation fail badly just recently (resulting
in corrupted plaintext that went unnoticed within TLS--MACing the ciphertext
is obviously a pretty dumb idea), something that is *MUCH* more unlikely
to happen to any cipher suites using GenericBlockCipher PDU.

Pretty much all of othe known crypto attacks are highly theoretical and
meaningless in practice, whereas corrupted plaintext is an immediate
real pain in the ass.

I'm glad that the problem was spotted before the affected code was shipped.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 18 Mar 2016 18:10:49 +0100 (CET)

> that's the job of the TLS layer.

Yep.  And retrofitting random padding into TLS (all protocol versions, all
PDUs) could be actually pretty simple and straightforward.

http://www.ietf.org/mail-archive/web/tls/current/msg11626.html

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 18 Mar 2016 23:53:44 +0000

Martin Rex <[email-masked]> writes:

>is obviously a pretty dumb idea), something that is *MUCH* more unlikely to
>happen to any cipher suites using GenericBlockCipher PDU.

There have been many more failures with GCM, the most notorious being Colin
Percival's tarsnap, where a single missed operation (increment the IV)
resulted in a total loss of security.  Colin is a very experienced crypto
developer, so its not like this was some beginner mistake.  This is why I
referred to GCM as "brittle", you can be about as abusive as you like with CBC
and the worst you get is degradation to ECB, while with GCM you make one
mistake and you get a catastrophic loss of security.

Peter.

---

From: Harlan Lieberman-Berg <[email-masked]>
Date: Sun, 20 Mar 2016 15:53:30 -0400

Peter Gutmann <[email-masked]> writes:
> This is why I referred to GCM as "brittle", you can be about as
> abusive as you like with CBC and the worst you get is degradation to
> ECB, while with GCM you make one mistake and you get a catastrophic
> loss of security.

Couldn't you say the same about CTR mode, or stream ciphers themselves?
Sure -- it's definitely a lot harder to screw up "incrementing a
counter" than it is all the stuff GCM requires you to do, but....

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Mar 2016 13:18:04 -0700

Note: TLS 1.3 should significantly decrease the risk of this because the
record sequence number is used as the nonce, therefore if you fail to
increment the sequence number, you will quickly not interoperate with
other implementations which are correct.

-Ekr

On Sun, Mar 20, 2016 at 12:53 PM, Harlan Lieberman-Berg <[email-masked]

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 21 Mar 2016 06:20:41 +0000

>Couldn't you say the same about CTR mode, or stream ciphers themselves?

Yep, the KSG ciphers are all equally bad, just RC4 in another form.
Microsoft, and the downstream users of its APIs, were do badly burned by this
over and over again that their build tools now flag any use of RC4 as a
security failure.

Peter.