Hi Ekr, Discussion on this topic is dying down, can you post a PR so we can see the proposed text. There is still some discussion on the API thread so there may be some additional modifications coming in that area.
On Wed, Jun 14, 2017 at 10:45 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Tue, Jun 13, 2017 at 03:24:24PM -0700, Bill Cox wrote: > > On Tue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara < > ilariliusva...@welho.com> > > 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
