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

[Michael StJohns <[e-mail]>]

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]> *On Behalf Of * Michael StJohns
> *Sent:* Saturday, October 28, 2023 11:50 PM
> *To:* [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 <[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
>
>     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]> on behalf of Russ Housley
>     <[e-mail]>
>     *Sent:* Saturday, October 28, 2023 10:44:57 AM
>     *To:* Panos Kampanakis <[e-mail]>
>     *Cc:* LAMPS <[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. 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]> 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]
>
>     https://www.ietf.org/mailman/listinfo/spasm
>