On Fri, Feb 19, 2016 at 3:15 PM, Dave Garrett <[email protected]> wrote:
> 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. > I don't think distributing the 0RTT semi-static DHE config for a set of top sites using a file is a realistic use case. As Eric said, for each active DH share, the server has a long-term key floating around which is a risk to PFS. Keeping these keys around for longer than the recommended 7 days is not a good practice. If the semi-static secrets are rotated at this rate, this increases the rate at which clients will have to download the configuration file. For everything other than these few dozen sites, the first connection will still be 1RTT. Clients who want 0RTT with these top sites might as well just establish a session out of band and then use 0RTT PSK. > > 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 This assumes that there is a reasonable concrete scenario for distributing the semi-static DH share. It is not clear that this use case exists. Any use case we find to distribute semi-static secrets out of band needs to handle authentication, key freshness, and provide a latency improvement over simply priming the connection with a full handshake. At the very least, we should consider removing the ServerConfiguration distribution as part of the TLS handshake. It is only useful for establishing 0-RTT in resumption connections, and there is already a method for 0-RTT resumption using PSK. Having a two ways in TLS to distribute key material to prime 0-RTT for resumed connections is redundant. > > 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 >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
