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

[Bas Westerbaan <[e-mail]>]

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