Subject: [Curdle] Comments on draft-housley-cms-eddsa-signatures

From: Russ Housley <[email-masked]>
Date: Mon, 2 May 2016 13:32:26 -0400

Jim Schaad sent me some comments on this document.  Since I have asked this
working group to adopt this draft, I have gotten Jim’s permission to respond to
the comments on list.

> 1.  I am not sure that I see a great deal of benefits for doing both the
> pre-hash version and pure version of EdDSA.   Specifically, the use of the
> pre-hash version really only seems to make sense if one does not use signed
> attributes.  However, I think that this is a case which would never occur
> for this signature algorithm.

Right.  Since signed attributes are the most common use with CMS, it is
probably better to just make use of PureEdDSA.

I suggest adding this text to Section 2 of the document:

   One of the parameters of the EdDSA algorithm is the "prehash"
   function.  This may be the identity function, resulting in an
   algorithm called PureEdDSA, or a collision-resistant hash function,
   resulting in an algorithm called HashEdDSA.  In most situations the
   CMS SignedData includes signed attributes, including the message
   digest of the content.  Since HashEdDSA offers no benefit when signed
   attributes are present, only PureEdDSA is used with the CMS.

And, then change Section 2.1 like this:

   When the id-EdDSAPublicKey onject identifier is used, the
   AlgorithmIdentifier parameters field MUST contain EdDSAParameters to
   specify a particular set of EdDSA parameters:

      EdDSAParameters ::= ENUMERATED {
        ed25519   (1),    -- PureEdDSA
        ed25519ph (2),    -- HashEdDSA; not used in the CMS
        ed448     (3),    -- PureEdDSA
        ed448ph   (4) }   -- HashEdDSA; not used in the CMS

> 2.  We need to get a definition of how to use SHAKE256 from someplace if we
> are going to say use the same hash algorithm throughout as that is what
> Ed448 uses.  It would be worthwhile to specify what hash algorithms should
> be used with each of the different signature algorithms given that it is not
> clear from the name of the algorithm identifier.

This document references draft-irtf-cfrg-eddsa-05, and that document
includes this reference for SHAKE256:

   [FIPS202]  National Institute of Standards and Technology, U.S.
              Department of Commerce, "SHA-3 Standard: Permutation-Based
              Hash and Extendable-Output Functions", FIPS 202, August
              2015.

I’m not sure what more you think is needed.

> 3.  In section 3 para 2: This sentence does not necessarily make sense for
> the pure version of EdDSA.  In some sense there is no hash function which is
> used on the signedAttribute value.  I don't know that it needs to be fixed,
> but it might be somewhat confusing.

You are talking about this paragraph:

   The same one-way hash function SHOULD be used for computing the
   message digest on both the eContent and the signedAttributes value if
   signedAttributes are present.

I think the principle is correct.  I’m not sure how to address your comment.

> 4.  In section 4, the problem with EdDSA is worse for the use of different
> algorithms than what you are stating.  It is possible to do some interesting
> forgeries if you cross between the pre-hash and not pre-hash versions with
> the Ed25519 curve since there is no context difference between them.  This
> has to be forbidden not just strongly suggested.

Does the removal of HashEdDSA resolve this one?

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 2 May 2016 11:45:19 -0700

Russ,

Comments inline.

jim

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Monday, May 02, 2016 10:32 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: [Curdle] Comments on draft-housley-cms-eddsa-signatures

Jim Schaad sent me some comments on this document.  Since I have asked this
working group to adopt this draft, I have gotten Jim's permission to respond
to the comments on list.

> pre-hash version really only seems to make sense if one does not use 
> signed attributes.  However, I think that this is a case which would 
> never occur for this signature algorithm.

[JLS] Both of those changes look very reasonable.

> 2.  We need to get a definition of how to use SHAKE256 from someplace 
> if we are going to say use the same hash algorithm throughout as that 
> is what
> Ed448 uses.  It would be worthwhile to specify what hash algorithms 
> should be used with each of the different signature algorithms given 
> that it is not clear from the name of the algorithm identifier.

I'm not sure what more you think is needed.

[JLS] To start with, I think we need to get a reference for an OID for the
SHAKE256 algorithm from NIST (or internally) since that is needed as one of
the authenticated attributes.

I worry that since we have changed this set of identifiers from saying X
with Y to just saying X that there is going to be a degree of people missing
which algorithm is being used as a hash algorithm for this.  

