Re: [TLS] AdditionalKeyShare Internet-Draft

> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Douglas Stebila
> Sent: Monday, April 17, 2017 2:24 PM
> To: <tls@ietf.org>
> Subject: [TLS] AdditionalKeyShare Internet-Draft
> 
> 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.

We have a draft with similar goals; draft-whyte-qsh-tls13 .  It also tries to achieve Quantum-safeness through multiple key exchange mechanisms; however in terms of protocol, it works somewhat differently.  You have the 'normal' key exchange (as exists in the protocol), and a second one on the side.  We allows the client to define a hybrid group (which consists of several key exchanges done in parallel).  One of our goals was to stay within the existing TLS architecture as much as possible (and thus limiting the changes needed to the TLS state machine and parsing logic); things such as modifying the key derivation mechanism (such as you do) were considered to be too large.

It may be worth your while to go through our draft,,,

> 
> 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.

Our draft allows for that naturally.

As for the need, well, I expect that some will want it.  We don't have any postquantum key exchanges that are both practical and really well trusted (at least, to the same extent that (EC)DH is); I would expect that some people will want to spread their risk and do (for example) x25519 + Frodo + SIDH.

> 
> - 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