Re: [TLS] AdditionalKeyShare Internet-Draft

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) <
sfluhrer@cisco.com> wrote:

>
> > -----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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>