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

[Daniel Van Geest <[e-mail]>]

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://aka.ms/AAb9ysg>
________________________________
From: Daniel Van Geest <[e-mail]>
Sent: Tuesday, January 30, 2024 5:09:16 PM
To: Carl Wallace <[e-mail]>; Russ Housley <[e-mail]>; Mike Ounsworth <[e-mail]>
Cc: LAMPS <[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://aka.ms/AAb9ysg>
________________________________
From: Carl Wallace <[e-mail]>
Sent: Tuesday, January 30, 2024 4:52:12 PM
To: Russ Housley <[e-mail]>; Daniel Van Geest <[e-mail]>; Mike Ounsworth <[e-mail]>
Cc: LAMPS <[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]> on behalf of Russ Housley <[e-mail]>
Date: Monday, January 8, 2024 at 4:02 PM
To: Daniel Van Geest <[e-mail]>
Cc: LAMPS <[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]> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm



_______________________________________________ Spasm mailing list [e-mail] https://www.ietf.org/mailman/listinfo/spasm