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

[Eric Rescorla <[e-mail]>]

TL;DR.
Should we remove the semi-static DHE 0-RTT mode and just leave
the PSK and PSK-DHE 0-RTT modes?


DETAIL
This is the last in the series of messages about changes to consider.

TLS 1.3 currently supports two 0-RTT modes:

- A semi-static Diffie-Hellman mode in which the server provides
  a long-term DH share and the data is protected under the client's
  ephemeral DH share and the server's long-term DH share.

- A PSK mode in which the client and server establish a shared
  key in handshake #1 and then they use that to encrypt 0-RTT
  data in handshake #2. And of course you can use tickets.
  [Note that this isn't as completely specified as one might
  like, but as there is agreement that this should work, we
  need to fully specify it. I'm working on implementing it now
  and this should help flush out issues.]

A number of people have independently observed that semi-static DHE
for 0-RTT is not clearly better than DHE-PSK for 0-RTT and suggested
that we limit 0-RTT to PSK and DHE-PSK [0], so I figured it was
something we should disuss. Obviously this is a significant
simplification, while still a big improvement over TLS 1.2-style
resumption because it allows PFS and 0-RTT.


Aside from simplicity, there are two major other considerations
here: PFS and public "priming".

PFS
In the semi-static mode, the 0-RTT client data is encrypted under g^xs
and the server's application data and any 1-RTT client app data is
encrypted under both g^xy and g^xs, so you get PFS for any 1-RTT data
but not for 0-RTT data, because as long as the server has s floating
around, there is a risk that the attacker can attack the server,
recover s, and decrypt any of the 0-RTT data.

In PSK-DHE mode, the 0-RTT data is encrypted under the shared
resumption master secret (r) and then the 1-RTT data is encrypted
under both r and g^xy, so you get PFS for any 1-RTT data
but not for 0-RTT data, because as long as the server has s floating
around, there is a risk that the attacker can attack the server,
recover s, and decrypt any of the 0-RTT data. If we assume that
the server uses tickets, then r isn't stored but encrypted under
some master key m.

They key point is that in both cases the server has a long-term key
floating around which is a risk to PFS. But the concerns are basically
the same for m and s, so you can pretty much keep them around with the
same kind of lifetime.

As Adam Langley points out, the *client* has to store a long-term
secret (r) in the DHE-PSK mode and if that is compromised, then an
attacker can decrypt the 0-RTT data and potentially mount an active
attack on future connections. This is a pretty qualitatively lower
risk from compromise of the server's long-term DHE key.


PUBLISHED CONFIGURATIONS
The semi-static mode in principle allows the server to publish its
configuration (i.e., it's semi-static key), e.g., via DNS, which the
client can then use for 0-RTT handshakes on first contact. However,
recent conversations (especially with the guys from Cloudflare) have
convinced me that this probably isn't useful: DNS TXT record
penetration rates are really bad and all the other proposed mechanisms
are also pretty problematic. For the few protocols where I was
thinking that this sort of priming was attractive, it turns out not to
work well or to have other easier workarounds.


WHAT ARE THE OPTIONS
1. Simply leave things as-is.
2. Just remove 0-RTT semi-static DHE
3. Remove 0-RTT semi-static DHE *and* 0-RTT client auth
   (on the theory that tickets let you carry it across connections).

Obviously #3 is the biggest change, but also the biggest simplification.
Both #2 and #3 are basically subsets of the existing protocol.

In addition, if we decide to make this change, we should probably
consider having some way for the client to indicate 0-RTT PSK-DHE but
force the server to do a signature (thus proving possession of the
signature key). I can think of a number of ways to design this easily,
however.

In terms of the way forward, if we can agree on a general strategy,
I'll work up proposed text.

Thanks,
-Ekr


[0] I've heard this suggested at one time or another by
Watson Ladd, Cloudflare, and the INRIA/MSR Cambridge group.