[lamps] Re: [EXTERNAL] Re: KDF in draft-ietf-lamps-cms-kyber

[Mike Ounsworth <[e-mail]>]

Hi Uri,

 

Please don’t confuse the issue. Can you please point to the NIST document that claims that HKDF-SHA2 is allowed as a post-processing KDF with ML-KEM? Because we have a definitive statement and reference from Quynh Dang earlier in this thread that says that it is not.

 

https://mailarchive.ietf.org/arch/msg/spasm/aXSLgBPTX49pzo_mWE7EiADQ5oU/

 

---

Mike Ounsworth

 

From: Blumenthal, Uri - 0553 - MITLL <[e-mail]> 
Sent: Monday, September 30, 2024 1:58 PM
To: Mike Ounsworth <[e-mail]>; Daniel Van Geest <[e-mail]>; Dang, Quynh H. (Fed) <[e-mail]>; LAMPS <[e-mail]>; Russ Housley <[e-mail]>
Subject: [EXTERNAL] Re: KDF in draft-ietf-lamps-cms-kyber

 

KMAC is NIST-approved, but not CNSA-authorized.

 

HKDF-SHA2 is NIST-approved, and with SHA384 – also CNSA-authorized (AFAICT). And, as pointed out, “widely implemented already”.

 

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                        C. A. R. Hoare

 

I was a shepherd to fools

Causelessly bold or afraid.

They would not abide by my rules.

Yet they escaped. For I stayed.

                                    R. Kipling “Epitaphs of the War. Convoy Escort”

 

 

From: Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:Mike.Ounsworth=[e-mail]> >
Date: Monday, September 30, 2024 at 12:29
To: Daniel Van Geest <[e-mail] <mailto:[e-mail]> >, Dang, Quynh H. (Fed) <quynh.dang=[e-mail] <mailto:quynh.dang=[e-mail]> >, LAMPS <[e-mail] <mailto:[e-mail]> >, Russ Housley <[e-mail] <mailto:[e-mail]> >
Subject: [EXT] [lamps] Re: KDF in draft-ietf-lamps-cms-kyber

> I can add a note saying something like "if you want NIST compliance, also implement KMAC,"

 

The problem is, where is that specified? It’s more than just saying “oh, and you can also use KMAC”. You need to at least specify which OIDs to use, what to put in SMIME-CAPS, KMAC128 vs KMAC256, what values to use for K, L, S. You can’t say “You can also use KMAC” without having a spec to point at that has all of this written down. 

 

IMO, IETF / LAMPS should specify at least one FIPS-compatible option. If ML-KEM-with-HKDF-SHA2 is not FIPS-approved, then I think it behooves us to also include in draft-ietf-lamps-cms-kyber the full specification of how to use ML-KEM in CMS with KMAC as the CMS-layer KDF. 

 

---

Mike Ounsworth

 

From: Daniel Van Geest <[e-mail] <mailto:[e-mail]> > 
Sent: Monday, September 30, 2024 11:08 AM
To: Mike Ounsworth <[e-mail] <mailto:[e-mail]> >; Dang, Quynh H. (Fed) <quynh.dang=[e-mail] <mailto:quynh.dang=[e-mail]> >; LAMPS <[e-mail] <mailto:[e-mail]> >; Russ Housley <[e-mail] <mailto:[e-mail]> >
Subject: [EXTERNAL] Re: KDF in draft-ietf-lamps-cms-kyber

 

Catching up here. Specifying a particular KDF as MTI with ML-KEM in draft-ietf-lamps-cms-kyber does not prevent an implementer from also supporting another KDF. Specifying an MTI KDF in the RFC just increases interoperability. HDKF-with-SHA2

Catching up here.

 

Specifying a particular KDF as MTI with ML-KEM in draft-ietf-lamps-cms-kyber does not prevent an implementer from also supporting another KDF.  Specifying an MTI KDF in the RFC just increases interoperability.

 

HDKF-with-SHA2 was requested because it is already widely implemented.

 

So, if draft-ietf-lamps-cms-kyber specifies HDKF-with-SHA2 as the MTI KDF, nothing is preventing an implementation from also implementing KMAC in order to get NIST compliance.

 

Is an implementation going to fail to get NIST compliance if it implements both KMAC and HKDF for ML-KEM in CMS?  Even if it's configured to only use KMAC?

 