A second worry is that SHAK256 is defined as being an XOF function and not a
hash function.  I think it might make more sense to say that we should be
using SHA3-256 rather than SHAKE256.  In any event the OID assigned on the
NIST web site does not make any statements about the size of output of
SHAKE256 and if we are going to use it as a hash algorithm here we need to
do that.  Suffice it to say that I don't think that using SHAKE256 as a hash
algorithm here is sufficiently defined.

> 3.  In section 3 para 2: This sentence does not necessarily make sense 
> for the pure version of EdDSA.  In some sense there is no hash 
> function which is used on the signedAttribute value.  I don't know 
> that it needs to be fixed, but it might be somewhat confusing.

I think the principle is correct.  I'm not sure how to address your comment.

[JLS] Yeah, I am not sure how to address my comment here either.  The
problem as stated above is that there is no explicit hash function that is
used as a pre-hash to the signature so people might not know what hash
algorithm to be using here.

> 4.  In section 4, the problem with EdDSA is worse for the use of 
> different algorithms than what you are stating.  It is possible to do 
> some interesting forgeries if you cross between the pre-hash and not 
> pre-hash versions with the Ed25519 curve since there is no context 
> difference between them.  This has to be forbidden not just strongly
suggested.

[JLS] Yes that would deal with this issue.  However, given that currently
the difference is just a field in the enumeration it should probably have a
security consideration about it.  If we can change the PKXI draft so that
the pre-hash and pure versions using different OID identifiers, then this
because much cleaner and less of a worry.  It would currently be potentially
necessary to make a RFC 2119 statement about the enumeration which is not
proposed above.

Russ

_______________________________________________
Curdle mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/curdle

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 3 May 2016 15:39:29 +0000

Hi Jim, Russ and all,

NIST currently plans to allow the SHAKEs to be used. Please see the document attached to the email John Kelsey sent out on 4/8/2016 with the email titled Customized shake. The uses of SHAKE256 in the EdDSA with Ed448 are good (prehash and without prehash versions).

SHAKE256 is used as a prf in the PureEdDSA with ed448 and a prf produces different output sizes depending on the needs.

If an OID for SHAKE256 with some specific output length is needed, NIST can help, just let us know!

Regards,
Quynh.

________________________________________
From: Curdle <[email-masked]> on behalf of Jim Schaad <[email-masked]>
Sent: Monday, May 2, 2016 2:45:19 PM
To: 'Russ Housley'
Cc: [email-masked]
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

Russ,

Comments inline.

jim

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Monday, May 02, 2016 10:32 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: [Curdle] Comments on draft-housley-cms-eddsa-signatures

suggested.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 3 May 2016 13:12:11 -0700

Quynh,

I see that NIST has assigned an OID for SHA256, when they assigned it did
they have ideas on when and where it was going to be used.  Or did they just
assign one because it didn't have one without thinking about it?

Jim

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Dang, Quynh (Fed)
Sent: Tuesday, May 03, 2016 8:39 AM
To: Jim Schaad <[email-masked]>; 'Russ Housley'
<[email-masked]>
Cc: [email-masked]

Hi Jim, Russ and all,

NIST currently plans to allow the SHAKEs to be used. Please see the document
attached to the email John Kelsey sent out on 4/8/2016 with the email titled
Customized shake. The uses of SHAKE256 in the EdDSA with Ed448 are good
(prehash and without prehash versions).

SHAKE256 is used as a prf in the PureEdDSA with ed448 and a prf produces
different output sizes depending on the needs.

If an OID for SHAKE256 with some specific output length is needed, NIST can
help, just let us know!

Regards,
Quynh.

________________________________________
From: Curdle <[email-masked]> on behalf of Jim Schaad
<[email-masked]>
Sent: Monday, May 2, 2016 2:45:19 PM
To: 'Russ Housley'
Cc: [email-masked]
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

Russ,

Comments inline.

jim

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Monday, May 02, 2016 10:32 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: [Curdle] Comments on draft-housley-cms-eddsa-signatures

suggested.

Russ

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 4 May 2016 11:46:36 +0000

Hi Jim,

There are at least two obvious uses. The first one is for full-domain hash RSA signatures. Either SHAKE128 or SHAKE256 can produce a hash value of the size equal to any RSA modulus size naturally (at two different security strength levels: 128 and 256 bits). The size of a hash output is determined by the size of the RSA modulus. Therefore, in a full-domain hash RSA signature standard, one can just identify which function to be used. So, the OIDs for the SHAKE128 and SHAKE256 are useful here. 

