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

[Loganaden Velvindron <[e-mail]>]

I do not support ML-KEM only.



On Mon, 11 Nov 2024 at 22:03, Deirdre Connolly <[e-mail]> wrote:
>
> OK; what about ML-KEM only?
>
> On Mon, Nov 11, 2024, 9:58 AM Bas Westerbaan <[e-mail]> wrote:
>>
>> That was before the release of FIPS 203.
>>
>> On Mon, 11 Nov 2024 at 18:29, Deirdre Connolly <[e-mail]> wrote:
>>>
>>> Two meetings ago there was a consistent vibe in the room that Recommend'ing any PQ parameters, hybrid or no, was premature; has that changed?
>>>
>>> On Mon, Nov 11, 2024 at 9:00 AM Alicja Kario <[e-mail]> wrote:
>>>>
>>>> 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
>>>> > 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.
>>>>
>>>> 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
>>>> >      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).
>>>>
>>>> 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
>>>>
>>>> _______________________________________________
>>>> TLS mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>>> TLS mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]