I just took a look. I didn't read the (large) appendices, though I appreciate that they have value.
The draft is largely in good shape. I have a few minor concerns. I don't think that you want to reserve the hybrid_private_use(0x2F00..0x2FFF) range of values. There were specific reasons for an FFDHE range that I don't think apply if we constrain this design to TLS 1.3 and higher (as we should). The same applies to the 0x02.. prefix you suggest for the use of hybrid codepoints. I find the emphasis on the NIST process a little strong for what is a permanent artifact. It is OK to note its existence as motivation for the work, but I would avoid over-emphasis. For example: OLD: Moreover, it is possible that even by the end of the NIST Post- Quantum Cryptography Standardization Project, and for a period of time thereafter, conservative users may not have full confidence in some algorithms. NEW: Moreover, it is possible that after next-generation algorithms are defined, and for a period of time thereafter, conservative users may not have full confidence in those algorithms. and OLD: In the context of the NIST Post-Quantum Cryptography Standardization Project, key exchange algorithms are formulated as key encapsulation mechanisms (KEMs), which consist of three algorithms: NEW: This document models key agreement as key encapsulation mechanisms (KEMs), which consist of three algorithms: Please avoid "defining" codepoints, even in examples: OLD: For example, a future document could specify that hybrid value 0x2000 corresponds to secp256r1+ntruhrss701, and 0x2001 corresponds to x25519+ntruhrss701. NEW: For example, a future document could specify that one codepoint corresponds to secp256r1+ntruhrss701, and another corresponds to x25519+ntruhrss701. Finally, the use of the word "hybrid" is awkward. Maybe "composite" is a less-heavily overloaded term that accurately captures the intent; with an antonym of "unitary" or "discrete". When you talk about concatenation, it might pay to cite the relevant appendix. I would also note that the goal is that when the composed elements are not fixed-length, a length prefix might be used to ensure that both secrets contribute all of their entropy without being exposed to a weakness in the other. (You might say that the composition is injective.) Section 4 includes questions to which I think answers can be given now: *Larger public keys and/or ciphertexts.* => I think that the answer here has to be "too bad". Just note that TLS cannot handle a KEM that includes values larger than 2^16 (minus a little bit). *Duplication of key shares.* => Your existing text is sufficient to answer this one. *Resumption.* => There isn't much existing language on this point, but I don't see it as needing anything special in this draft. My view is that fresh entropy of any kind is an improvement, but generally we will see better than that because clients and servers will perform a fresh key exchange with an algorithm that they consider sufficient at the time. That might result in a change in posture relative to the original session, but the result should still be as good as min(original, current), which is always better than just using the PSK. *Failures.* => KEM failure is a problem, but I would do nothing more than note the potential and have the handshake fail. I see that the finalists have low enough error rates that this doesn't seem likely to be an issue in practice. Clients can always try again if they hit this specific problem. Ours already retries in a bunch of different failure cases. Some text on this point in the draft is probably sensible. Nits: OLD: However, the key_exchange values for each algorithm MUST be generated independently. NEW: However, key_exchange values for different algorithms MUST be generated independently. On Wed, Jul 7, 2021, at 11:19, Douglas Stebila wrote: > Dear TLS working group, > > We wanted to see if there is any further feedback on our draft "Hybrid > key exchange in TLS 1.3" > (https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/) and > what steps are required for it to advance further. We have not > received any new feedback from the working group since we posted our > last non-trivial update in October 2020. > > The draft as written does not actually specify any post-quantum > algorithms nor give identifiers for specific algorithm combinations, > only the formats for hybrid key exchange messages and key derivation. > We have received a suggestion that the draft be updated to include > identifiers for hybrid key exchange combining elliptic curve groups and > the KEMs currently in Round 3 of the NIST PQC standardization process, > so that implementations can begin testing interoperability using > numbers listed in the draft, rather than relying on ad hoc lists for > such purposes. Is that something the working group would like to see, > or would you prefer to leave it as it currently stands, without any > specific algorithm identifiers? > > Douglas, Scott, and Shay > _______________________________________________ > 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
