I think that Nico is right to identify that at its core the question for the WG is one of policy, and Dan is right to look to the WG charter for guidance.
I see two parts of the charter that could cover this work -- "[t]his goal also includes protocol changes that reduce TLS resource consumption without affecting security", and "[t]he second working group goal is to improve security, privacy, and deployability." It is a little hard to argue that this work reduces resource consumption without affecting security, which seems to be a core theme in Dan's objection to adoption. But the charter is silent about the deployability goal other than the exerpt I quote, which leaves a fair bit of room for interpretation of this work as being included in that part of the charter. I can see a case being made that this draft does improve the deployability of TLS if we start with a baseline of draft-ietf-tls-ecdhe-mlkem and note that that mechanism is not deployable in some environments (I guess, ones with some kind of strict FIPS-only requirement, though I'm not conversant in the details of such an environment). Dropping the ECDHE does then make the scheme more deployable at the cost of some risk to the security guarantees, and the magnitude of that risk is hard for me to assess. This line of argument also seems to address another one of Dan's concerns about having a way to draw the line between this algorithm and other national algorithms, especially in the context of the WG having been trying to push "national crypto" to the ISE in general. If we do have a WG-recommended scheme that is not deployable in some environments, we do have the freedom (but not the obligation) to adopt and document a variation of that recommended algorithm that is "more deployable", but that does not give us freedom to adopt arbitrary national crypto algorithms unless they are part of a WG-recommended construction that has deployability concerns that we choose to care about. WG adoption also gives us a very strong level of control over the text accompanying the protocol specification itself, including the security considerations, deployment guidance, and recommendations for (non-)use. So even if I would not use pure MLKEM myself and would recommend that others not do so as well, I can still see adopting this document as being better than having it published via ISE in that it gives us a good way to write up the caveats and risks around its use (and a chance to prohibit key reuse). Dan has argued (if I understand correctly) that we should not accept letting it get published via ISE either, but I think that is pretty hard to justify given that we have actively pushed other crypto algorithms to publish via ISE, even when we think they are bad in some sense. So if the choice is between publishing as WG document with strong caveats and disclaimer that hybrids should be preferred if they are deployable, and publishing via ISE without such caveats, I would pick the WG-document version. Whether I (or anyone else) would prefer not having the TLS SupportedGroups codepoints 512-514 defined at all or not is simply not relevant, as that is no longer a possibility. -Ben On Mon, Apr 14, 2025 at 12:02:15AM -0400, Sean Turner wrote: > !-------------------------------------------------------------------| > This Message Is From an External Sender > This message came from outside your organization. > |-------------------------------------------------------------------! > > Just a reminder that this WG adoption call closes tomorrow. > > Cheers, > spt > > > On Apr 1, 2025, at 8:58 AM, Sean Turner <s...@sn3rd.com> wrote: > > > > We are continuing with our pre-announced tranche of WG adoption calls; see > > [0] for more information. This time we are issuing a WG adoption call for > > the ML-KEM Post-Quantum Key Agreement for TLS 1.3 I-D [1]. If you support > > adoption and are willing to review and contribute text, please send a > > message to the list. If you do not support adoption of this draft, please > > send a message to the list and indicate why. This call will close at 2359 > > UTC on 15 April 2025. > > > > In response to other WG adoption calls, Dan Bernstein pointed out some > > potential IPR (see [2]), but no IPR disclosure has been made in accordance > > with BCP 79. Additional information is provided here; see [3]. > > > > BCP 79 makes this important point: > > > > (b) The IETF, following normal processes, can decide to use > > technology for which IPR disclosures have been made if it decides > > that such a use is warranted. > > > > WG members can take this information into account during this adoption call > > to determine if we should adopt these drafts. > > > > Reminder: This call for adoption has nothing to do with picking the > > mandatory-to-implement cipher suites in TLS. > > > > Cheers, > > Joe and Sean > > > > [0] > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/__;!!GjvTz_vk!SUUSF07W5ceLD8t-9ebVDShWKxztuYGUUWu-tzNJAuZErxDMARrWEAxLBBBtY4b-MNxV0NSIQQ$ > > > > [1] > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/__;!!GjvTz_vk!SUUSF07W5ceLD8t-9ebVDShWKxztuYGUUWu-tzNJAuZErxDMARrWEAxLBBBtY4b-MNyYj2GOUg$ > > > > [2] > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/__;!!GjvTz_vk!SUUSF07W5ceLD8t-9ebVDShWKxztuYGUUWu-tzNJAuZErxDMARrWEAxLBBBtY4b-MNzSNkIZ2Q$ > > > > [3] > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/__;!!GjvTz_vk!SUUSF07W5ceLD8t-9ebVDShWKxztuYGUUWu-tzNJAuZErxDMARrWEAxLBBBtY4b-MNwvr-gAnQ$ > > > > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
