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

[Nick Sullivan <[e-mail]>]

On Fri, Feb 19, 2016 at 3: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.
>

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>