Re: [TLS] Closing on 0-RTT

[Bill Cox <[e-mail]>]

On Tue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara <[e-mail]>
wrote:

> >   - Note that 0-RTT exporters are not safe for authentication on servers
> > that do not enforce single-use tickets, or for clients that do not
> > recompute authentication signatures on retransmission of early data.
>
> "Single-use tickets" imply global anti-replay.
>

I assumed "gobal anti-replay" meant there would be a globally synchronized
cache of valid single-use tickets.  It sounds like you mean "global
anti-replay" includes schemes using orbit/metro/server bound tickets, since
they can support single-use tickets.  In that case, I agree with you, but I
think the phrase "single-use tickets" may be less confusing.  Maybe just
say "anti-replay" instead of "global anti-replay"?

And the latter part is way too obscure. I have no idea how it is
> trying to fix ClientHello replay resulting the same exporter
> output.
>

I don't know what you mean by "resulting the same exporter output."  Auth
signatures in a 1-RTT fallback need to be recomputed using the 1-RTT
exporter to avoid having the same signature accepted twice.  Maybe this is
too specific and should be left out.

> Even this is only partially true.  Anti-replay can be built above the TLS
> > layer.  I'm considering doing token-binding replay defense in the
> > authentication backend, to help ensure the token-binding guarantee: that
> > auth tokens taken from one device cannot be used from another device
> > without continued access to the first device's signing oracle.
> > Unfortunately, 0-RTT master resumption secrets are a new kind of auth
> > bearer token, and the token binding spec does not cover them.
>
> Doing stuff like this gets more and more complicated and fragile as
> one moves up the layer stack.
>

It depends on the task.  Moving channel ID from the TLS layer to token
binding in the HTTP layer should simplify the TLS state machine enough to
justify the change.  Anti-replay in the TLS layer would be good for 0-RTT
token binding, but the cost and complexity of running the whole user-facing
fleet of servers with anti-replay caches is huge, many times higher than
the cost of token-binding anti-replay in the backend.  Also, the
authentication backend is where bound tokens are currently verified, so
putting the anti-replay there seems like the appropriate layer.

I'm still not sure this scheme is worth implementing, but without it, I do
not think we can support client certificates or token binding over 0-RTT.
It doesn't really matter for the TLS 1.3 spec.  I'm just pointing out that
the statement "0-RTT auth is insecure without anti-replay defense" is not
100% accurate.  There are other ways to improve the security.

Bill