Hello,
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.
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
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).
> 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.
With that I hope the draft is ready for adoption.
Any feedback is more then welcome.
Kind regards,
Kris
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
