I support adoption. The question of explicitly prohibiting key share reuse is orthogonal; this can be done in a separate document.
* If someone want to do reuse, I think that should be visible… Ephemeral key reuse by the server is already visible by observing server key shares across connections. Cheers, Andrei From: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> Sent: Monday, November 11, 2024 2:21 PM To: Kris Kwiatkowski <k...@amongbytes.com>; tls@ietf.org Subject: [EXTERNAL] [TLS] Re: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 Hi, I expressed my view before this thread https://mailarchive.ietf.org/arch/msg/tls/tx0fEKDEWDYuLJlmQC8elAjW5YM/ - Note that RECOMMENDED=Y requires IETF Standards Action. I don't think any new "Supported Groups" that allows an ephemeral key to be reused in more than one key-establishment in violation of SP 800-56ar3 should be RECOMMENDED=Y. As stated by Bas, we we can't stop reuse for existing key agreements immediately. Instead, we could require this for new key agreement such as these in this document. I don't think reuse should be up to the endpoint. I would like to know that the endpoint I communicate with is not allowed too do reuse. If someone want to do reuse, I think that should be visible using something like https://www.ietf.org/archive/id/draft-rhrd-tls-tls13-visibility-01.txt Cheers, John From: Kris Kwiatkowski <k...@amongbytes.com<mailto:k...@amongbytes.com>> Date: Sunday, 10 November 2024 at 13:39 To: tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>> Subject: [TLS] Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 Hello, As discussed during the TLS session at IETF 121, we would like to propose the adoption of draft-kwiatkowski-tls-ecdhe-mlkem. There are a few open questions that need to be addressed: 1. **Alignment of NamedGroup X25519MLKEM768** with the order of shared secrets, as per Section 3.2 of draft-ietf-tls-hybrid-design. - I suggest updating the name to mlkem768_x25519, while keeping the codepoint unchanged (if that is acceptable). If this change is made, I also recommend changing the name of Secp256r1MLKEM768 to align with x25519. 2. **Changing the order of shares in Secp256r1MLKEM768**. - The current order is based on requirements from SP800-56C-r2, and it was chosen to facilitate the migration of the TLSv1.3 handshake in a flow requiring FIPS certification. Although the switched order of shares aligns with FIPS, it necessitates the re-certification of the cryptographic module. The current order supports modules that are already deployed in the field. My (slight) personal preference would be to proceed with adoption but switch the order only if NIST relaxes the requirement regarding the order of shares in SP800-56C-r2, which we know is under discussion. Otherwise, I believe the current choice better supports migration to non-hybrid MLKEM, but I would appreciate feedback on this decision (ideally from others who have a requirement for FIPS). 3. **Setting RECOMMENDED=Y for Secp256r1MLKEM768**. Additionally, we plan to register Secp384r1MLKEM1024, but I believe this should only be done once we reach a consensus regarding point 2. Thank you! -- Kris Kwiatkowski Cryptography Dev
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
