Subject: [TLS] Additional warnings on 0-RTT data

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 23 Nov 2016 09:47:54 -0800

I've submitted a PR with an expanded warning on the dangers of 0-RTT data
for implementors:

https://github.com/tlswg/tls13-spec/pull/776/files

The text is there, and the TLDR summary is basically that time-based
defenses aren't sufficient to mitigate idempotency bugs, so applications
need to be aware of the sharp edges and have a plan.  For clarity, I've
outlined three example security issues that could arise due to realistic
and straightforward, but naive, use of 0-RTT. There's been some light
discussion of each in person and on the list.

In the PR I'm "MUST"ing that applications need to include /some/ mitigation
for issues of this class (or else they are obviously insecure). In my
experience this class of issue is so pernicious, and easy to overlook, that
I'm also "RECOMMEND"ing that applications using Zero-RTT data
*intentionally* replay 0-RTT data non-deterministically, so as to keep
themselves honest.

At a bare minimum I think it would be good to make clear that clients and
implementations MAY intentionally replay 0-RTT data; to keep servers on
their toes. For example a browser could infrequently tack on a dummy
connection with repeated 0-RTT data, or an implementation could
periodically spoof a 0-RTT section to the application. That should never be
considered a bug. but a feature. (And to be clear: I want to do this in our
implementation).

-- 
Colm

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Nov 2016 10:03:16 +1100

This seems like too much text to me.  Maybe some people would
appreciate the reminder that replay might cause side-effects to be
triggered multiple times, or that side effects are just effects and
those might also be observable.  But I think that those reminders
could be provided far more succinctly.

The bit that concerns me most is the recommendation to intentionally
replay early data.  Given that I expect that a deployment that enables
0-RTT will tolerate some amount of side-effects globally, and that
excessive 0-RTT will trigger DoS measures, all you are doing is
removing some of the safety margin those services operate with.

On 24 November 2016 at 04:47, Colm MacCárthaigh <[email-masked]> wrote:
> outlined three example security issues that could arise due to realistic and
> straightforward, but naive, use of 0-RTT. There's been some light discussion
> of each in person and on the list.
>
> connection with repeated 0-RTT data, or an implementation could periodically
> spoof a 0-RTT section to the application. That should never be considered a
> bug. but a feature. (And to be clear: I want to do this in our
> implementation).
>
>
> --
> Colm
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 23 Nov 2016 18:18:49 -0800

> could be provided far more succinctly.

My main goal is clarity, especially to application builders. In my
experience the implications of replay-ability are frequently overlooked and
it's well worth being abundantly clear.  For most builders, those full
implications have never occurred to them (why would they?), so it's often
not a reminder, but new knowledge. It warrants a big warning label, not
FUD, but honestly scary because it is a very hard problem.

But still, the text can most likely be shortened some, edits welcome.

> removing some of the safety margin those services operate with

Can I break this into two parts then? First, do you agree that it would be
legitimate for a client, or an implementation (library), to deliberately
replay 0-RTT data? E.g. browsers and TLS libraries MAY implement this as a
safety mechanism, to enforce and audit the server's and application's
ability to handle the challenges of replay-ability correctly.

At a bare minimum I want to be free to include this in our implementation
of TLS, and in the clients that we use. I think there's value in explicitly
documenting this, and that the problem is squarely on the server side if it
is not replay-even-within-time-window-tolerant. Frankly: I want to be able
to point to the spec and it be clear whose fault it is.

Now second, consider a web service API that exists today and is using TLS.
Many such APIs depend entirely on TLS for all anti-replay protection
(though for the record, the SigV4 authentication mechanism we use at AWS
includes its own anti-replay measure). When TLS1.3 comes along it is *very*
tempting for providers to turn it on and use it for those APIs. Everyone
always wants everything to be faster, and it won't be a huge code change.
The problems of replay attacks could be dismissed as unlikely and left
unaddressed, as security issues often are.

So through a very predictable set of circumstances, I think those calls
will be left vulnerable to replay issues and TLS1.3 will absolutely degrade
security in these cases. What I'm suggesting is that we RECOMMEND a
systematic defense: clients and/or implementations should intentionally
generate duplicate data, so that the problem *has* to be addressed at least
in some measure by providers. I far prefer that they be forced to encounter
a low grade of errors early in their testing than to leave a large hole
looming for users to fall into.