The second use is in RSASSA-PSS where a new MGF can be defined as a SHAKE and the size of an output from this new MGF is determined by the RSA modulus size and the size of a salt. Therefore, only the OIDs of the SHAKEs are needed in this situation. The SHAKEs produce variable-length outputs in a natural way instead of using some mode of operations with SHA2s and HMAC. 

Also, the SHAKEs do not rehash/reprocess input when more output bits are needed. They are efficient construction (Sponge), not like SHA2s and HMAC. 

Regards,
Quynh. 
________________________________________
From: Jim Schaad <[email-masked]>
Sent: Tuesday, May 3, 2016 4:12 PM
To: Dang, Quynh (Fed); 'Russ Housley'
Cc: [email-masked]
Subject: RE: [Curdle] Comments on draft-housley-cms-eddsa-signatures

Quynh,

Jim

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Dang, Quynh (Fed)
Sent: Tuesday, May 03, 2016 8:39 AM
To: Jim Schaad <[email-masked]>; 'Russ Housley'
<[email-masked]>
Cc: [email-masked]

Hi Jim, Russ and all,

Regards,
Quynh.

Russ,

Comments inline.

jim

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Monday, May 02, 2016 10:32 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: [Curdle] Comments on draft-housley-cms-eddsa-signatures

suggested.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 5 May 2016 16:05:26 -0400

> working group to adopt this draft, I have gotten Jim's permission to respond

Dropping items 1 and 3 since they seem to be resolved.

See below for the continued discussion of items 2 and 4.

> the authenticated attributes.

Based on other traffic on this list, I hope that NIST will assign the OID.

> which algorithm is being used as a hash algorithm for this.

We need to do the same thing with this document and draft-ietf-curdle-pkix-eddsa.

I have started a separate thread on this mail list.  Let’s have the discussion on that thread, and then put the conclusion in both documents.

> algorithm here is sufficiently defined.

Doesn’t this need to be addressed in draft-irtf-cfrg-eddsa?

> necessary to make a RFC 2119 statement about the enumeration which is not

Hopefully the direction for this will emerge from the discussion on the other thread.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 5 May 2016 13:47:12 -0700

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Thursday, May 05, 2016 1:05 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

Jim:

> SHAKE256 algorithm from NIST (or internally) since that is needed as 
> one of the authenticated attributes.

[JLS] They have assigned an OID for SHAKE256, I just don't know if it was
done "correctly" for our purposes.  We will need to work that out. I still
need to look at and think about Quynh's response to my message.

> I worry that since we have changed this set of identifiers from saying 
> X with Y to just saying X that there is going to be a degree of people 
> missing which algorithm is being used as a hash algorithm for this.

We need to do the same thing with this document and
draft-ietf-curdle-pkix-eddsa.

I have started a separate thread on this mail list.  Let's have the
discussion on that thread, and then put the conclusion in both documents.

> A second worry is that SHAK256 is defined as being an XOF function and 
> not a hash function.  I think it might make more sense to say that we 
> should be using SHA3-256 rather than SHAKE256.  In any event the OID 
> assigned on the NIST web site does not make any statements about the 
> size of output of
> SHAKE256 and if we are going to use it as a hash algorithm here we 
> need to do that.  Suffice it to say that I don't think that using 
> SHAKE256 as a hash algorithm here is sufficiently defined.

Doesn't this need to be addressed in draft-irtf-cfrg-eddsa?

[JLS] No, I am not worried about how SHAKE256 is being used in the EdDSA
process (it is fully defined there), I am looking at the use of SHAKE256
when it is placed in the digestAlgorithm attribute of the SignerInfo
structure.  In this case the length of the output needs to be specified
(i.e. how long is the message digest signed attribute).  This is defined for
hash algorithms, but is not defined for XOF functions.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 5 May 2016 20:08:00 -0400

> hash algorithms, but is not defined for XOF functions.

I was not understanding you issue until now…

You are worried about this:

       Compute SHAKE256(dom(F, C) || prefix || M, 114), where M is the
       message to be signed, …

Maybe we just make M = SHA512(ValueOnly(DER(SignedAttrs)))

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 5 May 2016 17:39:53 -0700

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Thursday, May 05, 2016 5:08 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

On May 5, 2016, at 4:47 PM, Jim Schaad <[email-masked]> wrote:

>> A second worry is that SHAK256 is defined as being an XOF function 
>> and not a hash function.  I think it might make more sense to say 
>> that we should be using SHA3-256 rather than SHAKE256.  In any event 
>> the OID assigned on the NIST web site does not make any statements 
>> about the size of output of
> [JLS] No, I am not worried about how SHAKE256 is being used in the 
> EdDSA process (it is fully defined there), I am looking at the use of 
> SHAKE256 when it is placed in the digestAlgorithm attribute of the 
> SignerInfo structure.  In this case the length of the output needs to 
> be specified (i.e. how long is the message digest signed attribute).  
> This is defined for hash algorithms, but is not defined for XOF functions.

