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

On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner <sean@sn3rd.com> wrote:

> All,
>
> To make sure we’ve got a clear way forward coming out of our BA sessions,
> we need to make sure there’s consensus on a couple of outstanding issues.
> So...
>
> 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,

I am not offering an opinion about what the WG should decide regarding
keeping
DHE-based 0-RTT in the base TLS 1.3 document, but just wanted to note that
the
above claim "The security properties of PSK-based 0-RTT and DHE-based 0-RTT
are
almost identical" is not quite right (nothing I say here is new, I just felt
that I had to "object" to this statement as written).

There are some significant differences - in some cases even "fundamental
differences" - between keeping secret state (in the PSK case) and keeping
non-secret state (in the DHE case) or even not keeping state at all (in the
DHE case) and retrieving the server key g^s from some external source (with
integrity but not secrecy).  In addition, using DHE 0-RTT would require the
client to send a key share g^x leading to a PFS 1-RTT exchange while with
PSK
it may be "tempting" to omit PFS.  Moreover,  if the server's configuration
key g^s is refreshed often (say each 5 minutes) then the g^xs key used by
the
client to protect its 0-RTT data already has some good level of forward
secrecy (the attacker has a 5 minute window to find s and after that forward
security is guaranteed).  The latter point touches on an important aspect
which is the key management complexity of ticket encryption/decryption keys
(as needed in the PSK case) vs managing secret DH key s (in the DHE case).
I am not sure what would be done better (more secure) in practice.

But really it seems that the discussion boils down to identifying cases of
enough interest where avoiding the original 1-RTT trip for establishing a
session ticket is important. I am puzzled by the fact that the Google team
seems ok with something that essentially voids the main feature and design
basis of of QUIC.

Hugo

> 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.
>
> If you think that we should keep DHE-based 0-RTT please indicate so now
> and provide your rationale.
>
> J&S
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>