[COSE] Benjamin Kaduk's No Objection on draft-ietf-cose-hash-algs-06: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cose-hash-algs-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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