PR up: https://github.com/tlswg/tls13-spec/pull/1034
On Fri, Jun 23, 2017 at 9:21 AM, Joseph Salowey <j...@salowey.net> wrote: > 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
