Re: [TLS] Closing on 0-RTT

[Ilari Liusvaara <[e-mail]>]

On Tue, Jun 13, 2017 at 03:24:24PM -0700, Bill Cox wrote:
> 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"?

IMO, "anti-replay" also includes per-server anti-replay, which archives
"at most N replays" in global scale.

Of course, the ticket scope of server can be wider than the 0-RTT scope
(the server accepts tickets but rejects 0-RTT from any ticket in
between).
 
> 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.

If you replay ClientHello and it gets accepted twice, including to
different servers, both connections have the same 0-RTT exporter values.

The 1-RTT exporter values will not be the same, but this is not helpful
for 0-RTT data, or for that matter any 1-RTT data unless exporters are
switched mid-stream.

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

Implementing such thing without some TLS support at application layer is
just crazy.

IMO, the only reason token binding concerns itself at all with TLS is
that "0.5 RTT" (a TLS 1.3 feature) and HTTP/2 was not available when
token binding was started. Those (together with exporters) would have
enabled token binding in HTTPS without having to mess with TLS.

(The messing with TLS in token binding seems to be solely about saving
round-trips!)

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

That greatly depends on the implementation and deployment. That's why it
is more fragile.

E.g. run more than one authentication backend for 0-RTT scope, and
your application layer anti-replay breaks. And I'm not convinced the
scale of anti-replay cache would be much smaller at application layer, in
fact, it could be even biger.

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

Well, client certificates are currently forbidden for connections with
0-RTT data (indirectly, but it is still forbidden). It could become possible
in the future.





-Ilari