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.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
