Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh <[e-mail]>]

On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara <[e-mail]>
wrote:
>
> To me, that reads as gross understatement about the dangers involved in
> 0-RTT:
>
> - The side channel attacks with millions or billions of replays are hard
>   to protect against. This is if the side channels are in TLS library.
>   If not, protecting against that sort of side channels becomes
>   virtually impossible.

- Furthermore, with that kind of replay volume, protecting against DoS
>   attacks is virtually impossible.


> - Even if once-per-server or once-per-cluster replay detection limits
>   the number of replays to few hundred to few thoursand at maximum,
>   where the low-level crypto side channels are much less of a threat,
>   cache attacks can be used to break security (in fact, not sending a
>   mad burst of data to any one server is useful for carrying out these).
>

I wouldn't be too fatalistic about it. The speed of light is too slow for
human interaction, and 0-RTT is an important and awesome feature that we
should make safe and near universal.

Some protection is necessary; but it isn't too hard - a single-use session
cache, or a strike register, do protect against the side-channel and DOS
problems. Combined with a "fail closed" strategy and tickets that are
scoped to clusters or servers, these techniques do hard-stop the literal
0-RTT replays, and they are practical. Many of us run systems like that
already.


> Also, the kind of thing going on here seems exactly how I would imagine
> the past very bad decisions from TLS WG, that were known to be insecure
> at the time of specification and where then successfully attacked later,
> played out. However, I have not read those discussions from the ML
> archives.
>

In this case, I think people see the trade-offs differently and that's ok.
There's a sense that the risks or cost are worth it. After all, you can
mitigate a lot of the risk if you have a team of experts on standby who
manually mitigate these kinds of attacks, or more advanced automated
response systems. And many big providers do have both of these.

What concerns me most is that the 0-RTT interactions here are formalizable
and that the messaging interactions can be modeled in TLA+, F*, etc ... but
that hasn't been done as it has with the rest of the TLS1.3 state machine.

My TLA+ simple model convinced me that what's in the draft doesn't actually
work; there's nothing in the messages that allows a server to de-dupe, I
wrote up a simple 3-message example of this earlier in the thread, and it
seems to hold to the breaking the "X-" header trick that one provider came
up with.  That already in this draft deployment phase, that can advanced,
knowledgable, provider's attempt at a mitigation can be shown to be broken
should be cause for alarm. It's not a safe set-up.

Here's all I think we need to fix all of this though, in order of priority:

For relatively "Normal" clients (e.g. Browsers):

* Servers supporting 0-RTT need to robustly prevent replay of literal 0-RTT
sections. No time-based mitigation, which simply doesn't work. This is the
"cost" of doing 0-RTT.
* Clients should be the real arbiter of what to use 0-RTT; e.g. never use
for POST, etc. This could bear some emphasis. It's important because
middle-boxes exist.

For careful clients, think about something implementing a transaction over
TLS:

* If a 0-RTT section is sent but does not result in a successful receipt,
that failure needs to be signaled to the client.
* In order to fully reason about when that message may later get received,
there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by all
potential middle-boxes in the pipe that may be using 0-RTT.

And then separate to all of the above, and lower priority:

* There's a contradiction between the obfuscated ticket age add parameter
and the desire to use tickets multiple times in other (non-0RTT) cases. We
can't do one without defeating the point of the other. Either remove the
obfuscation because it is misleading, or move it into an encrypted message
so that it is robust.

-- 
Colm