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

[Eric Rescorla <[e-mail]>]

On Fri, May 19, 2017 at 2:40 PM, Ilari Liusvaara <[e-mail]>
wrote:

> On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:
> > On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara <
> [e-mail]>
> > wrote:
> > >
> > > - 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.
>
> Yup. There are no known reasons that prevent at-most-once 0-RTT delivery,
> even with distributed servers for the origin.
>

I don't disagree with that necessarily, but if the client responds by
retransmitting
in 1-RTT, then you don't have overall at-most-once.

-Ekr



>
> Of course, this impiles that there is some small-enough spatial scope
> for 0-RTT, so servers in scope can reach global consistency in acceptable
> time (which also sets the server timeout!)
>
> Latencies within a single datacenter should be pretty low, and routing
> should be pretty sticky between datacenters.
>
> > 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.
>
> Yeah, for clients that are as careless with HTTP as browsers, sending
> POSTs in 0-RTT data is very bad idea.
>
> > 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.
>
> This is already required in order to implement HTTP semantics. E.g. so
> that if 0-RTT section contains POST request, the HTTP library can signal
> its client "failed: connection to server lost before reply was
> received" (and retry GETs, PUTs and DEETEs).
>
> > * 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.
>
> Isn't that potentially multi-party problem if middleboxes are involved?
>
>
> > 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.
>
> The purpose of obfustication is not to hide sibling sessions. The
> client already blows its cover by using the same session ID twice. The
> purpose of obfustication is to hide the parent session.
>
> Are you talking about attackers being able to determine the rate of
> client clock?
>
>
> -Ilari
>