On Thursday, February 18, 2016 08:04:05 pm Eric Rescorla wrote: > PUBLISHED CONFIGURATIONS > The semi-static mode in principle allows the server to publish its > configuration (i.e., it's semi-static key), e.g., via DNS, which the > client can then use for 0-RTT handshakes on first contact. However, > recent conversations (especially with the guys from Cloudflare) have > convinced me that this probably isn't useful: DNS TXT record > penetration rates are really bad and all the other proposed mechanisms > are also pretty problematic. For the few protocols where I was > thinking that this sort of priming was attractive, it turns out not to > work well or to have other easier workarounds. > > WHAT ARE THE OPTIONS > 1. Simply leave things as-is.
Nobody has enough of a reason to have support for DNS records that can do this, yet. Adding it here could change the situation over time. More importantly, some major sites/services might even want to just cut out the middle-ware and dump 0RTT configs into a client synced list of some sort, akin to how some handle HPKP. Not the most elegant of systems, but it would let clients that use such a list have out-of-the-box 0RTT to major high-traffic sites. Ad hoc systems would also be able to preload for 0RTT for their services easily (e.g. make an app & include 0RTT config cache with it). Even for clients merely getting their config via a first connection, we might be more likely to be able to cache for DHE safely longer than just for PSK for every client. I think it's a feature worth keeping. Dave _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
