Re: [lamps] Adoption call for draft-housley-lamps-cms-sha3-hash

[Tim Hollebeek <[e-mail]>]

Yes, thank you.  That’s what I thought but I didn’t want to put words in your mouth.  I’ve enjoyed the thoughtful discussion.

 

Anyway, with that, we’re officially adopting cms-sha3-hash as a WG document.  Russ, please post the WG version.

 

-Tim

 

From: Kampanakis, Panos <kpanos=[e-mail]> 
Sent: Monday, November 27, 2023 4:53 PM
To: Tim Hollebeek <[e-mail]>; Michael StJohns <[e-mail]>; [e-mail]
Subject: RE: [lamps] Adoption call for draft-housley-lamps-cms-sha3-hash

 

Hi Tim,

 

I am not against adoption. I don’t think it would hurt to standardize SHA3 in CMS. 

 

I was trying to play devil’s advocate for an implementer trying to decide if they should implement draft-housley-lamps-cms-sha3-hash or RFC8702. But I am not against adoption. 

 

 

From: Tim Hollebeek <tim.hollebeek=[e-mail] <mailto:tim.hollebeek=[e-mail]> > 
Sent: Monday, November 27, 2023 4:01 PM
To: Kampanakis, Panos <[e-mail] <mailto:[e-mail]> >; Michael StJohns <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: RE: [EXTERNAL] [lamps] Adoption call for draft-housley-lamps-cms-sha3-hash

 

Panos,

 

Are you actually against adoption of this draft, or are you just making some very intelligent comments and participating in discussion on what the final contents of the document should say?  I’m trying to close out the adoption call, and if you’re not against adoption, then there’s clear consensus in favor.  If not, I’d like to dig into your objections to adoption a little further and understand them better.

 

-Tim

 

From: Spasm <[e-mail] <mailto:[e-mail]> > On Behalf Of Kampanakis, Panos
Sent: Sunday, October 29, 2023 10:03 PM
To: Michael StJohns <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: Re: [lamps] Adoption call for draft-housley-lamps-cms-sha3-hash

 

> try and practice algorithmic pluralism in the way we define things

 

Personally, I am not sure algorithmic pluralism for the sake of variety is a good idea. Integrating and using only new algorithms that make sense is a better one imo. 

I can’t think of a case where SHA-3 would be preferred over SHAKEs, but I am open to suggestions. 

 

From: Spasm <[e-mail] <mailto:[e-mail]> > On Behalf Of Michael StJohns
Sent: Saturday, October 28, 2023 11:50 PM
To: [e-mail] <mailto:[e-mail]> 
Subject: RE: [EXTERNAL] [lamps] Adoption call for draft-housley-lamps-cms-sha3-hash

 


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

 

IMHO - These are somewhat orthogonal items.   Russ' document is useful irrespective of the Mike's KEM stuff, and I'd like to see it move forward on that basis.

 

