Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

[Ryan Hamilton <[e-mail]>]

On Tue, Mar 29, 2016 at 10:14 AM, Wan-Teh Chang <[e-mail]> wrote:

> On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner <[e-mail]> wrote:
> >
> > There also seems to be (rougher) consensus not to support 0-RTT via DHE
> > (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT
> mode
> > as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT
> > are almost identical, but 0-RTT PSK has better performance properties and
> > is simpler to specify and implement. Note that this does not permanently
> > preclude supporting DHE-based 0-RTT in a future extension, but it would
> > not be in the initial TLS 1.3 RFC.
>
> This will remove a feature from the QUIC protocol, so I'd be
> interested in hearing the QUIC team's opinion.
>
> Since DHE-based 0-RTT is already specified in the TLS 1.3 draft, I'm
> not sure if "simplier to specify" should be an important factor.
> However, "simpler to implement" is an important consideration. I am
> curious to know how we concluded that 0-RTT PSK is simpler to
> implement. Did anyone implement both 0-RTT modes and can compare the
> difficulties?
>
> As for 0-RTT PSK having better performance, that comes at the cost of
> a previous full handshake with the server. Also, TLS 1.3 clients that
> want to do 0-RTT PSK across an application shutdown will need to deal
> with the harder problem of storing PSKs persistently.
>

​We've talked about losing DHE 0-RTT within the team, and have concluded
that PSK resumption should be an acceptable alternative. As you suspected
however, we have not implemented ​PSK resumption and are instead waiting
until we have a TLS 1.3 implementation which supports it which we will use
in QUIC.

Since Chrome does not persist the TLS session resumption cache to disk, we
will likely lose 0-RTT across browser restarts, which is a bit of a bummer.
It's probably not too bad, but it does likely suggest we'll need to come up
with something more complex for mobile.