My inclination for the next version of the draft is to specify HKDF-with-SHA2 as MTI. We know this includes an unnecessary extract step, but it's not hurting anything.  I can add a note saying something like "if you want NIST compliance, also implement KMAC," but then what's to stop more requests for "if you want XYZ compliance, also implement HIJKDF."

 

If I follow this inclination (with or without the note), am I going to hear about it at IETF 121 and need to update this section yet again?

 

Regards,

Daniel Van Geest

 

 

On 2024-09-23 7:07 p.m., Mike Ounsworth wrote:

Dan: right. That’s a pretty solid reason why we need a KDF.

 

 

 

Quynh: Hmm. Well that certainly makes it more complicated.

 

Quynh, can you clarify where those three KDFs listed in SP 800-108r1 come from?

 

4.1 KDF in Counter Mode

4.2 KDF in Feedback Mode

4.3 KDF in Double-Pipeline Mode

 

Do any of them have RFCs? Are any of them HKDF? Is there precedent for RFCs the specify using those KDFs in a CMS *RecipientInfo? (I’m guessing that the answer to all is “no”?)

 

 

The “obvious” thing for draft-ietf-lamps-cms-kyber is to use HKDF-SHA2 as per RFC5869, but at a quick glance, HKDF is not one of the three KDFs defined in 4.1 – 4.3 of SP 800-108r1.

 

But KMAC is.

 

So  <mailto:[e-mail]> @Daniel Van Geest I wonder if we’re back to listing both options?

HKDF-SHA2: use this if you need SHA2

KMAC: use this if you need FIPS compliance.

 

What if you need both SHA2 and FIPS? Too bad?

 

---

Mike Ounsworth

 

From: Dang, Quynh H. (Fed)  <mailto:quynh.dang=[e-mail]> <quynh.dang=[e-mail]> 
Sent: Monday, September 23, 2024 12:42 PM
To: Mike Ounsworth  <mailto:[e-mail]> <[e-mail]>; Daniel Van Geest  <mailto:[e-mail]> <[e-mail]>; LAMPS  <mailto:[e-mail]> <[e-mail]>; Daniel Van Geest  <mailto:[e-mail]> <[e-mail]>; Russ Housley  <mailto:[e-mail]> <[e-mail]>
Subject: [EXTERNAL] RE: KDF in draft-ietf-lamps-cms-kyber

 

At this moment, there are 2 NIST compliant methods to get an AES key from the K.

 

1) Get a part or the whole of K depending on AES128, 192 or 256.

2) Run a KDF in SP 800-108 revision 1 and K is the secret input: the pseudorandom key, to the KDF.  Further technical requirements are in the document. 

 

Regards,

Quynh. 

 

From: Mike Ounsworth < <mailto:Mike.Ounsworth=[e-mail]> Mike.Ounsworth=[e-mail]> 
Sent: Monday, September 23, 2024 11:43 AM
To: Dang, Quynh H. (Fed) < <mailto:[e-mail]> [e-mail]>; Daniel Van Geest < <mailto:[e-mail]> [e-mail]>; LAMPS < <mailto:[e-mail]> [e-mail]>; Daniel Van Geest < <mailto:[e-mail]> [e-mail]>; Russ Housley < <mailto:[e-mail]> [e-mail]>
Subject: RE: KDF in draft-ietf-lamps-cms-kyber

 

Quynh,

 

Interesting. Are you proposing that when ML-KEM is used for content encryption within CMS, it does not need a KDF at the KEMRecipientInfo level, and in fact would be in violation of FIPS if it did? IE we should set KEMRecipientInfo.kdf = id-none (does this actually exist?) ?

 

The primary reason for a KDF at the KEMRecipientInfo layer is not for security but to stretch the shared secret output from the KEM to match the require key size for the AES wrap. ML-KEM.Encaps(ek) from FIPS 203 does not have a variable output length param – you always get a 32 byte (256 bit) shared secret from all strengths of ML-KEM, right?

 

But maybe that’s ok because we only ever need up to AES-256. Maybe we can get away with KEMRecipientInfo.kdf = id-none and just truncate as needed for the given AES size?

 

 <mailto:[e-mail]> @Daniel Van Geest,  <mailto:[e-mail]> @Russ Housley, thoughts?

 

 

 

 

The relevant parts of KEMRecipientInfo (from RFC 9629):

 

