Thanks Martin. All makes sense, and I'll incorporate in a revision. Though at this point changing the word "hybrid" to "composite" would be a rather big rewrite so I'll omit that unless there are very strong objections to the word hybrid.
Douglas > On Jul 6, 2021, at 21:53, Martin Thomson <m...@lowentropy.net> wrote: > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
