[TLS] Re: [EXTERNAL] Re: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Kris Kwiatkowski <[e-mail]>]

Hello,

The code point for	SecP384r1MLKEM1024	 has been registered.

Please see 
https://www.iana.org/assignments/tls-parameters

Happy New Year,
Kris


On December 11, 2024 2:38:59 PM GMT+01:00, Bas Westerbaan <[e-mail]> wrote:
>Following the feedback from the last TLS meeting at IETF@121, I have opened
>> this PR to change the name from X25519MLKEM768 to MLKEM768X25519. This
>> change aligns with draft-ietf-tls-hybrid-design-11 (section 3.2).
>>
>> https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/26
>>
>
>I don't believe there was consensus to swap (or keep) the name.
>X25519MLKEM768 has already been assigned and deployed under that name.
>
>
>> 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).
>>
>> According to the message from
>> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ST_yMzYyMl0, NIST
>> plans to permit the ordering of shares in either direction. This approach
>> addresses the previously mentioned issue, so no further changes are needed
>> in this regard. I believe it is now appropriate to register an additional
>> code point for Secp384r1MLKEM1024, as currently outlined in the draft.
>>
>>
>> 3. **Setting RECOMMENDED=Y for Secp256r1MLKEM768**.
>>
>> I think this can only be done once draft if adopted. Hence, no change here
>> (for now).
>>
>
>Agreed.
>
>
>> > On 11/11/2024 23:14, Andrei Popov wrote:
>> > I support adoption. The question of explicitly prohibiting key share
>> reuse is orthogonal; this can be done in a separate document.
>> I agree that the PR was submitted to change the text in the draft, but I
>> think it would be better to include this text in
>> draft-ietf-tls-hybrid-design. I have opened this PR
>> https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/39.
>>
>
>LGTM.
>
>> With that I hope the draft is ready for adoption.
>>
>
>Ageed.
>
>Thanks Kris,
>
> Bas