Re: [TLS] AdditionalKeyShare Internet-Draft

[Douglas Stebila <[e-mail]>]

Hi David,

Thanks for the feedback.

> This seems overly complicated. Why implement a parallel key share mechanism rather than merely defining a new NamedGroup value?
> 
> Using your example of Google's recent New Hope experiment, I would imagine defining, say, NamedGroup.cecpq1. Let its key_shares be the concatenation of New Hope and X25519 public values, and let the resulting shared secret be some combination of the two resulting keys.
> 
> This avoids changing the key schedule or protocol logic and slots in nicely into the existing arrangement. The AdditionalKeyShare proposal has more moving parts and combinatorial combinations to test and worry about.

Defining combined NamedGroups, like in the Google New Hope experiment, also incurs a combinatorial explosion, this time in the number of NamedGroups.  Given that TLS 1.3 has taken the approach of splitting off each component of a TLS 1.2 ciphersuite into its own negotiable component to avoid combinatorial explosion in standardized values, separately negotiating each parallel key share mechanism seemed to us to follow the TLS 1.3 design approach.

> It also requires implementations answer silly questions like:
> - What happens the server selects two New Hopes with no X25519? X25519 and P-256 together?

In our draft, KeyShare and AdditionalKeyShare form disjoint pools of NamedGroups from which one element can be selected.  If the client offers say P256 and X5519 in KeyShare and NewHope in its AdditionalKeyShare, your first problem cannot happen.  If the client offers NewHope in both pools, then the situation you propose could happen.  This does not negatively impact compatibility or security, although there is obviously no value in doing two NewHopes compared to a single NewHope.  I don't think we've put in a MUST NOT/SHOULD NOT here, but we could add that.

> - What happens if the client offers New Hope in the normal key shares slot and X25519 in the additional one?
> - What happens if the client only offers New Hope and not X25519?

This is fine from the draft's perspective.  If the client does so and then interacts with a non-NewHope-compatible server that only speaks X25519, the connection would fail because the KeyShare slot contains no mutually compatible key shares.

> - How does a client express that it's not willing to do New Hope without ECDH?  What if the server sends a HelloRetryRequest for New Hope in the main slot and does not select X25519?

The server must pick exactly one NamedGroup from the KeyShare pool, and at most one NamedGroup from the AdditionalKeyShare pool.  The client could put ECDH in KeyShare and NewHope in AdditionalKeyShare to indicate this desire; the server would then have to use ECDH from the KeyShare slot and could optionally use NewHope from the AdditionalKeyShare slot.

If the client wants "ECDH (KeyShare) and NewHope (AdditionalKeyShare)" and the server says "retry with NewHope (KeyShare)", the client has the option of retrying with "NewHope (KeyShare) and ECDH (AdditionalKeyShare)".  If the server rejects, then the client knows its policy cannot be satisfied, and it should not continue.  If the server continues with NewHope but discards the AdditionalKeyShare (as it's allowed to do in our draft), the client learns the server is unwilling to satisfy its policy, and the client can drop the connection.

> - How can I plausibly expose this complex array of options to the consumer of my TLS library?

Yes, there is a complex array of options:
- which algorithm(s) the client views as "must have"
- which algorithm(s) the client views as "would like to have"
- which algorithm(s) should/should not happen at the same time

If this functionality is encapsulated anywhere in TLS, then that complexity needs to incorporated somewhere, either already in compound NamedGroups or in configuration of the parallel key share mechanism.  As I mentioned above, we thought that combinatorial explosion of NamedGroups was not the TLS 1.3 way.  However, we are open to considering that if there's a clear preference for it.

Douglas

> 
> 
> On Mon, Apr 17, 2017 at 2:23 PM Douglas Stebila <[e-mail] <mailto:[e-mail]>> wrote:
> Dear TLS mailing list,
> 
> We have posted an Internet-Draft
>     https://tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00 <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.
> 
> 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.
> 
> - 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 <https://github.com/jschanck/tls13-spec>
> 
> John and Douglas
> 
> _______________________________________________
> TLS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>