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

[Eric Rescorla <[e-mail]>]

On Fri, Feb 19, 2016 at 4:15 PM, Dave Garrett <[e-mail]>
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 <[e-mail]>
> 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.
>

This seems to basically come down to an assessment of how likely it is that
we in fact will
have an out-of-band priming mechanism. My sense from talking to the people
most likely
to deploy such a thing is that that's not actually very likely to emerge.
Note that we're
primarily discussing what has to appear in TLS 1.3. If something like this
emerged
it can be added in a future extension.  appreciate that this is a judgement
call and for a
long time I leaned the way you are arguing, but lately I've started to feel
like the arguments
to the contrary are fairly persuasive.



> 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.
>

I don't find this argument very persuasive. The server need not store any
information at all
(because it can use tickets). As a practical matter, having the server's
config leaks the
fact that you had contacted the server just as much as having a session
ticket. We already
see this with HPKP and HSTS information and that's definitely public.

-Ekr