Subject: [COSE] Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 08 Jun 2020 20:22:50 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-cose-hash-algs-04: 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 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/

---

From: Jim Schaad <[email-masked]>
Date: Mon, 8 Jun 2020 21:17:04 -0700

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]> 
Sent: Monday, June 8, 2020 8:23 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Ivaylo Petrov <[email-masked]>; [email-masked]
Subject: Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT)

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

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

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.
[JLS] Yes that makes sense, but I removed the trailing "is needed" because it does not read well.

** 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.
[JLS] ACK - I left it this way because it is a draft and not an RFC to make sure that it is highlighted for the RFC Editor.

[JLS] Already caught.

[JLS] Done.

OLD

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.
[JLS] This was already rewritten in response to comments from Barry.

              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.

-- 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.
[JLS] It may not age well but it is why these are the ones in the document.  Perhaps "currently being standardized in the IETF.  This is the reason for including these algorithms in this document."

[JLS] Fixed

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 9 Jun 2020 12:24:01 +0000

Hi Jim!

Thanks for the quick response. You refinements below are an improvement over mine.  Thanks for making them.

Regards,
Roman

> From: Jim Schaad <[email-masked]>
> Sent: Tuesday, June 9, 2020 12:17 AM
> To: Roman Danyliw <[email-masked]>; 'The IESG' <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> 'Ivaylo Petrov' <[email-masked]>
> Subject: RE: Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04:
> (with COMMENT)
> 
> 
> 
> Cc: [email-masked]; [email-masked]; [email-masked];
> Ivaylo Petrov <[email-masked]>; [email-masked]
> 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.)
> 
> 
> 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
> 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.
> [JLS] ACK - I left it this way because it is a draft and not an RFC to make sure
> that it is highlighted for the RFC Editor.
> 
> -- Section 2.1. Editorial.  s/this could /This could/ [JLS] Already caught.
> 
> -- Section 3.1. Editorial. s/assign a point/assign a code point/ [JLS] Done.
> 
>               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.
> 
> are the instances of SHA-3 that are currently being standardized in the IETF”, it
> isn’t clear this sentence will age well.
> [JLS] It may not age well but it is why these are the ones in the document.
> Perhaps "currently being standardized in the IETF.  This is the reason for
> including these algorithms in this document."
> 
> -- Section 4.  Typo. s/preseved/preserved/ [JLS] Fixed
> 
>