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

[Russ Housley <[e-mail]>]

The IETF has been moving more and more to one OID tells all you need to know, and avoid parameters altogether unless they are needed at runtime, like an IV for AES-CBC.

Russ

> On Nov 1, 2023, at 7:13 PM, Mike Ounsworth <Mike.Ounsworth=[e-mail]> wrote:
> 
> Hi Mike,
>  
> > One of the things I dislike about the pq-kem document is that choices like the particular KDF to use are implied by the KEM algorithm OID and can't be easily substituted without starting over.  Compare and contrast RFC5990 and the RSA-KEM parameters definition.
>  
> Great discussion to bring out on the list!
>  
> This is sorta going in circles; initially the composite sigs and kems drafts had all the parametrized flexibility that you could dream of. We were told this is not how we do things in 2023 and AlgID params are verboten and everything needs to be implied by the OID. For example, we were told that id-MLKEM512-RSA-KMAC128 was too flexible since it leaves the RSA key size unconstrained, so in the most recent version we changed that to id-MLKEM512-RSA2048-KMAC128.
>  
> So let’s hash this out on-list. @Russ Housley <mailto:[e-mail]> is the big proponent of “no params, mega-OID” approach.
>  
> ---
> Mike Ounsworth
>  
> From: Spasm <[e-mail] <mailto:[e-mail]>> On Behalf Of Michael StJohns
> Sent: Monday, October 30, 2023 11:57 AM
> To: Kampanakis, Panos <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: [EXTERNAL] Re: [lamps] Adoption call for draft-housley-lamps-cms-sha3-hash
>  
> On 10/29/2023 10: 02 PM, Kampanakis, Panos wrote: > 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 
> On 10/29/2023 10:02 PM, Kampanakis, Panos wrote:
> > 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.
> AFAICT from FIPS202 both are just parameterized instantiations of the same KECCAK function and have exactly the same performance (and strength).  E.g. from FIPS202
> 
> SHA3-256 (M) ::= KECCACK[512](M||01, 256)
> 
> SHAKE256 (M,d) ::= KECCACK[512](M||1111, d)
> 
> Now RFC8702 says that SHAKE256 should use d = 512 if you're using it as a hash/message digest, but I can't find anywhere in the NIST document that also use that value as a default.  That worries me with respect to future interoperability.
> 
> The main advantage of id-sha3-256 in this instance is that the definition associated with that OID makes clear that SHA3-256 has a fixed output of 256 bits.   If I were going to use SHAKE256-512, I'd rather use id-shake256-len as the OID and parameterize it with that length in an AlgorithmIdentifer so that it was clear to the receiver just what I was doing with the XOF.
> 
> Alg-SHAKE256-LEN ALGORITHM ::= { OID id-shake256-len PARMS ShakeOutputLen }
> id-shake256 is an  unparameterized OID and that means I have to figure out what the length is from context and hope an implementer didn't miss getting to the same context.  RFC8702 section 3.1 notwithstanding.
> 
> With respect to pluralism, what I mean is the ability to plug in approved algorithms that more closely meet a set of requirements.  One of the things I dislike about the pq-kem document is that choices like the particular KDF to use are implied by the KEM algorithm OID and can't be easily substituted without starting over.  Compare and contrast RFC5990 and the RSA-KEM parameters definition.
> 
> Later, Mike
> 
>  
> 
>  
> 
>  
> 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 <https://urldefense.com/v3/__https:/csrc.nist.gov/Projects/computer-security-objects-register/algorithm-registration__;!!FJ-Y8qCqXTj2!dANQSh0mKJ9qwy0EFgNZVn5T2FrIWDG_l5rlc3-Ean-nzsgR_LwHK2ta8wm6lPACrEMPhdCvx49TQ9YYvfjGiKId360$> 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 <[e-mail]> <mailto:[e-mail]> On Behalf Of Mike Ounsworth
> Sent: Saturday, October 28, 2023 2:08 PM
> To: Russ Housley <[e-mail]> <mailto:[e-mail]>; Kampanakis, Panos <[e-mail]> <mailto:[e-mail]>
> Cc: LAMPS <[e-mail]> <mailto:[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 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-kem-02*name-rsa-kem-parameters__;Iw!!FJ-Y8qCqXTj2!dANQSh0mKJ9qwy0EFgNZVn5T2FrIWDG_l5rlc3-Ean-nzsgR_LwHK2ta8wm6lPACrEMPhdCvx49TQ9YYvfjGPwOTnfY$>
>  
> 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 <kpanos=40amazon. com@ dmarc. ietf. org> <mailto:kpanos=40amazon.%E2%80%8Acom@%E2%80%8Admarc.%E2%80%8Aietf.%E2%80%8Aorg> 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 <[e-mail] <mailto:[e-mail]>> On Behalf Of Tim Hollebeek
> Sent: Friday, October 27, 2023 11:39 AM
> To: SPASM <[e-mail] <mailto:[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://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-sha3-hash-00 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-housley-lamps-cms-sha3-hash-00__;!!FJ-Y8qCqXTj2!btMHx3oQg1XcdsmiDk3zQn-HVGxUExFHzJp0v2bwunfFVR3P8235FQ_QH4pzRkyD49fJSywzek8dgSw-P9DqGArWDMhf$>
>  
> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spasm <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!btMHx3oQg1XcdsmiDk3zQn-HVGxUExFHzJp0v2bwunfFVR3P8235FQ_QH4pzRkyD49fJSywzek8dgSw-P9DqGMDI1k9b$>
>  
> 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 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!dANQSh0mKJ9qwy0EFgNZVn5T2FrIWDG_l5rlc3-Ean-nzsgR_LwHK2ta8wm6lPACrEMPhdCvx49TQ9YYvfjGTEWqXBw$>
>  
> 
>  
> 
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spasm