Hi John, Thanks for reporting that (again). Indeed, I was hoping this text could be added to draft-ietf-tls-hybrid-design.
Please, let me know if this text properly addresses your concern: https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/35 Cheers, Kris > On 9 Mar 2025, at 19:33, John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > Hi, > When using X25519MLKEM768, I would like to know that the other peer is not > reusing its key share (as long as it is compliant). As a server reusing a key > share can have catastrophic security consequences for the client, I think > this is a _very_ reasonable request. > https://emanjon.github.io/NIST-comments/2025%20-%20SP%20800-227.pdf > I don't care about x25519, secp256r1, etc., We are planning to support > X25519MLKEM768 as soon as possible and then disable all groups that are not > quantum-resistant as soon as possible. I also don’t care about > SecP256r1MLKEM768 and SecP384r1MLKEM1024 as we are not planning to support > them. > I don't care about what other people do. If someone want to use (semi-)static > keys for performance or visibility, that is fine with me as long as I have > the option to not communicate with such implementations. > I see three solutions: > 1. Add normative text for X25519MLKEM768, MUST NOT reuse key share. > 2. Add signaling that the key share is reused so peers have the option to > abort the connection (similar to draft-rhrd-tls-tls13-visibility). > 3. Register two different X25519MLKEM768 groups. One forbidding reuse and one > allowing reuse (similar to TLS_ECDHE_ECDSA vs. TLS_ECDH_ECDSA). > I find the current situation of key shares being reused without the other > peer knowing inacceptable and frankly the worst possible option. > As the old PRs were closed in the hope the issue was already solved and > changes to draft-ietf-tls-hybrid-design does not solve the issue unless > normatively referenced form draft-kwiatkowski-tls-ecdhe-mlkem, I opened a new > issue. > https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/issues/34 > Cheers, > John > On 2024-12-25, 07:08, "internet-dra...@ietf.org" <internet-dra...@ietf.org> > wrote: > Internet-Draft draft-kwiatkowski-tls-ecdhe-mlkem-03.txt is now available. > Title: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 > Authors: Kris Kwiatkowski > Panos Kampanakis > Bas Westerbaan > Douglas Stebila > Name: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt > Pages: 9 > Dates: 2024-12-24 > Abstract: > This draft defines three hybrid key agreements for TLS 1.3: > X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which > combine a post-quantum KEM with an elliptic curve Diffie-Hellman > (ECDHE). > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/ > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-mlkem-03.html > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-kwiatkowski-tls-ecdhe-mlkem-03 > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Kris Kwiatkowski Cryptography Dev _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
