search

lamps-wg / draft-composite-kem

IETF draft specifying PQC composite KEM algorithms for use in X.509 and CMS
Other
6 stars 3 forks source link

Need to specify clearly how to invoke HKDF #93

Open ounsworth opened 1 week ago

ounsworth commented 1 week ago

Currently we just treat it as a generic KDF.

We need to take a much closer look at how to define the HKDF-SHA256 combo in a way that is 800-56Cr2 compliant. Technically HKDF (RFC 5869) is allowed under the 2-Step method, but it requires some careful alignment of inputs on the HKDF-Expand step. But in our case we only need to use the HKDF-Extract step for the combiner.

Fix: either specify that we only use the HKDF-Extract() step from RFC 5869, or else just use HMAC directly from RFC 2104

https://datatracker.ietf.org/doc/rfc2104/

chris-wood commented 1 week ago

@ounsworth this is a dupe of #87, I think?

chris-wood commented 1 week ago

In any case, I would recommend just dropping HKDF altogether. Since you're composing with ML-KEM, you already have SHA-3 available, so you might as well just use SHA3-256 as the one KDF across the board. What do you think?

ounsworth commented 1 week ago

In any case, I would recommend just dropping HKDF altogether. Since you're composing with ML-KEM, you already have SHA-3 available, so you might as well just use SHA3-256 as the one KDF across the board. What do you think?

Aww dude, you're like a year late to this debate. Both Joe Saloway and Deb Cooley were adamant that just because you have an ML-KEM implementation (potentially in a USB smartcard or something) does not mean that you have SHA3 available in, say, the Outlook S/MIME implementation that's gonna do the KEM Combining.

We have spent an inordinate amount of time fine-tuning a range of SHA2 and SHA3 offerings that everyone involved are happy with. Please don't re-open this can of worms.

ounsworth commented 1 week ago

@ounsworth this is a dupe of #87, I think?

Certainly related. There's a much larger discussion going on relating to how to make the SHA2-based combiner FIPS compatible. Russ is currently proposing that we ditch HKDF and specify raw usage of HMAC. This also has implications for CMS in general since the KEMRecipientInfo RFC that we just published (RFC 9629) has the same problem in that it is non FIPS compliant when used with id-alg-hkdf-with-sha256.

Please hold. I'll update github issues once my Outlook stops emitting smoke.

chris-wood commented 1 week ago

I'm sorry, but I don't buy the argument that ML-KEM will be available and SHA-3 will not. Where is discussion about this taking place?