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