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

[Alicja Kario <[e-mail]>]

I'd vote for "N": I worry about the security of implementations.
And I think we should steer people towards hybrids.

On Monday, 11 November 2024 19:00:01 CET, Deirdre Connolly 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 ...
>>>> 
>>>> 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 -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>> 
>>> _______________________________________________
>>> TLS mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>> 
>> 
>
>

-- 
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