Hi folks,
TL;DR.
Let's simplify the key schedule.
DETAILS
This is the second in a series of proposed simplifications to TLS 1.3
based on implementation experience and analysis once the protocol
starts to harden. The following suggestion comes out of conversations
with Richard Barnes, Karthik Bhargavan, Antoine Delignat-Lavaud,
Cedric Fournet, Markus Kohlweiss, Martin Thomson, Santiago Zanella and
others.
The current key schedule is elegant but it is actually more than we
need in that it allows SS to be known either before or after ES. If we
assume (as is always true in the current TLS 1.3 modes) that SS is
known before or at the same time as ES, then we can design a simpler
scheme which looks more like a ladder. Something like:
0
|
SS -> HKDF [ClientHello + Context]
| \
| \
v v
X1 0-RTT Traffic Keys *
|
|
v
ES -> HKDF [ClientHello, ServerHello]
| \
| \
v v
X2 1-RTT Traffic Keys *
|
|
v
0 -> HKDF [ClientHello...ClientFinished]
|
|
v
RMS, EMS
As should be apparent, this key schedule is well-suited to the
simplified key change schedule in my previous message.
Note 1: It might be attractive to not even bother with the first stage
if you aren't doing 0-RTT. It's not necessary then. However, this is
just an optimization. Also, if you don't want to extract an RMS or an
EMS you can skip the last stage (this is compatible).
Note 2: The IKM for the final HKDF is 0, but in principle we could use
it to add some sort of new keying material, for instance g^xs if we
were using static DH certificates (see below).
In line with Hugo's message earlier today, the major argument against
this design is that it is more oriented towards a signature-based
system, which TLS 1.3 is today, than towards a DH certificate-based
system. To elaborate on this a bit, in a DH certificate-based system,
the server authenticates by proving knowledge of g^xs (and hence
s). In the current TLS 1.3 design you can do this trivially by
replacing the signature in the server CertificateVerify with a MAC
over the transcript (using g^xs as the key) [again, analysis needed.]
This is straightforward and doesn't require rearchitecting the
protocol really at all. However, this (as with the current
signature-based mode) does not provide confidentiality of the
connection if y is later revealed.
As Hugo has noted several times, if you mix both g^xy and g^xs into
the traffic keys, then you are protected if either y or s is leaked,
which gives you somewhat stronger security properties with a DH
cetificate The current key schedule accommodates that by allowing for
SS to come before *or* after ES, but the simplified schedule does not
quite so easily.
With that said, TLS 1.3 doesn’t support *any* pure static DH design
now and will do so even less well if we remove the key change as
discussed above. There are at least three ways forward to incorporate
them in future:
- Just do as I suggest above.
- Define a new DH cipher suite that adds an additional key change.
This would allow us only to have the key change complexity in
that mode.
- Replace the 0 in the above schedule with g^xs and then define that
the key for KeyUpdate is actually coming out of the final HKDF.
Any of those seem like they wouldn’t be too hard to do, if and when
we start having a lot of demand for DH certificates.
Please discuss.
-Ekr
* Note that as I indicated in my previous message, it is possible to
generate multiple sets of keys at the same stage, if that is necessary
to handle the analysis concerns.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
