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
