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
