On Tue, Jun 13, 2017 at 12:06:26PM -0700, Bill Cox wrote: > On Tue, Jun 13, 2017 at 4:32 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > Also: > > > > - Note that 0-RTT exporters are not safe for authentication unless > > the server does global anti-replay on 0-RTT. > > > I do not think this is the case. Nick Harper has proposed an RFC for token > binding over 0-RTT: >
> - 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. 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. E.g., for Triple Handshake, one can mitigate the vulernability for using the exporter outputs for authentication, but the EMS spec does not document the methods of doing this for good reasons. > 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. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
