CBOR Object Signing and Encryption (COSE): Hash Algorithms
draft-ietf-cose-hash-algs-09

Note: This ballot was opened for revision 04 and is now closed.

Murray Kucherawy Yes

Barry Leiba Yes

Comment (2020-06-01 for -04)
— Abstract —

   There are however circumstances where
   hash algorithms are used, such as indirect signatures where the hash
   of one or more contents are signed, and X.509 certificate or other
   object identification by the use of a fingerprint.

I found this hard to parse, and had to read it a few times.  How about this?:

NEW
   There are, however, circumstances where
   hash algorithms are used, such as in indirect signatures, where the hash
   of some content is signed, and for fingerprinting of X.509 certificates or
   other objects.
END

— Introduction —

   This omission was intentional as a structure consisting of
   just a digest identifier, the content, and a digest value does not by
   itself provide any strong security service.

Nit: this needs a few more commas... one after “intentional”, and one before and one after “by itself”.

   One of the primary things that has been identified by a hash
   function for secure message is a certificate.

Another that I had trouble parsing.  Maybe, “One of the primary things related to secure messages that has been identified by a hash function is a certificate.”

— Section 2 —

   hash functions is part of the base design as cryptographic advances
   are sure to reduce the strength of a hash function.

Nit: this needs a comma after “design”.

   The standard "Collision Attack" is one where an attacker can
   find two different messages that have the same hash value.  If a
   collision attack exists, then the function SHOULD NOT be used for a
   cryptographic purpose.

I’m uncomfortable with having this document give a brief tutorial on cryptographic hashing, as it has to be oversimplified... and it is.  If it’s going to stay, I’d like to see ar least one minor change, though I’ll defer to the Sec ADs on this point: for any hash alg, it is always possible to encounter a collision, and the text isn’t clear about what “if a collision attack exists” really means.  I think it means not to use it if a collision attack is practical, and maybe this is a better way to say it?:

NEW
   A "collision attack" is one where an attacker can
   find two different messages that have the same hash value.  A
   hash function that is susceptible to collision attacks, SHOULD
   NOT be used for cryptographic purposes.
END

   checked to see if they are the correct one.

“They are the correct one?”  Oof.  How about, “to find the correct one,” or (maybe better), “to see if they are suitable.”?

   If the fingerprint is
   used to verify that it is the correct certificate, then that usage is
   subject to a collision attack as above.  If however, the fingerprint
   is used to sort through a collection of certificates

“then that usage is a cryptographic one and is subject to the warning above about collision attacks.”  And “however” also needs a comma before it, as well as after.

   In this case, one still needs to
   validate that the public key validates the signature

Make the first “validate” say “confirm” instead, to avoid the awkward double use of “validate”.

   To distinguish between these two cases, a new value in the
   recommended column of the COSE Algorithms registry is to be added.
   "Filter Only" indicates that the only purpose of a hash function
   should be to filter results and not those which require collision
   resistance.

Might it be better to have the new column be called “cryptographic use”, with values of “yes” and “no”?  Hint: I think it would.  Hint#2: this is a non-blocking comment, so you might disagree.

— Section 2.1 —

   *  Additional data, this can be something as simple as a random value

Nit: make the comma a semicolon.

      appending to the content, but it is strongly suggested to it

Nit: change “to it” to “that it”.

— Section 3.1 —

   Because of the known issues for SHA-1 and the fact that is should no

Nit: change “that is” to “that it”.

— Section 3.2 —

      Locations that use this hash function
      need either to analysis the potential problems with having a
      collision occur, or where the only function of the hash is to
      narrow the possible choices.

Locations?  And do you mean to use “analysis” as a verb?  Maybe this?:

NEW
      Use of this hash function
      needs analysis of the potential problems with having a
      collision occur, or must be limited to where the function
      of the hash is non-cryptographic.
END

— Section 3.3 —

   One of the benefits of this
   differences is that when computing a shorter SHAKE hash value

Nit: “difference”, singular.

— Section 5 —

   that need the cryptographic properties, i.e. collision resistance,
   and properties that correspond to possible object identification.

Collision resistance isn’t the only cryptographic property (there’s also, for example, preimage resistance), so change “i.e.” to “such as”.  This is another example of the hazard of trying to explain hashing in a simple document such as this one.

   This is
   the difference between collision resistance and second pre-image
   resistance.

If you have collision resistance, don’t you automatically have second preimage resistance?  What’s he point of mentioning second preimage resistance here, when you don’t mention it nor need it anywhere else?

   are under constant attack and the strength of hash algorithms will be
   reduced over time.

I would say “the cryptographic strength”.

Deborah Brungard No Objection

Roman Danyliw No Objection

Comment (2020-06-08 for -04)
Thanks for extending COSE for this additional use. 

** I added my thoughts on the Section 2 language to the email thread of Barry’s ballot

** Per “To distinguish between these two cases, a new value in the
   recommended column of the COSE Algorithms registry is to be added.
   "Filter Only" indicates that the only purpose of a hash function
   should be to filter results and not those which require collision
   resistance”, I would recommend:

NEW:
To distinguish between these two cases, a new value in the recommended column of the COSE Algorithms registry is to be added.  "Filter Only" indicates that the only purpose of a hash function should be to filter results and it is not intended for applications which require a cryptographically strong algorithm is needed.

It doesn’t change the intent, but it does generalize to all the security properties we might want of a hash algorithm.

