Re: [lamps] Key Derivation in draft-ietf-lamps-cms-kemri

[Mike Ounsworth <[e-mail]>]

I agree with Daniel.

 

draft-ietf-lamps-cms-kyber has not yet been updated to reflect the existence of KEMRI – it’s the “too many drafts, not enough hours” problem. If Daniel is offering to do some work on it, I fully support and welcome that.

 

---

Mike Ounsworth

 

From: Daniel Van Geest <[e-mail]> 
Sent: Tuesday, January 30, 2024 11:12 AM
To: Carl Wallace <[e-mail]>; Russ Housley <[e-mail]>; Mike Ounsworth <[e-mail]>
Cc: LAMPS <[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Key Derivation in draft-ietf-lamps-cms-kemri

 

Apologies. . . Previous message was sent too early. Continued. . . - specify required KDF (and wrap), similar to 5990bis, and allow for others (also similar) - security considerations. That's about it, a lot of the new draft will be pointing at 



Apologies... Previous message was sent too early.  

 

Continued...

- specify required KDF (and wrap), similar to 5990bis, and allow for others (also similar)

- security considerations. 

 

That's about it, a lot of the new draft will be pointing at other documents where OID/etc are already defined. 

 

Thanks,

Daniel 

 

Get Outlook for Android <https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!FJ-Y8qCqXTj2!dfmryflLrGq3J5Eaono2fRdPrLBBhjRih1AK-8UFXltMXvZifUf1D3bwlA4epNzVyJC6qhD3i6UGNLFRQQzpXowII3LmUcc$> 

  _____  

From: Daniel Van Geest <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, January 30, 2024 5:09:16 PM
To: Carl Wallace <[e-mail] <mailto:[e-mail]> >; Russ Housley <[e-mail] <mailto:[e-mail]> >; Mike Ounsworth <[e-mail] <mailto:[e-mail]> >
Cc: LAMPS <[e-mail] <mailto:[e-mail]> >
Subject: Re: [lamps] Key Derivation in draft-ietf-lamps-cms-kemri 

 

draft-ietf-lamps-cms-kyber-01 is out of date, it doesn't take KemRecipientInfo into consideration well enough (or at all?). I've spoken to my colleague Julien about taking over the draft since I've been implementing kemri anyways, I just need to find the time for both. I envision the draft being simplified, and following the model of rfc5990bis:

- discuss KEMs and ML-KEM in (very) brief. There seem to be many draft repeating the same info where it would be better to refer to the NIST specs (or a CFRG doc covering them). 

- specify OIDs for ML-KEM in CMS (again pointing to other drafts)

 

Get Outlook for Android <https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!FJ-Y8qCqXTj2!dfmryflLrGq3J5Eaono2fRdPrLBBhjRih1AK-8UFXltMXvZifUf1D3bwlA4epNzVyJC6qhD3i6UGNLFRQQzpXowII3LmUcc$> 

  _____  

From: Carl Wallace <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, January 30, 2024 4:52:12 PM
To: Russ Housley <[e-mail] <mailto:[e-mail]> >; Daniel Van Geest <[e-mail] <mailto:[e-mail]> >; Mike Ounsworth <[e-mail] <mailto:[e-mail]> >
Cc: LAMPS <[e-mail] <mailto:[e-mail]> >
Subject: Re: [lamps] Key Derivation in draft-ietf-lamps-cms-kemri 

 

Russ and Mike,

 

Section 5.2.1 of draft-ietf-lamps-cms-kyber-01 states the following:

 

“If the session key obtained from the KEM algorithm is long enough to fit into the WRAP algorithm, then the KDF could be equal to the identity function.”

 

Given this, should the kdf and kekLength fields be OPTIONAL in KEMRecipientInfo?

 

Carl

 

From: Spasm <[e-mail] <mailto:[e-mail]> > on behalf of Russ Housley <[e-mail] <mailto:[e-mail]> >
Date: Monday, January 8, 2024 at 4:02 PM
To: Daniel Van Geest <[e-mail] <mailto:[e-mail]> >
Cc: LAMPS <[e-mail] <mailto:[e-mail]> >
Subject: Re: [lamps] Key Derivation in draft-ietf-lamps-cms-kemri

 

Daniel:

 

It can use an KDF, but I expect that most implementers will want to use the same KDF that was used internal to the KEM algorithm to keep the implementation small.

 

Russ

 

On Jan 8, 2024, at 3:59 PM, Daniel Van Geest <[e-mail] <mailto:[e-mail]> > wrote:

 

I’m implementing draft-ietf-lamps-cms-kemri and have a question about the ` kdf KeyDerivationAlgorithmIdentifier` field in KEMRecipientInfo.

 

Is it intended that any (IKM, L, info) KDF can be thrown there (respecting Security Considerations), or should the KEM-instantiating documents specify which KDFs to use with which KEMs.  e.g. draft-ietf-lamps-cms-kyber should specify to use id-alg-hkdf-with-sha256 with Kyber512, id-alg-hkdf-with-sha384 with Kyber768 and id-alg-hkdf-with-sha512 with Kyber1024?

 

If they should do this, should the kdf field for KEMRecipientInfo be parameterized by allowed KDF ids (or whatever the right ANS.1 terminology is)?

 

    KEMRecipientInfo ::= SEQUENCE {

        …

        kdf KeyDerivationAlgorithmIdentifier{KEY-DERIVATION, KEMRIKeyDevAlgs},

        …

    }

 

    KEMRIKeyDevAlgs KEY-DERIVATION ::= {kda-hkdf-with-sha256, kda-hkdf-with-sha384, kda-hkdf-with-sha512, …}

 

And KEM instantiating docs can add to KeyDevAlgs if needed.

 

Thanks,

Daniel

 

_______________________________________________
Spasm mailing list
 <mailto:[e-mail]> [e-mail]
 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!dfmryflLrGq3J5Eaono2fRdPrLBBhjRih1AK-8UFXltMXvZifUf1D3bwlA4epNzVyJC6qhD3i6UGNLFRQQzpXowInU-lNac$> https://www.ietf.org/mailman/listinfo/spasm

 

_______________________________________________ Spasm mailing list [e-mail] <mailto:[e-mail]>  https://www.ietf.org/mailman/listinfo/spasm <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!dfmryflLrGq3J5Eaono2fRdPrLBBhjRih1AK-8UFXltMXvZifUf1D3bwlA4epNzVyJC6qhD3i6UGNLFRQQzpXowInU-lNac$>