Re: [TLS] AdditionalKeyShare Internet-Draft

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