> > Section 7, paragraph 0 > > This document requests/registers three new entries to the TLS > > Supported Groups registry, according to the procedures in Section 6 > > of [tlsiana]. These identifiers are to be used with the final, > > ratified by NIST, version of ML-KEM which is specified in > > [NIST-FIPS-203]. > > Thanks to Dale Worley for his GENART review. One of the questions he asks > is > about the Recommended value of N. He references the IANA section that says: > > If the "Recommended" column is set to "N", it does not necessarily > mean that it is flawed; rather, it indicates that the item either > has not been through the IETF consensus process, has limited > applicability, or is intended only for specific use cases. [...] > > To which the authors' response was that it was discussed on the mailing > list > and agreed that it should be kept N. However, the document does not seem to > have captured what the discussion was and whether the three entries have > limited applicability or are intended only for a specific use case, etc. >
Thanks for pushing on this. In the motivation section we discuss the particularities of the three groups to aid the reader. Quoting: - The first one uses X25519 [rfc7748 <https://www.ietf.org/archive/id/draft-ietf-tls-ecdhe-mlkem-03.html#rfc7748> ], is widely deployed, and often serves as the most practical choice for a single PQ/T hybrid combiner in TLS 1.3. - The second group uses secp256r1 (NIST P-256). This group supports use cases that require both shared secrets to be generated by FIPS-approved mechanisms. - The third group uses secp384r1 (NIST P-384). This group is intended for high-security environments that require FIPS-approved mechanisms with an increased security margin. There is no agreement on how this should influence the recommended column (yet). An incomplete list of (potentially controversially paraphrased) arguments and further considerations mentioned, - We should not care about any national standards [1] cf [14] - We should care about national standards [10]. - We should not recommend crypto at the P-256 / X25519 level. [2] - We expect both P-256 and X25519 variants to be widely supported [3] - We don't expected both P-256 and X25519 variants to be widely supported [4], cf. [7] - Fragmentation is bad (also because of HRR) [4] [9] [12], cf [7] - We should make these decisions as a separate effort and not when defining each new group [5] [9] [17] [19] - Regulators don't interpret these columns correctly, so better set them to Y. [6] - Regulators don't care about the column. [13] - P256 and X25519 add important diversity in security [8] - P256 and X25519 don't make a big difference. [4] - Hybrid is weaker than non-hybrid [11] - P256 is recommended and soon MTI, so better be consistent with that. [15] [16] - We should not be consistent just to be consistent giving evolving understanding [18] - The recommended flag is not important in practice. [17] I think most of these are out of scope for the document. I also believe the current motivation is helpful. Do you think we should add one of these specifically? Best, Bas [1] https://mailarchive.ietf.org/arch/msg/tls/5LMR6kxLiBfpaPo6YUQZ3b9khhQ/ [2] https://mailarchive.ietf.org/arch/msg/tls/Wc0tnrJX0AwMnjBspeM3pxCwEoU/ [3] https://mailarchive.ietf.org/arch/msg/tls/FK6fpPv4ZWtgkrfftNGuaP-c6Lo/ [4] https://mailarchive.ietf.org/arch/msg/tls/c5gEMi7Lv6glU-8dKEulz_X9FbI/ [5] https://mailarchive.ietf.org/arch/msg/tls/A3rMGGlJKSOvMhRy-NGfPzcpzkU/ [6] https://mailarchive.ietf.org/arch/msg/tls/5uako9hyThq-UJ70yaaNTWY-ETY/ [7] https://mailarchive.ietf.org/arch/msg/tls/6qZXbljE7mGmpsYeFVJf221UD9U/ [8] https://mailarchive.ietf.org/arch/msg/tls/eKWxJUTNKHLtg1uKKglDQ6aseSw/ [9] https://mailarchive.ietf.org/arch/msg/tls/2TZ0m26vA4Rx50hWT0xqUZA7xiI/ [10] https://mailarchive.ietf.org/arch/msg/tls/N5PL9yvjPvPxSw9MFf0xNwTTyrw/ [11] https://mailarchive.ietf.org/arch/msg/tls/3fGgU5jtXXivZUDCLQWaMOTqP5Q/ [12] https://mailarchive.ietf.org/arch/msg/tls/6Wmx_QE0K1d1mqN3jHj4tlTIvQE/ [13] https://mailarchive.ietf.org/arch/msg/tls/2ujX76TTwwLWeSwTOG_t6BwxRug/ [14] https://mailarchive.ietf.org/arch/msg/tls/Yul6hw0gD-48n4CjCOthafKZ7Rc/ [15] https://mailarchive.ietf.org/arch/msg/tls/wVmtruv0lnteKcrEcelPenp50YA/ [16] https://mailarchive.ietf.org/arch/msg/tls/bM1LCowwffAw25AprGC54sTfiDQ/ [17] https://mailarchive.ietf.org/arch/msg/tls/anqTfO9uoZXfHTOeiV1wZOm1GVo/ [18] https://mailarchive.ietf.org/arch/msg/tls/U1KfwAwbLnlLyyW_dJOkNfmvex8/ [19] https://mailarchive.ietf.org/arch/msg/tls/NmSPaL0DzwRhomq-lk_uxmo5C-U/
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
