On Sunday, 10 November 2024 13:38:38 CET, Kris Kwiatkowski wrote:
Hello,
As discussed during the TLS session at IETF 121, we would like
to propose the adoption of draft-kwiatkowski-tls-ecdhe-mlkem.
Very much in favour of adopting this draft.
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 ...
while I'd /like/ for the name to remain, I'm not opposed to changing it,
especially if we make it so that the order in the name matches the order
in the shares and derived secrets
(I've already seen names all over the place for the codepoint, so the
name isn't consistent across different implementations already...)
no preference for mlkem768_x25519 vs MLKEM768X25519 vs mlkem768x25519
OTOH, if NIST doesn't change their stance, then having name
represent the
order, and there still being interest in hybrid at a time when P-256 and
P-384 are not approved, would give a clear description for
the new point,
new name, with the order reversed
Given how widely it is already deployed, I'm very strongly opposed to
changing the codepoint or its meaning.
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 ...
I'm opposed to changing the order. The way it is right now
(for all three
codepoints) is good. Especially speaking as a vendor intersted in FIPS
compliance.
Even *if* NIST relaxes the requirements, we don't know *when* that will
happen.
We have explicit confirmation that as long as the first algorithm is
FIPS approved, then the whole SP800-56Cr2 scheme is, so I
think, for FIPS
compliance, we're good.
If in the future it will turn out that we want a hybrid with ML-KEM-1024
first, registering it won't be too much work.
(Or NIST may say that ML-KEM is fine as the second one iff the first
shared secret was "formely NIST approved algorithm", we don't know.)
And even without it, we already have codepoints for pure ML-KEM of all
sizes.
So, I think the three codepoints are the minimal set to handle:
* the general Internet
* FIPS compliance
* Common Criteria Protection Profile compliance
with as little friction to roll them out as possible.
I think this is the main thing we should have in mind: we want people
using PQC key exchanges as soon as possible as widely as possible.
3. **Setting RECOMMENDED=Y for Secp256r1MLKEM768**.
Since all three (secp256r1, secp384r1, and x25519) are RECOMMENDED=Y,
I think we should set "Y" for those three algorithms too.
Additionally, we plan to register Secp384r1MLKEM1024, but I
believe this should only be done once we reach a consensus
regarding
point 2.
Thank you! ...
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
<https://www.google.com/maps/search/Purky%C5%88ova+115,+612+00,+Brno,+Czech+Republic?entry=gmail&source=g>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
