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

[Ilari Liusvaara <[e-mail]>]

On Wed, May 24, 2017 at 08:50:07AM -0500, Benjamin Kaduk wrote:
> On 05/21/2017 05:47 PM, Eric Rescorla wrote:
> >
> >
> > On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara
> > <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >     On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:
> >      
> >
> >     - Clients MUST NOT use the same ticket multiple times for 0-RTT.
> >
> >
> > I don't understand the purpose of this requirement. As you note below,
> > servers are ultimately responsible for enforcing it, and it's not clear to
> > me why clients obeying it makes life easier for the server.
> >
> 
> I think it's just an attempt to make clear what the client behavior
> should be.  It's like when we say that implementations MUST NOT put more
> than one extension of the same type in a given extension block.  The
> peer has to validate received messages, but the local implementation has
> to know to not generate them, either.

There's also quite a bit of difference between:

- MUST NOT do X
- MUST NOT do X, MUST abort with Y if X is done.

As the second requires receiver to detect X, which can be hard. E.g.,
detecting arbitrary duplicated extension is definitely not trivial.
 
E.g., for duplicate extensions, my implementation only validates the
known extensions. As consequence, unknown extensions in offers can
appear multiple times without detection (e.g., two copies of extension
35 in ClientHello). It is done that way to limit resource usage:
Checking a small list of extensions is easy, checking 64k of those is
less so.

> >
> >     - Servers MUST NOT accept the same ticket with the same binder
> >     multiple
> >       times for 0-RTT (if any part of ClientHello covered by binder is
> >       different, one can assume binders are different). This holds even
> >       across servers (i.e., if server1 accepts 0-RTT with ticket X and
> >       binder Y, then server2 can not accept 0-RTT with ticket X and binder
> >       Y).
> >
> >
> > I assume that what you have in mind here is that the server would know
> > which tickets it was authoritative for anti-replay and would simply reject
> > 0-RTT if it wasn't authoritative? This seems like it would
> > significantly cut
> > down on mass replays, though it would of course still make
> > application-level
> > replay a problem.
> >
> 
> Right, this would bring replays down from the millions hypothesized for
> the weak time-based thing to more like tens, which is kind of in the
> regime that we are currently in with (at least some) application behavior.

Actually, even tens of replays at TLS level is quite dangerous,
especially if to different servers (bad information leaks via cache
attacks).

> > I'm happy to write this up as part of the first two techniques. I'd be 
> > interested in hearing from others in the WG what they think about:
> >
> 
> I think it's worth writing up the most-secure scheme(s) we know of, to
> give us some concrete text to digest and decide if we can live with.

However, every scheme that isn't the most-secure (tied 1st place) that
has been proposed so far is too insecure.

> > 1. Requiring it.
> > 2. Whether they still want to retain the stateless technique.
> >
> 
> If we think we can require it and have it actually stick, that seems
> like the safest plan.  The results of this discussion leave me uneasy
> with a scheme that permits millions of replays, even if there is not
> something concrete that I definitely object to.  As DKG (almost) said,
> "we're designing a security protocol, not an easy-to-implement
> protocol". 

There is major difference about how hard TLS 1.3 is to _implement_, and
how hard it is to _use_.

Most serious TLS 1.3 implementations will be written by experts.
Additionally, the protocol avoids using constructs that are almost
impossible to implement properly (e.g., good riddance TLS blockmode).

Whereas most applications using TLS will not be written by security
experts. And the protocols they implement are not designed for side-
channel resistance in implementations.

> Another crazy idea would be to just say that servers MUST limit the use
> of a single binder to at most 100 times, with the usual case being just
> once, to allow for alternative designs that have weaker distributed
> consensus requirements (but still describe these current two methods as
> examples of ways to do so).

You actually need strong distributed consensus about all accepted
0-RTT here.


-Ilari