This style of "Always always test the attack case in production" is also
just a good practice that keeps anti-bodies strong.

Thanks for reading and the feedback.

On 24 November 2016 at 04:47, Colm MacCárthaigh <[email-masked]> wrote:
> and
> periodically

-- 
Colm

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Nov 2016 14:31:25 +1100

> ability to handle the challenges of replay-ability correctly.

OK, let's be clear: I don't agree that the level of paranoia
surrounding 0-RTT is warranted.  I'm of the belief that end-to-end
replay is a property we should be building in to protocols, not just
something a transport layer does for you.  On the web, that's what
happens, and it contributes greatly to overall reliability.

The reaction to perceived problems in 0-RTT is disproportionate.  You
are asking for a license to replay here at some arbitrary layer of the
stack.  That's not principled, it's just on the basis that you don't
like 0-RTT and want to innoculate other people's software against the
ill effects it might create.  What I object to here is the
externalizing that this represents.  Now if I have the audacity to
deploy 0-RTT, I have to tolerate some amount of extra trash traffic
from legitimate clients?

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 23 Nov 2016 20:11:59 -0800

On Wed, Nov 23, 2016 at 7:31 PM, Martin Thomson <[email-masked]>
wrote:

> surrounding 0-RTT is warranted.

Do you disagree that the three specific example security issues provided
are realistic, representative and impactful? If so, what would persuade you
to change your mind?

> I'm of the belief that end-to-end

The proposal here I think promotes that view; if anything, it nudges
protocols/applications to actually support end-to-end replay.

> ill effects it might create.

The problems of 0-RTT are disproportionately under-estimated. I've provided
what I think are three concrete and realistic security issues. If we
disagree on those, let's draw that out, because my motivation is to
mitigate those new issues that are introduced by TLS1.3.

> What I object to here is the externalizing that this represents.  Now if I
> have the audacity to

I think there is a far worse externalization if we don't do this. Consider
the operations who choose not (or don't know) to add good replay
protection. They will iterate more quickly and more cheaply than the
diligent providers who are cautious to add the effective measures, which
are expensive and difficult to get right. That is a perverse incentive, and
ultimately users would pay the price.

I have the same gut reaction against sending duplicate data and having a
sort of "tax on everyone" for the sake of safety as you, it's icky, but I
haven't been able to think of another mitigation for the problems that
would be as effective.

-- 
Colm

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Nov 2016 15:40:25 +1100

On 24 November 2016 at 15:11, Colm MacCárthaigh <[email-masked]> wrote:
> Do you disagree that the three specific example security issues provided are
> realistic, representative and impactful? If so, what would persuade you to
> change your mind?

These are simply variants on "if someone hits you with a stick, they
might hurt you", all flow fairly logically from the premise, namely
that replay is possible (i.e., someone can hit you with a stick).

The third is interesting, but it's also the most far-fetched of the
lot (a server might read some bytes, which it later won't read,
exposing a timing attack).  But that's also corollary material; albeit
less obvious.  Like I said, I've no objection to expanding a little
bit on what is possible: all non-idempotent activity, which might be
logging, load, and some things that are potentially observable on
subsequent requests, like IO/CPU cache state that might be affected by
a request.

> protocols/applications to actually support end-to-end replay.

You are encouraging the TLS stack to do this, if not the immediate
thing that drives it (in our case, that would be the HTTP stack).  If
the point is to make a statement about the importance of the
end-to-end principle with respect to application reliability, the TLS
spec isn't where I'd go for that.

> disagree on those, let's draw that out, because my motivation is to mitigate
> those new issues that are introduced by TLS1.3.
>
> the operations who choose not (or don't know) to add good replay protection.
> They will iterate more quickly and more cheaply than the diligent providers
> who are cautious to add the effective measures, which are expensive and
> difficult to get right.

OK let's ask a different question: who is going to do this?

It's a non-trivial thing you ask for.  This involves a new connection
setup just to send a few packets, and probably a timer so that you can
wait long enough for the server to explode.  Do you expect to replay
before the real attempt?  Because that's even less likely to happen.

Connections aren't cheap, bandwidth as well.  And the time requirement
for building such a feature would be better spent elsewhere, not to
mention the ongoing maintenance.

I don't see browsers doing anything like what you request; nor do I
see tools/libs like curl or wget doing it either.  If I'm wrong and
they do, they believe in predictability so won't add line noise
without an application asking for it.

If few enough people do this, what makes you think that such a tiny
amount of replay would make any difference?  Unless you replay with
high probability, then the odd error will be dismissed as a transient.
This is especially true because most of these sorts of exploitable
errors will happen adjacent to some sort of network glitch (the
requests at the start of most connections - on the web at least - are
pretty lame).

Then you all you have done is increased the global rate of "have you
turned it off and on again?", which is - after all - yet another
opportunity for replay.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 23 Nov 2016 21:19:56 -0800

On Wed, Nov 23, 2016 at 8:40 PM, Martin Thomson <[email-masked]>
wrote:

> are

Prior to TLS1.3, replay is not possible, so the risks are new, but the
end-to-end designers may not realize to update their threat model and just
what is required. I'd like to spell that out more than what's where at
present.

> exposing a timing attack).

I need to work on the wording because the nature of the attack must not be
clear. It's really simple. If the 0-RTT data primes the cache, then a
subsequent request will be fast. If not, it will be slow.

If implemented on a CDN for example, the effort required would be nearly
trivial for an attacker. Basically: I replay the 0-RTT data, then probe a
bunch of candidate resources with regular requests. If one of them loads in
20ms and the others load in 100ms, well now I know which resource the 0-RTT
data was for. I can perform this attack against CDN nodes that are quiet,
or remote, and very unlikely to have the resources cached to begin with.

> But that's also corollary material; albeit

ok, cool :)

