[CFRG] Re: ML-KEM for HPKE: just use seeds

[Deirdre Connolly <[e-mail]>]

As per the meeting today, just re-surfacing this for the group:

https://datatracker.ietf.org/doc/draft-connolly-cfrg-hpke-mlkem/04/

and if there's good vibes, I'll go request the codepoints:

0x40 - ML-KEM-512
0x41 - ML-KEM-768
0x42 - ML-KEM-1024

And the only thing this really requires beyond FIPS 203 is that the 64-byte
decapsulation key format is a MUST, which is in alignment with other ML-KEM
work in IETF right now (such as lamps-kyber-certificates)

On Mon, Oct 14, 2024 at 9:58 PM Deirdre Connolly <[e-mail]>
wrote:

> With help from Rohan, we have pushed version -03, which removes the
> confusing language about KDFs and AEADs and chooses different codepoints in
> the HPKE KEMs Registry (now 0x0040, 0x0041, and 0x0042):
>
> https://datatracker.ietf.org/doc/draft-connolly-cfrg-hpke-mlkem/03/
>
> There are some todo's to complete on making the explicit mapping between
> FIPS 203 and RFC 9180 functions concrete and some references that should be
> done by the 121 deadline.
>
>
> On Sun, Oct 13, 2024 at 11:47 AM Deirdre Connolly <
> [e-mail]> wrote:
>
>> Yes you are correct - I was thinking I was registering a whole 'HPKE'
>> ciphersuite which is incorrect, this is just for the KEM, which is fully
>> described by FIPS 203 and doesn't need the extra KDF and AEAD definitions,
>> I'll be removing that text.
>>
>> On Sat, Oct 12, 2024, 5:56 AM Rohan Mahy <[e-mail]> wrote:
>>
>>> Apologies for my hasty response on too little sleep.
>>>
>>> After skimming FIPS203 again, it looks like the hash function is fully
>>> specified, so just deleting the paragraph about KDFs and AEAD seems best to
>>> me.
>>>
>>> And NSecret is indeed always 32. It might be worth a note so readers
>>> less familiar with ML-KEM don't think it is a typo.
>>>
>>> Thanks,
>>> -rohan
>>>
>>> On Sat, Oct 12, 2024, 02:23 Rohan Mahy <[e-mail]> wrote:
>>>
>>>> Hi Dierdre,
>>>> Thanks very much for getting this out. My main technical concern is
>>>> this paragraph, which does not provide a clear mapping of ML-KEM size to
>>>> its KDF, and muddles cipher suite definition with KEM definition:
>>>>
>>>> We use HKDF-SHA256 and HKDF-SHA512 as the HPKE KDFs and AES-128-GCM and
>>>> AES-256-GCM as the AEADs for ML-KEM-512, ML-KEM-768, and ML-KEM-1024.
>>>>
>>>> Please define the specific KDF to use clearly in text or in a table. (I
>>>> think we can leave AEAD out of this.) I heard much talk of using ML-KEM-768
>>>> for the 128-bit and 192-bit security levels. Should we have 3 or 4
>>>> definitions for HPKE KEM?
>>>> ML-KEM-512 (SHA256) for ??
>>>> ML-KEM-768 (SHA256) for 128?
>>>> ML-KEM-768 (SHA384) for 192
>>>> ML-KEM-1024 (SHA512) for 256
>>>>
>>>> Regarding the IANA registration section, it requests 0x0512, 0x0768,
>>>> and 0x1024. Please don't. 0x0040, 0x0041, etc would be much better. Is
>>>> NSecret really only 32 for all three KEMs? I would have guessed these
>>>> increased to 48 and 64.
>>>>
>>>> I'll propose an editorial PR soon, but these are my only substantive
>>>> issues.
>>>> Thanks,
>>>> -rohan
>>>>
>>>>
>>>>