Ah, got it. You're saying the Reference column would allow us to introduce other combination methods if needed, through separate defining documents. That sounds good to me as an upgrade path. Thanks!
On Thu, 28 Apr 2022 at 22:29, David Benjamin <david...@chromium.org> wrote: > I don't think the upgrade path needs any mention or changes. It's no > different from what we always do: allocate a new code point. > > Now that we've removed all the in-protocol combinator schemes from the > early versions, what remains is simply *a* method for defining a > NameGroup out of a pile of KEMs. It makes no commitment but the > tautological one: NamedGroups defined using this method will use this > method. > > The method doesn't preclude us from defining NameGroups via other > methods---after all, the existing NameGroups are defined differently > <https://datatracker.ietf.org/doc/html/rfc8446#section-7.4>. Should > someone wish to define a hybrid NamedGroup with a different combination > method (e.g. perhaps to hybrid with a KEMs that does not meet the > requirements in this document), they can simply not cite this document. > > Likewise, I don't think it's useful to extend the registry here. Any > NamedGroup, this method or otherwise, already needs a standard name (the > Description column) and a defining document (the Reference column). Those > two are sufficient to distinguish value=1234; desc=x25519_somepqscheme; > ref=[[some doc that uses this thing]] from value=5678; > desc=x25519_somepqscheme_v2; ref=[[some doc that uses a newer thing]]. > > David > > On Thu, Apr 28, 2022 at 7:19 AM Nimrod Aviram <nimrod.avi...@gmail.com> > wrote: > >> I'd like to reiterate my suggestion: While for now there is concensus for >> using concatenation to combine the two shared secrets, we should have a >> clear upgrade path if we want to use other combination methods in the >> future. >> >> As Douglas notes here [1], the document does commit to concatenation as >> the combination method. One possible upgrade path is for the relevant code >> points in the NamedGroup registry to indicate not only the key exchange >> algorithms, but also the combination method. I'm not sure whether this is >> sufficient for an upgrade path, but it seems necessary. >> >> As for the document itself, I support moving it forward. As Douglas >> noted, if we would eventually introduce a new key combination method, that >> can happen in a new document. >> >> [1] >> https://mailarchive.ietf.org/arch/msg/tls/SGyUKtTWoW9h9rX6Mo64fwfmxMY/ >> >> >> >> On Wed, 27 Apr 2022 at 18:28, Christopher Wood <c...@heapingbits.net> >> wrote: >> >>> This email commences a two week WGLC for draft-ietf-tls-hybrid-design, >>> located here: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ >>> >>> We do not intend to allocate any code points at this time and will park >>> the document after the call is complete. Once CFRG produces suitable >>> algorithms for consideration, we will then add them to the NamedGroup >>> registry through the normal process [1] and move the document forward. >>> >>> Please review the draft and send your comments to the list. This WGLC >>> will conclude on May 13. >>> >>> Best, >>> Chris, for the chairs >>> >>> [1] >>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 >>> _______________________________________________ >>> 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 >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