I was not understanding you issue until now.

       message to be signed, .

Russ

[JLS]  No that is not what I am worried about.  What I am worried about is

  SignerInfo ::= SEQUENCE {
      version CMSVersion, --  == 1 or 3 
      sid SignerIdentifier,  -- Identifier of the signer
      digestAlgorithm DigestAlgorithmIdentifier,  --- AlgorithmIdentifier(
{hashAlgs 12}, absent )
      signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, { contains
Attribute{ aa-messageDigest, SET OF { OCTET STRING { SHAKE256(Message Body)
}}
      signatureAlgorithm SignatureAlgorithmIdentifier,  -- id-edDSA
      signature SignatureValue, -- cryptographic result of eddsa with
		--  SHAKE256(dom(F, C) || prefix || DER(SignedAttrs), 114)
		--      where DER(SignedAttrs) = M just as would be
expected.
      unsignedAttrs [1] IMPLICIT Attributes
          {{UnsignedAttributes}} OPTIONAL }

The length of SHAKE256(Message Body) is not defined nor is there any place
for it to be specified by a parameter.   Specifically one needs to be able
to say that the messageDigest = SHAKE256(Message Body, 114)  (Or maybe just
57? If you want to do some type of size matching since the EdDSA uses a
double width hash algorithm internally)

Jim

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Fri, 6 May 2016 10:53:43 +0000

Hi Russ,

Since SHAKE256 is used in the function, one just goes with SHAKE256/512 instead of SHA512 and just needs to allocate on OID for SHAKE256/512.

Regards,
Quynh. 

________________________________________
From: Curdle <[email-masked]> on behalf of Russ Housley <[email-masked]>
Sent: Thursday, May 5, 2016 8:08 PM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

Russ

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Fri, 6 May 2016 11:16:15 +0000

Hi Jim,

To hash the signedAttributes value, SHAKE256/512 would be great.

For ed25519 and ed448 EdDSA signatures, hash algorithm OID should be null/absent. For ed25519ph and ed448ph, the hash algorithm is the prehash function: SHA512 for ed25519ph and SHAKE256/512 for ed448ph. 

Regards,
Quynh. 

________________________________________
From: Curdle <[email-masked]> on behalf of Jim Schaad <[email-masked]>
Sent: Thursday, May 5, 2016 8:39 PM
To: 'Russ Housley'
Cc: [email-masked]
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Thursday, May 05, 2016 5:08 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

Russ

Jim

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 May 2016 11:23:28 +1000

> For ed25519 and ed448 EdDSA signatures, hash algorithm OID should be null/absent. For ed25519ph and ed448ph, the hash algorithm is the prehash function: SHA512 for ed25519ph and SHAKE256/512 for ed…

The decision in TLS was to treat signature and hash as a single
primitive, rather than a composable one, since these are not
composable anyway. And Russ has suggested to drop the *ph versions,
which is a good idea.

That suggests no need to identify SHAKE* with respect to the
signatures, only to use in other parts of the CMS that need hashes.
And only where you want the hashes to be consistent throughout.

Could Jim's concern about size be addressed by defining different OIDs
for different output sizes?

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 8 May 2016 20:07:27 -0700

This would definitely be one approach to solving my issue.  The second would
be to define a new OID which takes an integer parameter which is the size of
the desired output.

Jim

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Sunday, May 08, 2016 6:23 PM
To: Dang, Quynh (Fed) <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Russ Housley
<[email-masked]>; [email-masked]
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

On 6 May 2016 at 21:16, Dang, Quynh (Fed) <[email-masked]> wrote:
> For ed25519 and ed448 EdDSA signatures, hash algorithm OID should be
null/absent. For ed25519ph and ed448ph, the hash algorithm is the prehash
function: SHA512 for ed25519ph and SHAKE256/512 for ed448ph.

The decision in TLS was to treat signature and hash as a single primitive,
rather than a composable one, since these are not composable anyway. And
Russ has suggested to drop the *ph versions, which is a good idea.

That suggests no need to identify SHAKE* with respect to the signatures,
only to use in other parts of the CMS that need hashes.
And only where you want the hashes to be consistent throughout.

Could Jim's concern about size be addressed by defining different OIDs for
different output sizes?