(also, https://csrc.nist.gov/Projects/computer-security-objects-register/algorithm-registration has the OID registration for id-sha3-256, so for the use Mike as asking about, it's unclear his document actually depends on Russ' document.  That said, its usually useful to have an IETF public of the NIST allocations as RFCs tend to be a bit easier to find for our participants).

 

If you want draft-ietf-lamps-pq-composite-kem to use Shake exclusively, that's more a discussion that needs to happen on the list with respect to that draft.  Alternately, do what is more flexible and define multiple kda-??? KEY-DERIVATION ::={} constructs to support both shake and sha3.

 

So I'd suggest it may be better to avoid discussions about which is better and try and practice algorithmic pluralism in the way we define things.  In other words, allocate top level OIDs for both a shake and sha3 variant of the KDF and include those in the ASN1.

 

Later, Mike

 

 

On 10/28/2023 10:37 PM, Kampanakis, Panos wrote:

Hi Mike, 

 

> I guess this is a design choice that the WG can discuss. We could instead use id-shake-256 from RFC8702, which is usable as a digest algorithm as per section 3.1, but why? If what I actually want is a hash function, then why can’t I have a hash function?

 

I suggest to discuss this in IETF-118. SHAKEs are XOFs but can be used just fine as hashes with constant output size. Their performance is better, and generally that is the reason they have be favored and more adopted than SHA-3 (in the same family).

 

 

 

 

From: Spasm  <mailto:[e-mail]> <[e-mail]> On Behalf Of Mike Ounsworth
Sent: Saturday, October 28, 2023 2:08 PM
To: Russ Housley  <mailto:[e-mail]> <[e-mail]>; Kampanakis, Panos  <mailto:[e-mail]> <[e-mail]>
Cc: LAMPS  <mailto:[e-mail]> <[e-mail]>
Subject: RE: [EXTERNAL] [lamps] [EXTERNAL] Re: Adoption call for draft-housley-lamps-cms-sha3-hash

 


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

 

Panos,

 

Specifically, draft-ietf-lamps-pq-composite-kem instantiates RSA-KEM (RFC5990bis) with:

keyDerivationFunction  kda-kdf3 with id-sha3-256

See:

https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-kem-02#name-rsa-kem-parameters

 

Therefore, I need an OID for id-sha3-256.

 

I guess this is a design choice that the WG can discuss. We could instead use id-shake-256 from RFC8702, which is usable as a digest algorithm as per section 3.1, but why? If what I actually want is a hash function, then why can’t I have a hash function?

 

- Mike Ounsworth

  _____  

From: Spasm <[e-mail] <mailto:[e-mail]> > on behalf of Russ Housley <[e-mail] <mailto:[e-mail]> >
Sent: Saturday, October 28, 2023 10:44:57 AM
To: Panos Kampanakis <[e-mail] <mailto:[e-mail]> >
Cc: LAMPS <[e-mail] <mailto:[e-mail]> >
Subject: [EXTERNAL] Re: [lamps] Adoption call for draft-housley-lamps-cms-sha3-hash 

 

Panos: Mike Ounsworth needs these OIDs to be available, and the easiest solution was to just publish the previously abandoned I-D. Russ On Oct 27, 2023, at 11: 00 PM, Kampanakis, Panos  <mailto:kpanos=40amazon. com@ dmarc. ietf. org> <kpanos=40amazon. com@ dmarc. ietf. org> wrote: Hi Russ, 

 

Panos: 

 

Mike Ounsworth needs these OIDs to be available, and the easiest solution was to just publish the previously abandoned I-D.

 

Russ

 

 

On Oct 27, 2023, at 11:00 PM, Kampanakis, Panos <kpanos=[e-mail] <mailto:kpanos=[e-mail]> > wrote:

 

Hi Russ, 

 

I was under the impression that SHAKEs for CMS and X.509 would suffice for introducing the Keccak family to these standards. SHAKEs have the same security and better performance. I thought that was the reason draft-turner-lamps-adding-sha3-to-pkix never made it.

 

Is there a reason why someone would use SHA-3 in CMS instead of SHAKE128 or SHAKE256 (RFC8702)?

 

 

 

From: Spasm < <mailto:[e-mail]> [e-mail]> On Behalf Of Tim Hollebeek
Sent: Friday, October 27, 2023 11:39 AM
To: SPASM < <mailto:[e-mail]> [e-mail]>
Subject: [EXTERNAL] [lamps] Adoption call for draft-housley-lamps-cms-sha3-hash

 


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

 

Hello,

 

Russ has asked for an adoption call for this short document that explains how to

use SHA-3 with CMS.  Since people may be traveling to IETF 118, we’ll do a three

week adoption call.

 

 

 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-housley-lamps-cms-sha3-hash-00__;!!FJ-Y8qCqXTj2!btMHx3oQg1XcdsmiDk3zQn-HVGxUExFHzJp0v2bwunfFVR3P8235FQ_QH4pzRkyD49fJSywzek8dgSw-P9DqGArWDMhf$> https://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-sha3-hash-00

 

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 indicate whether you support adoption, and optionally indicate why, on

the list by 17 November 2023.

 

For the chairs,

 

-Tim

 

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

 

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. 

 

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