Re: [lamps] [EXTERNAL] RE: WGLC for draft-ietf-lamps-cms-sha3-hash

[Mike Ounsworth <[e-mail]>]

Based on a little more discussion that I had this morning with my co-authors on draft-ounsworth-cfrg-kem-combiners, some extra thoughts:

 

There will be existing implementations of HKDF-SHA2 (which is HMAC inside) where the existing crypto agility easily allows for substitution of SHA2 for SHA3, but may not easily allow for substitution of the entire construction for KMAC. Given that there are no security objections to HKDF-SHA3 (only performance objections), we might as well register OIDs for them.

 

We should also include KDF-KMAC OIDs in draft-ietf-lamps-cms-sha3.

 

---

Mike Ounsworth

 

From: Daniel Van Geest <[e-mail]> 
Sent: Wednesday, February 7, 2024 9:39 AM
To: 'Russ Housley' <[e-mail]>; Mike Ounsworth <[e-mail]>; 'Markku-Juhani O. Saarinen' <[e-mail]>
Cc: 'Tim Hollebeek' <[e-mail]>; 'SPASM' <[e-mail]>
Subject: [EXTERNAL] RE: [lamps] WGLC for draft-ietf-lamps-cms-sha3-hash

 

I didn’t make the request, but draft-ietf-lamps-cms-kyber currently references the KDF OIDs, so that could be the source. I’ve just started rewriting that draft to mirror rfc5990bis. ML-KEM uses SHAKE128, SHAKE256, SHA3-256 and SHA3-512 internally.  



I didn’t make the request, but draft-ietf-lamps-cms-kyber currently references the KDF OIDs, so that could be the source. I’ve just started rewriting that draft to mirror rfc5990bis.

 

ML-KEM uses SHAKE128, SHAKE256, SHA3-256 and SHA3-512 internally. SHA3-512 is used to derive the 32 byte shared secret, so it would arguably be considered the internal KDF and should also be the basis for the KDF when using ML-KEM with KEMRecipientInfo. Though since the KEMRI KDF takes an output length, SHAKE256 could be a better choice.

 

KEMRI requires a KDF which takes a shared secret and info parameter.  HKDF with SHA3 fits that bill, although in an unnecessarily complicated way.

 

As I understand them (barely, they’re paywalled and I haven’t done anything to get them yet), KDF2 and KDF3 would also fit the bill, but they also have unnecessary iterations.

 

NIST SP 800-108 allows a simple KDF wrapping KMAC128/KMAC256. As far as I know there are no OIDs defined for that, and also KMAC is based on cSHAKE, not SHA3, so it’s possibly out of scope for draft-ietf-lamps-cms-sha3. But for the purposes of ML-KEM in KEMRI, this would probably be the best option.

 

So then, are there any suggestions on what to do with this?  Keep hkdf-with-sha3* and make  <mailto:[e-mail]> @Markku-Juhani O. Saarinen unhappy? Slide KMAC into draft-ietf-lamps-cms-sha3-hash? Spin up a new draft for KMAC? Define an OID for KMAC in draft-ietf-lamps-cms-kyber (yuck)? Force draft-ietf-lamps-cms-kyber to use KDF3 like rfc5990bis (and further commit to a paywalled spec)?

 

Thanks,

Daniel

 

 

From: Spasm <[e-mail] <mailto:[e-mail]> > On Behalf Of Russ Housley
Sent: Tuesday, February 6, 2024 8:51 PM
To: Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:Mike.Ounsworth=[e-mail]> >; Markku-Juhani O. Saarinen <[e-mail] <mailto:[e-mail]> >
Cc: Tim Hollebeek <tim.hollebeek=[e-mail] <mailto:tim.hollebeek=[e-mail]> >; SPASM <[e-mail] <mailto:[e-mail]> >
Subject: Re: [lamps] WGLC for draft-ietf-lamps-cms-sha3-hash

 

Mike and Markku:

 

Section 5 was added in October 2023because someone asked for KDFs.  I do not recall the source of the request.

 

Russ

 

On Feb 6, 2024, at 3:21 PM, Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:Mike.Ounsworth=[e-mail]> > wrote:

 

Sorry, too quick on the SEND.

 

Markku is questioning why we need section 5.1 HKDF with SHA3.

 

---

Mike Ounsworth

 

From: Spasm < <mailto:[e-mail]> [e-mail]> On Behalf Of Mike Ounsworth
Sent: Tuesday, February 6, 2024 2:20 PM
To: Tim Hollebeek < <mailto:tim.hollebeek=[e-mail]> tim.hollebeek=[e-mail]>; SPASM < <mailto:[e-mail]> [e-mail]>; Markku-Juhani O. Saarinen < <mailto:[e-mail]> [e-mail]>
Subject: [EXTERNAL] Re: [lamps] WGLC for draft-ietf-lamps-cms-sha3-hash

 

I’m just gonna lob this in on  <mailto:[e-mail]> @Markku-Juhani O. Saarinen’s behalf.

 

He commented this morning that it’s un-necessary to do HMAC with SHA3. If you need a MAC, then KMAC is a single invocation of SHA3 vs two invocations in HMAC. And if you only need a KDF then (I think?) naked SHA3 is fine?

 

I’ll leave it to Markku to give the details here, but I wanted to make sure this got logged before WGLC closes.

 

---

Mike Ounsworth

 

From: Spasm < <mailto:[e-mail]> [e-mail]> On Behalf Of Tim Hollebeek
Sent: Tuesday, January 30, 2024 2:43 PM
To: SPASM < <mailto:[e-mail]> [e-mail]>
Subject: [EXTERNAL] [lamps] WGLC for draft-ietf-lamps-cms-sha3-hash

 

Hello,

 

Russ has suggested that draft-ietf-lamps-cms-sha3-hash might be ready for WGLC, and since it’s a pretty simple draft that seems like a pretty reasonable way to flush out any remaining comments and problems.

 

Therefore this is the WGLC for draft-ietf-lamps-cms-sha3-hash:

 

Use of the SHA3 One-way Hash Functions in the Cryptographic Message Syntax (CMS)

 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamps-cms-sha3-hash/__;!!FJ-Y8qCqXTj2!awcQH_wkt28UPyvQOrJnJWYJsX_vWI1_iWC9qzjW7XEhN04OR3mXDXDWhnCRSOncjSMhjohXKKDWP3lmkYLS3iThg5HtvaU$> https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-sha3-hash/

 

Abstract

 

   This document describes the conventions for using the four one-way

   hash functions in the SHA3 family with the Cryptographic Message

   Syntax (CMS).

 

Please send comments to the list by 12 February 2024.

 

-Tim

 

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