[TLS] Re: The TLS WG has placed draft-connolly-tls-mlkem-key-agreement in state "Call For Adoption By WG Issued"
I support adoption. I don't think we having a (non-recommended!) scheme available that does not support hybrids is a problem, there are legitimate reasons to want that kind of key exchange, and as time progresses, non-hybrid key exchanges will become more and more commonplace, so why not have it already defined? Note that the draft as is does not recommend reusing keys, but rather notes that TLS does not disallow this option, and that the scheme therefore MUST be IND-CCA. That is simply an accurate security observation, and the flaw lies with TLS 1.3, not this draft. On Wed, Apr 2, 2025 at 2:57 AM Martin Thomson wrote: > I think that adoption is fine. I might oppose the registration of a > codepoint that was Recommended: Y for reasons similar to what Stephen > described, but we can talk about that. > > On Tue, Apr 1, 2025, at 23:58, IETF Secretariat wrote: > > The TLS WG has placed draft-connolly-tls-mlkem-key-agreement in state > > Call For Adoption By WG Issued (entered by Sean Turner) > > > > The document is available at > > https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/ > > > > > > ___ > > 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 > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschm...@google.com ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Dnsdir telechat review of draft-ietf-tls-esni-24
Reviewer: R. Gieben Review result: Ready Hello, I'm the designated reviewer from dnsdir for this draft. I've reviewed -23 and looked at the diff with -24. My previous comments/nits are fixed in version -24, thus ready from that perspective. Regards, Miek ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3
The IANA codepoints allocated in the current draft are all 'Recommended: N' On Tue, Apr 1, 2025, 8:59 PM Martin Thomson wrote: > Like other pure ML-KEM uses, I am OK with adoption, though I might oppose > Recommended: Y when it comes to that. I also share John's concerns about > key reuse, but would prefer to litigate that in the working group, rather > than during adoption. > > On Tue, Apr 1, 2025, at 23:58, Sean Turner 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://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/ > > [1] > https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/ > > [2] > https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/ > > [3] > https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/ > > > > ___ > > 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 > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3
Sean Turner 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. Like others, I'd like to see reuse of ephemeral keys be prohibited, but also believe that that should not hinder immediate progress in adopting the draft. I believe that adopting the draft will allow those who wish to use pure PQC (for whatever reasons they may have) to do so while at the same time not in any way impacting anybody else who doesn't want to do that. Ergo: I support adoption. -Jan ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3
> rather than a safer hybrid As a coauthor on hybrid publications and I-Ds, I do not agree that hybrids are categorically safer. The -tls-hybrid-design for hybrids is pretty great... if you use secure component algorithms. On Wed, Apr 2, 2025, 12:24 PM Bellebaum, Thomas < thomas.belleb...@aisec.fraunhofer.de> wrote: > > I believe that adopting the draft will allow those who > > wish to use pure PQC (for whatever reasons they may > > have) to do so while at the same time not in any way > > impacting anybody else who doesn't want to do that. > > Those who wish to use pure PQC do not need permission. This is about IETF > _endorsement_. > > Even with Recommended=N, I can imagine many managers reacting to a > presentation on "YOU NEED TO USE PQC LIKE ML-KEM BECAUSE ELSE..." by > googling "deploy ML-KEM now" and being recommended this rather than a safer > hybrid[1]. I am not convinced that such a person, if given more knowledge, > "doesn't want to do that". > > Not everyone using TLS is a cryptographer knowing the implications of > their algorithm choices by heart. > > -- TBB > > [1] After all, the manager was told to deploy MLKEM, not this suspicious > X25519MLKEM, whatever scam that must surely be. > ___ > 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
[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3
> I believe that adopting the draft will allow those who > wish to use pure PQC (for whatever reasons they may > have) to do so while at the same time not in any way > impacting anybody else who doesn't want to do that. Those who wish to use pure PQC do not need permission. This is about IETF _endorsement_. Even with Recommended=N, I can imagine many managers reacting to a presentation on "YOU NEED TO USE PQC LIKE ML-KEM BECAUSE ELSE..." by googling "deploy ML-KEM now" and being recommended this rather than a safer hybrid[1]. I am not convinced that such a person, if given more knowledge, "doesn't want to do that". Not everyone using TLS is a cryptographer knowing the implications of their algorithm choices by heart. -- TBB [1] After all, the manager was told to deploy MLKEM, not this suspicious X25519MLKEM, whatever scam that must surely be. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3
I support adoption. I also would like to prohibit key reuse, but opposing adoption feels like a bad way to reach that outcome: if the document is published by the ISE or just lives on as a widely deployed draft, the WG will have no say in what requirements it has. It also seems clear to me the WG consensus will be for the codepoints to remain "Recommended: N" at least for now. Opposing adoption to force the document to be published in a way that can't be "Recommended: Y" feels like (unnecessarily) meta-gaming the IETF process. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3
2025-04-02 17:39 GMT+02:00 Salz, Rich : > Opposing adoption to force the document to be published in a way that can't > be "Recommended: Y" feels like (unnecessarily) meta-gaming the IETF process. > > I am not aware of any of those opposed who are doing it for this reason. > Perhaps speculating on their reasons isn’t a good thing to do? I interpreted at least one opposing statement in the sibling thread as expressing a preference for the ISE for this reason, but I chose to address the concern (Recommended Y or N) and not the individuals. If I misinterpreted, then great: my argument is a non-sequitur that applies to no one.___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3
> I believe that adopting the draft will allow those who > wish to use pure PQC (for whatever reasons they may > have) to do so while at the same time not in any way > impacting anybody else who doesn't want to do that. Those who wish to use pure PQC do not need permission. This is about IETF _endorsement_. Endorsement is based on many factors. ..." by googling "deploy ML-KEM now" and being recommended this rather than a safer hybrid[1]. I am not convinced that such a person, if given more knowledge, "doesn't want to do that". This assumes that “more knowledge” must lead to “don’t do ‘pure’”. Which is “purely” wrong – there are several aspects of a solution that contribute to or detract from “safety”, and the theoretical truism of “combination of different (independent) algorithms is generally stronger” is merely one – not even the biggest – part of it. Deirdde> As a coauthor on hybrid publications and I-Ds, I do not agree that hybrids are categorically safer. The -tls-hybrid-design for hybrids is pretty great... if you use secure component algorithms. Deirdre is absolutely correct. And even when the components are strong now – remember that the key (no pun intended) point of this exercise is to deal with CRQC, which will make all of the Classic components immediately useless. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3
I support adoption of pure PQC KEMs drafts with Intended status: Informational (meaning that the IETF is not recommending using). Any IPR that can be asserted against Kyber can be asserted against already adopted hybrid methods incorporating Kyber. If anything, one may attempt to argue that hybrids do not implement NIST's MLKEM scheme and are thus not covered by the NIST licenses. Y(J)S -Original Message- From: Sean Turner Sent: Tuesday, April 1, 2025 8:58 AM To: TLS List Subject: [TLS] WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3 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://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/ [1] https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/ [2] https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/ [3] https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/ ___ 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 This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
