Sorry! Link to the most recent version... https://tools.ietf.org/html/ draft-whyte-qsh-tls13-04
William On Thu, Apr 20, 2017 at 1:08 PM, William Whyte <[email protected]> wrote: > 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-ke >> yshare-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
