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

[Eric Rescorla <[e-mail]>]

On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara <[e-mail]>
wrote:

> On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:
>
> >
> > 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.
>
> As requirements:
>
> - Clients SHOULD NOT use the same ticket multiple times.
>

This is already in the document.



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



> - Servers MAY accept the same ticket multiple times.
>

This seems implicit.



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

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:

1. Requiring it.
2. Whether they still want to retain the stateless technique.

-Ekr