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

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

On Thu, Jun 1, 2017 at 5:22 PM, Eric Rescorla <[e-mail]> wrote:

> I've just gone through this thread and I'm having a very hard time
> understanding what the actual substantive argument is about.
>
> Let me lay out what I think we all agree on.
>

This is a good summary, I just have a few clarifications ...


> 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause
>    connection failures) then a DKG-style attack where the client
>    replays the 0-RTT data in 1-RTT is possible.
>

This isn't what I call a replay. It's a second request, but the client is
control of it. That distinction matters because the client can modify it if
it needs to be unique in some way and that turns out to be important for
some cases.

2. Because of point #1, applications must implement some form
>    of replay-safe semantics.
>

Yep; though note that in some cases those replay-safe semantics themselves
actually depend on uniquely identifiable requests. For example a protocol
that depends on client-side-versioning, or the token-binding case.


> 3. Allowing the attacker to generate an arbitrary number of 0-RTT
>    replays without client intervention is dangerous even if
>    the application implements replay-safe semantics.
>

Yep.


> 4. If implemented properly, both a single-use ticket and a
>    strike-register style mechanism make it possible to limit
>    the number of 0-RTT copies which are processed to 1 within
>    a given zone (where a zone is defined as having consistent
>    storage), so the number of accepted copies of the 0-RTT
>    data is N where N is the number of zones.
>

This is much better than the total anarchy of allowing completely unlimited
replay, and it does reduce the risk for side-channels, throttles etc, but I
wouldn't consider it a proper implementation or secure. Importantly it gets
us back to a state where clients may have no control over a deterministic
outcome.

Some clients need idempotency tokens that are consistent for duplicate
requests, this approach works ok then. Other kinds of clients also need
tokens that are unique to each request attempt, this approach doesn't work
ok in that case. That's the qualitative difference.

I'd also add that the suggested optimization here is clearly to support
globally resumable session tickets that are not scoped to a single site.
That's a worthy goal; but it's unfortunate that in the draft design it also
means that 0-RTT sections would be globally scoped. That's seems bad to me
because it's so hostile to forward secrecy, and hostile to protecting the
most critical user-data. What's the point of having FS for everything
except the requests, where the auth details often are, and which can
usually be used to generate the response? Synchronizing keys that can
de-cloak an arbitrary number of such sessions to many data centers spread
out across the world, seems just so defeating. I realize that it's common
today, I've built such systems, but at some point we have to decide that FS
either matters or it doesn't. Are users and their security auditors really
going to live with that? What is the point of rolling out ECDHE so
pervasively only to undo most of the benefit?

Maybe a lot of this dilemma could be avoided if the the PSKs that can be
used for regular resumption and for 0-RTT encryption were separate, with
the latter being scoped smaller and with use-at-most-once semantics.

5. Implementing the level of coherency to get #4 is a pain.
>
> 6. If you bind each ticket to a given zone, then you can
>    get limit the number of accepted 0-RTT copies to 1
>    (for that zone) and accepted 1-RTT copies to 1 (because
>    of the DKG attack listed above).
>

Yep! Agreed :)

-- 
Colm