On Friday, February 19, 2016 05:24:25 pm Eric Rescorla wrote: > My impression is exactly the opposite. All the infrastructure to > PSK-resumption and > hence PSK-0RTT is already in place for TLS 1.2. And of course PSK-resumption > is also much faster.
That's good to hear. The perf advantage is why I'm not advocating dropping it; merely saying that I too would prefer a single method if it didn't loose capability. Dropping PSK resumption drops less than dropping DHE 0RTT, but keeping both seems like the best option at the moment. > On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett <[email protected]> wrote: > > It would mean that TLS only has 0RTT resumption and not actually have any > > 0RTT sessions. > > Why do you think that this makes a material difference? One of the fundamental complaints about TLS, performance-wise, is the added round trip time over plaintext. That's why the WG made a point to focus on adding 0RTT in the first place. Someone considering upgrading from HTTP to HTTPS generally has this concern (or any other protocol to a variant over TLS). With only PSK resumption, we can still always have a 1RTT hit on first connection, and revert to that after the session is considered expired. With DHE 0RTT we have a longer term config that could allow for more generic caching and distribution and thus not have to get that 1RTT hit in many scenarios. The lack of a current ability to easily distribute a new config system should not be used as evidence against creating a new config system that we would want to create a way to easily distribute. Even dumping the top few dozen sites' 0RTT DHE config into a static file in a client update would be a noticeable improvement over not doing so. Coming up with a better method can come next. People should be using TLS or encryption in general as a matter of responsibility, but they don't. Softening *all* barriers to them upgrading is very necessary to get more to switch. 0RTT PSK only gets rid of a delay in continuing a session, which in some use-cases might be minimally noticeable. 0RTT DHE allows for a first-connect with comparable speed to plaintext (in scenarios where 0RTT data is safe, namely most HTTP). Within the context of HTTP, which is singled out as a focus in the TLS WG charter, 0RTT DHE will provide a more noticeable latency reduction in comparison to 0RTT PSK only. Another issue is that of privacy with session resumption. If the only way to get 0RTT is to keep sessions alive, then clearing that cache on the client side costs a future 1RTT. You can, however, cache 0RTT DHE configs safely for a longer time because they are not specific to the user agent. (we should probably narrow the spec to state that configs SHOULD NOT be per-client) In order to reliably get 0RTT without DHE configs, applications/services would need to cache PSK resumption sessions for as long as possible, which leaves a distinct per-user marker on both the client and server. Anyone trying to optimize away the 1RTT hit of first-connect will be required to maintain a system that keeps more user identifiable information than we should want. Dave _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
