Re: [TLS] AdditionalKeyShare Internet-Draft

[Eric Rescorla <[e-mail]>]

I agree with David here. ISTM that if we discover that this is turning a
lot of problems,
we can presumably add an extension like the one proposed here at some later
point.

-Ekr


On Mon, Apr 17, 2017 at 4:14 PM, Benjamin Kaduk <[e-mail]> wrote:

> On 04/17/2017 02:44 PM, Douglas Stebila wrote:
>
> 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.
>
>
> You only get the combinatorial explosion if you let it happen.  A lot of
> the possible combinations wouldn't make much sense, and would not need to
> be defined.  TLS 1.3 also tries to limit the possible combinations in some
> aspects, presenting just a few good choices with clear trade-offs.
>
> 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.
>
>
> That's pushing complexity from the spec into implementations; we have a
> lot of evidence to suggest that not all implementations will get it right.
>
>
> - 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.
>
>
> I would rather leave the complexity in the NamedGroups registry.
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>