Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?

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-bounces@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 <davemgarrett@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