** Section 5.  Since collision and second-preimage attacks are mentioned, for completeness it would be worth mentioning the need for preimage resistance for cryptographic usage too.

** Editorial nits:

-- Abstract.  Editorial. The abstract has an explicit reference, [I-D.ietf-cose-rfc8152bis-struct], which abstracts are not permitted to have.

-- Section 2.1. Editorial.  s/this could /This could/

-- Section 3.1. Editorial. s/assign a point/assign a code point/

-- Section 3.2. Editorial.

OLD
Locations that use this hash function
      need either to analysis the potential problems with having a
      collision occur, or where the only function of the hash is to
      narrow the possible choices.

NEW
Applications that use this hash function need either to analyze the potential impact with having a collision occur, or use it only where the function of the hash is to narrow the possible choices.

-- Section 3.3.  Per “The pair of algorithms known as SHAKE-128 and SHAKE-256 are the instances of SHA-3 that are currently being standardized in the IETF”, it isn’t clear this sentence will age well.

-- Section 4.  Typo. s/preseved/preserved/

Martin Duke No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-07-10 for -06)
Thanks for the past and pending updates to address my Discuss point.
A few new comments on the -06:

Section 2

   attacks, SHOULD NOT be used for a cryptographic purpose.  The
   discovery of theoretical collision attacks against a given hash
   function SHOULD trigger a review of the continued suitability of the
   algorithm if alternatives are available and migration is viable.  The

It's not really clear who this SHOULD is binding upon.

   An example of a non-cryptographic use of a hash is for filtering from
   a collection of values to find a set of possible candidates, the
   candidates can then be check to see if they can successfully be used.

This turned into a comma splice; I'd just make it use a semicolon (and
independently do s/check/checked/)

Section 3.1

   this hash algorithm.  Some of these situations are with historic HSMs
   where only SHA-1 is implemented, other situations are where the SHA-1
   value is used for the purpose of filtering and thus the collision
   resistance property is not needed.

nit: comma splice

   The COSE capabilities for these algorithms is an empty array.

This went from "this algorithm" to "these algorithms" in the -05, but
I missed why -- it's just the one SHA-1 algorithm, I thought.

Section 3.2

   *  *SHA-256/64* provides a truncated hash.  The length of the
      truncation is designed to allow for smaller transmission size.
      The trade-off is that the odds that a collision will occur
      increase proportionally.  Use of this hash function needs analyze
      of the potential problems with having a collision occur, or must
      be limited to where the function of the hash is non-cryptographic.

With the rest of the rewording, we have to go back to "analysis" from      
"analyze".  (Sorry!)

Section 3.3

   The SHA-3 hash algorithms have a significantly different structure
   than the SHA-2 hash algorithms.  One of the benefits of this
   difference is that when computing a shorter SHAKE hash value, the
   value is not a prefix of the result of computing the longer hash.

(This last sentence is scheduled for removal.)

Erik Kline No Objection

Comment (2020-06-09 for -04)
No email
send info
[[ nits ]]

[ section 2.1 ]
* "suggested to it" -> "suggested that it"

[ section 3.2 ]
* "need either to analysis" -> I couldn't come up with a good fix for this

Warren Kumari No Objection

Comment (2020-06-01 for -04)
Thank you for writing this - it was an interesting read.

I do have one issue, which I cannot tell if it is simply me being dumb, or if the text needs more work.

“ Doing indirect signing allows for a signature to be validated without first downloading all of the  content associated with the signature.  This capability can be of   even greater importance in a constrained environment as not all of   the content signed may be needed by the device.”

I’m unclear how this works —  itseems clear enough that I can verify that the signature matches the hash, but doesn’t the device need to still download and compute the hash over all of the content?

Otherwise I could take a hash and signature from content A, and claim that it is for content B. Sure, if the signature **doens’t** match the hash I know not to bother downloading the content at all, but if the sig does match the hash I still need to download the content to check that the hash is for this content....

Please help educate me!

Nit: “ A pointer to the value that was hashed.  this could” — s/this/This/

Alvaro Retana No Objection

Éric Vyncke No Objection

Robert Wilton No Objection

Comment (2020-06-09 for -04)
Hi,

Thank you for this document, I found it easy to read and understand.  A few minor comments:

1.  Introduction

   Indirect signing of content is a paradigm where the content is not
   directly signed, but instead a hash of the content is computed and
   that hash value, along with the hash algorithm, is included in the
   content that will be signed.  Doing indirect signing allows for a
   signature to be validated without first downloading all of the
   content associated with the signature.  This capability can be of
   even greater importance in a constrained environment as not all of
   the content signed may be needed by the device.
   
Would it be better to write "along with an identifier for the hash algorithm"?

1.  Introduction

   The use of hashes to identify objects is something that has been very
   common.  One of the primary things that has been identified by a hash
   function for secure message is a certificate.  Two examples of this
   can be found in [ESS] and the newly defined COSE equivalents in
   [I-D.ietf-cose-x509].
   
Perhaps drop "newly defined"?

3.2.  SHA-2 Hash Algorithms

   *  *SHA-256* is probably the most common hash function used
      currently.  SHA-256 is an efficient hash algorithm for 32-bit
      hardware.
      
Is this intended to imply that SHA-256 is not an efficient hash algorithm when running on 64-bit hardware?  If so, that might be worth explicitly stating, although it is implied by the description for SHA-512/256.

3.3.  SHAKE Algorithms

Would this be more clear to be titled as SHA-3 Algorithms?

Thanks,
Rob