Hi, Thanks for this draft, which I found interesting and readable. I think it lays out the problem well and proposes a conceptually straightforward solution that will hopefully be less prone to implementation errors than more complex options. However, there are a few points that I think need further time and/or explanation before a final WGLC. 1. It keeps coming up, but the terminology in the draft should be tightened to make it internally consistent, as well as to align it with the LAMPS hybrid drafts (and any future PQ hybrid drafts). In particular: * "Constituent" and "component" algorithms are both used to mean an algorithm that is part of a hybrid. * "Traditional" and "classical" algorithms are both mentioned. I'm not sure if this distinction is intentional. * "Composite" is used here as a synonym for hybrid, whereas in the LAMPS drafts composite solutions are particular types of hybrids. 2. There are several points in the draft where properties of, or restrictions on KEMs, are mentioned but it's not clear whether this applies to all KEMs, just to the next-generation KEMs, or just to the NIST Round 3 candidates. I think it's important to clarify this, drawing a distinction between post-quantum and classical KEMs (specifically FFDH and ECDH modelled as KEMs) as well as between general next-generation KEMs and the NIST Round 3 candidates. 3. As you say in section 2, IND-CPA and IND-CCA2 security of KEMs relies on the generated shared secret being indistinguishable from random, but this is not necessarily the case (e.g. for DH modelled as a KEM as described in this draft). Is it an assumption that the KEMs are indistinguishable from random? If so, this should be stated up front and discussed in the security considerations. If not, then some of the analysis should take this into account (e.g. the results from [BINDEL] referenced in the first paragraph of section 6 do not apply as expected when using this draft's description of DH as a KEM). 4. Related to the above, the description of DH as a KEM in section 2 does not match DHKEM from RFC 9180 (which it points to) as it's missing the final key derivation step. What's the intended behaviour here? 5. I wasn't clear on the restrictions for repeating key_exchange values between different hybrids with a shared component algorithm, or in the case where a component algorithm of a hybrid is also offered on its own. Does it have to be the case that the key_exchange value for Algorithm A is the same wherever it is used? Or is it allowed but not mandated? Let me know if there's anything it would be helpful to expand on here and I look forward to seeing how this draft progresses, Flo Florence D (she/her) UK National Cyber Security Centre
This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfo...@ncsc.gov.uk. All material is UK Crown Copyright © -----Original Message----- From: TLS <tls-boun...@ietf.org> On Behalf Of Christopher Wood Sent: 27 April 2022 16:27 To: TLS@ietf.org Subject: [TLS] WGLC for draft-ietf-tls-hybrid-design This email commences a two week WGLC for draft-ietf-tls-hybrid-design, located here: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tls-hybrid-design%2F&data=05%7C01%7CFlorence.D%40ncsc.gov.uk%7C817e9a7a562b4c05490008da286a4e99%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637866734869729134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=kIKYy%2FMSdDSoeU2B7oAmXQCV8ayAILkwww8Xr3BjbP0%3D&reserved=0 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Ftls-parameters%2Ftls-parameters.xhtml%23tls-parameters-8&data=05%7C01%7CFlorence.D%40ncsc.gov.uk%7C817e9a7a562b4c05490008da286a4e99%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637866734869729134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=PEEzd855q7nqAo8Lzy70YFWecmzEI2FWJfwE7FDSWow%3D&reserved=0 _______________________________________________ TLS mailing list TLS@ietf.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7CFlorence.D%40ncsc.gov.uk%7C817e9a7a562b4c05490008da286a4e99%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637866734869729134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=siqYjvV2uEF%2F9VvHXn4m58lDsD4FYJW4xGC86CXG4%2FQ%3D&reserved=0 This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfo...@ncsc.gov.uk. All material is UK Crown Copyright © _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
