[CFRG] Re: Notes from NIST call about IETF hybrid KEMs and SP 800-227. Oct 17, 2024

[Falko Strenzke <[e-mail]>]

Please note that the link below for the OpenPGP combiner is wrong. It is 
pointing to the pre-adoption version. This is the correct link the 
up-to-date proposal (published yesterday) of the KEM combiner:

https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-05.html#section-4.2.1

Falko

Am 17.10.24 um 20:52 schrieb Mike Ounsworth:
>
> Notes from NIST call about IETF hybrid KEMs and SP 800-227. Oct 17, 2024
>
> ========================================================================
>
> I would like to consider three different (but similar) hybrid KEM 
> combiner constructions in IETF
>
> documents that are approaching publication.
>
> The question for this meeting:
>
> >>>>
>
> If these KEM combiners are implemented as-written, will they be able 
> to receive FIPS certification under SP 800-227?
>
> Alternatively, can they already be certified under SP 800-56Cr2?
>
> <<<<
>
> 1.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-kem-04#name-kem-combiner
>
> This supports ML-KEM + X25519, ECDH, and RSA-OAEP
>
> 2.
>
> The above is a very minor adjustment from
>
> https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem-04#name-combiner
>
> This supports only ML-KEM768+X25519
>
> 3.
>
> https://datatracker.ietf.org/doc/html/draft-wussler-openpgp-pqc-04#name-key-combiner
>
> Notes:
>
> Mike Ounsworth gave an overview of the KEM combiners in the three IETF 
> drafts above.
>
> Angela Robinson: The LAMPS and the OpenPGP seem to be aligned 56Cr2 
> because the domain separators fit nicely because the CT, PK, 
> domain_separator would fit into the fixedInfo. X-Wing places the 
> domain separator first, which would be problematic with a 56Cr2 
> certification. 800-227 is really an extension of 56Cr2 and does not 
> (currently) make any major deviations.
>
> Elaine Barker: In our current thinking is that the first component 
> would need to be the FIPS-approved one.
>
> Mike Ounsworth: one of the design goals here is that implementors can 
> start using ML-KEM before receiving a FIPS certification for it by 
> hybriding it with an already-validated algorithm.
>
> Turns out Brainpool is FIPS-approved? SP 800-186?
>
> Russ: This order thing (that the FIPS-approved one needs to come 
> first) causes me concern because over time what is FIPS-approved will 
> change (ex.: at some point ECDH will be removed from the FIPS-approved 
> list). It would be unfortunate if at that point we need to re-do all 
> these protocols and deployed systems to swap the order of the inputs.
>
> Gorjan: Moving on from the order discussion. We should also discuss 
> that X-Wing has the label first and the others have it last. And we 
> should talk about the choice of KDFs (HKDF-SHA2, SHA3, and KMAC are 
> all used, are they all FIPS-allowed?).
>
> Deirdre: the X-Wing team did not consider FIPS certifiability when 
> making the construction, which is why we did not consider putting the 
> label at the end.
>
> Gorjan asked if the X-Wing team would be willing to move the domain 
> separator to the end.
>
> Chris Celi: FIPS 140-3 IG D.P. allows for dropping the counter in a 
> single-iteration case, so that may allow for the LAMPS HKDF-SHA2 
> construction to be certified (assuming the HKDF is ok).
>
> Panos: HKDF is allowed specifically for TLS 1.3, there is a specific 
> IG, but HKDF is not FIPS-approved as a general KDF. SP 800-108, only 
> HKDF-expand is allowed as a generic KDF.
>
> KDFs
>
> Is HKDF-SHA2 FIPS compatible?
>
> Want SHA2-nice options (SHA3 may not be available, KMAC
>
> https://words.filippo.io/dispatches/fips-hkdf/
>
> "If you’re doing key-agreement you can use HKDF per SP 800-56C Rev. 2. 
> If you’re not you can use HKDF-Extract to combine a randomly-generated 
> key with other keys and/or data per SP 800-133 Rev. 2 (Section 6.3 
> Option #3), and use HKDF-Expand as a general purpose KDF per SP 800-108.
>
> SP 800-227 really really must say something about HKDF as a KDF not 
> just for key agreement.
>
> HKDF is "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)" 
> so it is not a far stretch for it to be allowed under 56Cr2 Option 2: 
> H(x) = HMAC-hash(salt, x), but we need an IG from NIST that says this.
>
> ACTION ITEMS:
>
> - NIST : Is HKDF-SHA2 a sub-category of 56Cr2 Option 2 (HMAC-Hash)
>
> - NIST : come up with a position on order of the KDF shared secret 
> inputs (ie must it be that the first one is the FIPS approved one). 
> The community has asked that 800-227 relax the requirement or order.
>
> - X-Wing team : consider moving the label to the end.
>
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>
>
> _______________________________________________
> CFRG mailing list [e-mail]
> To unsubscribe send an email [e-mail]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: [phone]
E-Mail: [e-mail]
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>