Re: [TLS] AdditionalKeyShare Internet-Draft

[Benjamin Kaduk <[e-mail]>]

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