> spec isn't where I'd go for that.

I'm not sure where the folks designing the HTTP and other protocols would
get the information from if not the TLS spec. It is TLS that's changing
too. Hardly any harm in duplicating the advice anyway.

> protection.

I am, for one. I don't see 0-RTT as a "cheap" feature. It's a very very
expensive one. To mitigate the kind of issues it brings really requires
atomic transactions. Either the application needs them, or something below
it does. So far I see fundamentally no "out" of that, and once we have
atomic transactions then we either have some kind of multi-phase commit
protocol, distributed consensus, routing of data to master nodes, or some
combination thereof.

The smartest people I've ever met work on these kinds of systems and they
all say it's really really hard and subtle. So when I imagine Zero-RTT
being done correctly, I imagine organizations signing up for all of that,
and it being worth it, because latency matters that much. That's a totally
valid decision.

And in that context, the additional expense of intentionally replaying
0-RTT seems minor and modest. My own tentative plan is to do it at the
implementation level; to have the TLS library occasionally spoof 0-RTT data
sections towards the application. This is the same technique used for
validating non-replayable request-level auth.

> without an application asking for it.

I hope this isn't the case, but if it is and browsers generally agree that
it would be unimplementable and impractical, then I think 0-RTT should be
removed unless we can come up with other effective mitigations. Otherwise
it's predictable that we'll see deployments that don't bother to solve the
hard problems and are vulnerable to the issues I've described. But let's
not be doom and gloom about it, there's got to be a way to mitigate.

-- 
Colm

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 23 Nov 2016 20:44:51 -1000

On Wednesday, November 23, 2016 7:20 PM, Colm MacCárthaigh wrote:
>
> Prior to TLS1.3, replay is not possible, so the risks are new, but the end-to-end designers
> may not  realize to update their threat model and just what is required. I'd like to spell 
> that out more than what's where at present. 

Uh? Replay was always possible, at the application level. Someone might for example click twice on the same URL, opening two tabs, closing one at random. And that's without counting on deliberate mischief.

-- Christian Huitema

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 24 Nov 2016 06:37:52 -0800

On Wed, Nov 23, 2016 at 10:44 PM, Christian Huitema <[email-masked]>
wrote:

> end-to-end designers
> Uh? Replay was always possible, at the application level. Someone might
> for example click twice on the same URL, opening two tabs, closing one at
> random. And that's without counting on deliberate mischief.
>

Much more than browsers use TLS, and also more than HTTP. There are many
web service APIs that rely on TLS for anti-replay, and do not simple retry
requests. Transaction and commit protocols for example will usually have
unique IDs for each attempt.

But even if this were not the case, there are other material differences
that are still relevant even to browsers. Firstly, an attacker can replay
0-RTT data at a vastly higher rate than they could ever cause a browser to
do anything. Second, they can replay 0-RTT data to arbitrary nodes beyond
what the browser may select. Together these open new attacks, like the
third example I provided.

-- 
Colm