IE the KEMRecipientInfo would be:

 

  KEMRecipientInfo ::= SEQUENCE {

    …

    kem id-mlkem-*,

    …

    kdf id-none,

    kekLength INTEGER (1..65535),  <-- if doing this approach, then it would be max 256

    …

    wrap id-aes*-wrap,

    … }

 

?

 

---

Mike Ounsworth

 

From: Dang, Quynh H. (Fed) < <mailto:quynh.dang=[e-mail]> quynh.dang=[e-mail]> 
Sent: Monday, September 23, 2024 5:41 AM
To: Daniel Van Geest < <mailto:daniel.vangeest=[e-mail]> daniel.vangeest=[e-mail]>; LAMPS < <mailto:[e-mail]> [e-mail]>
Subject: [EXTERNAL] [lamps] Re: KDF in draft-ietf-lamps-cms-kyber

 

Hi Daniel and all, The shared secret key K coming out of a ML-KEM Encap/Decap is a pseudorandom key. So, it is pointless to run an extraction function over it before running an expansion function as the version 04 does. NIST might update SP

 

Hi Daniel and all,
 
The shared secret key K coming out of a ML-KEM Encap/Decap is a pseudorandom key.  So, it is pointless to run an extraction function over it before running an expansion function as the version 04 does. 
 
NIST might update SP 800-56C to allow the KDFs (including the HKDF with HMAC) there to derive keys from K in the future. But nothing is a sure thing before it happens. 
 
At this moment, if someone wants to use a NIST-compliant KDF, they can use one of the KDFs in SP 800-108 revision 1 here:  <https://urldefense.com/v3/__https:/nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1-upd1.pdf__;!!FJ-Y8qCqXTj2!cEXz6BLF7QDTmt2iYATb3Cgg0-8nfYlozfv4UKugL3mEb0D5gV7EO_XEFP27ISzrt1YoALEyIpjNIzYqYEGlI51-GGmoTOj-IpJ6FUVGZg$> https://urldefense.com/v3/__https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1-upd1.pdf__;!!FJ-Y8qCqXTj2!cEXz6BLF7QDTmt2iYATb3Cgg0-8nfYlozfv4UKugL3mEb0D5gV7EO_XEFP27ISzrt1YoALEyIpjNIzYqYEGlI51-GGmoTOj-IpJ6FUVGZg$
 
Regards,
Quynh. 
 
 
 
> -----Original Message-----
> From: Daniel Van Geest <daniel.vangeest=40cryptonext-
>  <mailto:[e-mail]> [e-mail]>
> Sent: Monday, September 23, 2024 5:26 AM
> To: LAMPS < <mailto:[e-mail]> [e-mail]>
> Subject: [lamps] KDF in draft-ietf-lamps-cms-kyber
> 
> Hi LAMPS,
> 
> The feedback in IETF 120 for draft-ietf-lamps-cms-kyber was to specify a single
> MTI KDF to use with ML-KEM in KEMRecipientInfo. The draft I presented
> specified that one of KMAC or HMAC with SHA2 must be implemented.
> Feedback from previous meetings was to please include HMAC with SHA2.
> 
> So, in the next version we will specify that the following KDFs MUST be
> supported:
> 
> If ML-KEM-512 is supported, HMAC with SHA2-256.
> If ML-KEM-768 is supported, HMAC with SHA2-512.
> If ML-KEM-1024 is supported, HMAC with SHA2-512.
> 
> The question for the group is whether we should just leave it that, or should
> we say something about KMAC?
> 
> For example, we could say implementations SHOULD to support KMAC.  The
> reasoning for KMAC is that it uses the same underlying Keccak primitives as
> ML-KEM.  But SHOULD seems to strong to me, I think it implies that most
> implementations would want to implement this and I don't know if that's the
> case.
> 
> Or, we could say implementations MAY support KMAC.  To me this statement
> seems meaningless because implementation may already support any
> additional KDF with KEMRecipientInfo as long as they also support the MTI
> one.
> 
> Thanks,
> Daniel Van Geest
> 
> 
> _______________________________________________
> Spasm mailing list --  <mailto:[e-mail]> [e-mail]
> To unsubscribe send an email to  <mailto:[e-mail]> [e-mail]
_______________________________________________
Spasm mailing list --  <mailto:[e-mail]> [e-mail]
To unsubscribe send an email to  <mailto:[e-mail]> [e-mail]