Hi folks,
TL;DR.
I propose that we should not change keys between the handshake
and application traffic keys.
DETAILS
As we try to finalize the drafts and implementations are starting to
emerge, it's worth looking for opportunities to simplify. This is the
first of several messages suggesting areas where we may have made
things too general/complicated and now that we can look at
simplifying. The following suggestion comes out of conversations with
Karthik Bhargavan, Antoine Delignat-Lavaud, Cedric Fournet, Christian
Huitema, Markus Kohlweiss, Martin Thomson, Santiago Zanella and
others.
The general idea is that there is no strong security reason to change
change keys between handshake and traffic in the same phase (e.g.,
between the 1-RTT handshake and traffic keys, so we should simplify by
not doing so.) This is something that implementers have asked for,
especially for DTLS (so you don't need to have three contexts in one
flight) and we have resisted, nominally for security reasons but
really over concerns about analysis.
There are three basic security reasons why one might want to change
keys:
- To add additional secret information.
- To bind in additional context.
- For PFS.
None of these apply at the handshake/traffic transition: We don’t have
any more secret material at this point in TLS 1.3 (SS and ES are both
known at the time that the handshake keys must be generated.) It is
not necessary to bind in the additional context to the traffic keys
(though see below about resumption) because it is tied to the keys
via the Finished messages. We know how to do security proofs
for this (those exist for 1.2). There’s no reason to have different
PFS for the handshake versus the application traffic.
We can simplify matters by adopting a schedule more like the following:
Key Class Input Handshake Context Specific
Secrets /Transcript Keys
---------------------------------------------------------------------------------
0-RTT Keys SS ClientHello + client write keys
ServerConfiguration + client finished keys
ServerCertificate +
CertificateRequest
1-RTT Keys SS, ES ClientHello, client/server write
keys
ServerHello client/server
finished keys
Final Keys SS, ES Complete transcript
through client finished exporter master
secret
resumption master
secret
[Maybe
traffic_secret_1]
Note that it is very important that the Resumption Master Secret
include the server certificate (otherwise you get Triple Handshake)
but you shouldn'tt need that for the initial handshake traffic keys.
This is clearly simpler and also has the advantage that you do fewer
expansions with different combinations of transcript messages. It's
a very simple change to the specification and to implementations.
It also allows a somewhat simpler key schedule (see the next message
in this series).
There are two potential objections here:
- It’s a change, how do we know it’s OK?
- Doesn’t this make analysis harder?
There are intuitive reasons to believe that it is OK (this is very
similar to what TLS 1.2 does with the resumption secret being derived
as with Extended Master Secret), and there are teams actively adapting
their analysis to verify that they are OK. Obviously, it might not be
OK and we should not finalize this change until we have some analysis.
I'll let Karthik, Cedric, etc. speak to the progress on that and
perhaps we can discuss more at TRON.
There is a sense in which it makes analysis harder in that the
cryptographic (as opposed to symbolic) proofs are better adapted to
assuming that the keys being output by the handshake are never used
for any handshake purpose. However, there are techniques for making
this work with plausible assumptions about how TLS will use the keys
(mainly that only TLS will be allowed to send traffic with the TLS
internal keys and that everything else will only get access to
Exported keys) [1].
One more important note: for DHE-PSK mode, it is important to have the
traffic encrypted under both SS and ES (I.e., both PSK and DHE) but
that’s not presently true for the handshake data (which is only
encrypted under ES). So, this will also require at least some change
to the key schedule to accommodate that. However, those changes are
relatively straightforward.
Comments, please.
-Ekr
[1] Another alternative here would be to generate separate keys for
handshake and application traffic but do so at the same time, so that
there is only one derivation stage. This simplifies the specification
and implementation somewhat, but not as much as having handshake
and application traffic.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
