I would also suggest keeping PSK 0RTT. On of the things I'm looking at is postquatum cryptography (that is, cryptography that would still be secure even if someone manages to build a large quantum computer). While this is not the most important issue that TLS 1.3 needs to deal with; it's probably not in the top 100; however at some point, TLS will need to deal with it, and it would be preferable if we could say "here's a minor tweak/new ciphersuite/named group we apply to TLS 1.3, and we're good to go", rather than "we need to start doing a TLS 1.4".
Here's one of the issues that I foresee; we have key exchange protocols that look postquantum, however they can't do everything that (EC)DH can; either either must be run ephemerally (that is, no static keyshares, you have to generate a fresh one for each key exchange), or the response keyshare is a function of the initiator's one (and can't be used be used in a second exchange). While such a key exchange protocol would work fine in an initial contact situation, it doesn't work out nearly as well in a DHE-0RTT protocol (which does make both assumptions). Leaving in a doorway where we don't require our cryptoprimitives to have such capabilities may, in the long run, make things easier on us. > -----Original Message----- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett > Sent: Friday, February 19, 2016 6:15 PM > To: Eric Rescorla; tls@ietf.org > Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? > > 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 <davemgarr...@gmail.com> > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
