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

[[ 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

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/

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/

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.)

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