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
