Dear TLS mailing list,
We have posted an Internet-Draft
https://tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00
for using an additional key share in TLS 1.3. The intended use case is to
provide support for transitional key exchange mechanisms in which both a
pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are used.
(Google's experiment with New Hope in 2016 had such an arrangement.) Our draft
replicates the functionality of the KeyShare extension in a new extension called
AdditionalKeyShare. Like KeyShare, the client's AdditionalKeyShare contains a
vector of KeyShareEntry structs. The server can respond with a single matching
KeyShareEntry in the AdditionalKeyShare extension of its ServerHello. The
resulting additional shared secret is included in the TLS key schedule after the
ECDH shared secret.
While the motivation for our Internet-Draft is to facilitate the transition to
post-quantum algorithms, our Internet-Draft does not specify any post-quantum
algorithms.
There are a couple of items for discussion related to this draft:
- We only provide a mechanism for a single AdditionalKeyShare, thus leading to
the session establishing at most PSK + ECDHE + 1 additional shared secret. Is
there a value in even more shared secrets than that? Will someone want
to include more than one post-quantum algorithm? If so, our draft could be
adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., but we did not
want to add that complexity unless there was desire for it.
- TLS 1.3 allows the client to restrict the use of PSKs that they provide in
ClientHello through the "psk_key_exchange_modes" extension. The client may,
for instance, request that the PSK only be used in a PSK+(EC)DHE mode, so as
to ensure that the resumed session has forward secrecy. It is unclear the
best way to reconcile this with support for multiple key shares; we outline
some possibilities in Section 4 of our Internet-Draft, and we welcome input.
We have also created a pull request to TLS 1.3 draft 19 which includes a
clarification on how additional secrets are to be included in the TLS key
schedule.
https://github.com/jschanck/tls13-spec
John and Douglas
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
