On Sun, Mar 13, 2016 at 9:29 PM, Bill Cox <waywardg...@google.com> wrote:
> On Sun, Mar 13, 2016 at 6:26 PM, Harlan Lieberman-Berg < > hlieber...@setec.io> wrote: > >> Bill Cox <waywardg...@google.com> writes: >> >> More generally, I strongly believe that TLS 1.3 should not >> provide options which we think should be restricted to "admins who know >> what they're doing". These end up hurting us down the line (cf EXPORT >> cipher suites.) >> >> I think we should ship the parts of 0-RTT that we believe are >> intrinsically safe for (the vast majority) of the internet to enable and >> use on day 1. >> > > This is just my opinion, not Google's. Here is a dumb idea I just had: > > The current 0-RTT modes described in TLS 1.3 are clearly only for admins > who really know what they are doing. If the current 0-RTT modes are deemed > to dangerous, then how about going back to session IDs, and doing 0-RTT > resumption from the session cache? > Isn't this more or less what we have been calling PSK-resumption? Can you explain the difference? -Ekr > This is not only fairly simple given the existing code base, but it fits > well with my personal bias towards supporting strong client authentication, > which basically got thrown under the bus in the current 0-RTT scheme. > Frankly, my current job (working on token binding) is a lot less appealing > in a world where servers cannot do proofs-of-possession with clients. With > 0-RTT cached session resumption, the TLS sequence numbers remain intact, > and we inherit the security parameters from the original connection. The > new replay attacks go away, as do most of the "new and exciting" ways to > PWN TLS 1.3 0-RTT. > > The new tickets could still be supported to enable advanced operators the > flexibility they need to implement stateless 0-RTT, but from the TLS point > of view, it would just be a 0-RTT resume using a session ID, with > additional ticket data. If the admins at a particular company want to > stuff all the session state into the ticket and accept the security > consequences of stateless 0-RTT resumption, I think they should have the > flexibility to do that. I _think_ the new tickets give them what they need. > > This would enable the standard 0-RTT resume to be as secure as keeping the > connection alive the whole time. I think it would stop this "race to the > bottom" problem people are worried about on this thread. > > So... how dumb is this idea? > > Bill > > _______________________________________________ > 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
