On Mon, Mar 14, 2016 at 4:39 AM, Eric Rescorla <e...@rtfm.com> wrote:
> 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 > Sometimes all you need is to rename a thing to make it acceptable to everyone. What should we call stateful 0-RTT resumption vs stateless 0-RTT resumption to make the difference clear? We have all been calling "0-RTT resumption" the stateless version, whether DH-0RTT or PSK-resumption based 0-RTT. Stateless PSK-resumption has all the "new and exciting" security holes. Stateful PSK-resumption is boring, just like 1-RTT. Stateless DH-0RTT and PSK-resumption is well documented in the spec, but is dangerous. Stateful PSK-resumption is not documented in any way, and appears to have been depreciated. Users who want it will have to build it as a non-standard way to use tickets, by encoding the session-ID in the ticket. All I am suggesting is to change the documentation so that the standard 0-RTT resumption mode is the safe stateful version that puts the session-ID in the ticket (and of course, drop the DH-0RTT mode). As we all know, what matters most in security is the default mode. I am suggesting making the default 0-RTT resumption mode stateful, with a documented session-ID (and let's bring back the timestamp, too, since we'll need it). Bill
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
