Link to that draft: https://tools.ietf.org/html/draft-whyte-qsh-tls13-02
Cheers, William On Wed, Apr 19, 2017 at 2:42 PM, Scott Fluhrer (sfluhrer) < [email protected]> wrote: > > > -----Original Message----- > > From: TLS [mailto:[email protected]] On Behalf Of Douglas Stebila > > Sent: Monday, April 17, 2017 2:24 PM > > To: <[email protected]> > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
