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

[Benjamin Kaduk <[e-mail]>]

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.

>  
>
>     - Servers MAY accept the same ticket multiple times.
>
>
> This seems implicit.
>

It seems implicit to me, as well, though I'm not sure that there's harm
in saying it explicitly, particularly when reusing a ticket is a MUST
NOT in certain specific cases (0-RTT).

>  
>
>     - 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.

> 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.

> 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".  I'm still concerned that if we put MUST it will be more RFC
6919 than 2119, though, even if clients and/or ssllabs try to grease
it.  So, if we require it, then the stateless technique is not needed
per se (but we still want the time limit so as to bound the size of a
strike register).  If we don't/can't require it, then I would say keep
the stateless technique but try to crank down the time window and
suggest that implementations rate-limit 0-RTT acceptance per domain to
try to get away from the billions of replay regime.

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).

-Ben