Thanks for the feedback. Responses inline below: > 1) I am a little puzzled that it is Informational, yet uses a lot of 2119 > language, in particular several MUSTs. While I believe Informational documents > can do this, I think it's relatively rare to see. Perhaps the status should be > reconsidered, or the use of such language. This document is meant to be a framework for subsequent documents that will instantiate hybrid key exchange with specific algorithms, such as draft-ietf-tls-ecdhe-mlkem, which will need 2119 language. That was my reasoning for including it here. However, not being an expert on IETF document design, I defer to the TLS chairs and others as to whether this should be revised. > 2) I also note the document states that the term 'hybrid' is used in other > contexts, and could potentially cause confusion here. I would agree that > 'composite' would be a better term to use, but a rewrite to change that would > take time and effort. The usage of the term "hybrid" in this document is consistent with how RFC 9794 uses the term hybrid, and the language in the PQ crypto adoption community also uses hybrid frequently in this sense already. If you think additional text should be added to warn the reader about the different uses of the word hybrid, I can do so, but I don't think a rewrite to globally replace "hybrid" with "composite" is desirable. > 3) The discussion around performance and latency tradeoffs of the additional > algorithms being blended is appropriate. The document could note more clearly > that the tolerance for lower performance / increased latency will depend on the > context and use case of the systems and the network involved. I've added some text to this effect in https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/48 > 4) In the backwards compatibility section, is it also possible that a client or > server may not be hybrid-aware, but two 'next generation' algorithms be in use, > with no traditional algorithm, or by definition does a 'widely deployed' > traditional algorithm have to be included? That's a good point. I've revised the text here to refer to "non-hybrid" instead of "traditional"; see https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/48 Douglas -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
