[TLS] Re: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt

[Kris Kwiatkowski <[e-mail]>]

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=[e-mail]> 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, "[e-mail]" <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]




-- 
Kris Kwiatkowski
Cryptography Dev