Subject: [COSE] Review of draft-ietf-cose-hash-algs-01

From: Ludwig Seitz <[email-masked]>
Date: Wed, 25 Sep 2019 09:23:35 +0200

Hello group,

here is my review of draft-ietf-cose-hash-algs-01.

==

The draft talks about identifying objects with hashes, should we add an 
informal reference to RFC 6920?

==

2.

Expand the abbreviation 'HSM' at first use.

==

2.1

"There is no definition here of what goes into the 'any' value and how 
it would be included in the computed hash value."

Perhaps prepend a "Note: " ?

==

2.1

there needs to be a manual line break for readability in the COSE_Hash_V 
example.

==

3.3

The reference for SHA-3 is wrong. FIPS-180-4 does not mention SHA-3 or 
SHAKE. The reference should be FIPS-202.

==
3.3 Table 3

Any specific reasons why we do not specify identifiers for SHA3-224,
SHA3-256, SHA3-384 and SHA3-512?

==

Section 4:

"Many of the hash values ... even though it is a shorter value."

Does this need to be in the final document? It feels more like a
hint for IANA and designated experts when deciding on the value of the
identifier, so I think it should be prepended with "RFC Editor: Please 
remove this paragraph"

==

Regards,

Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Jim Schaad <[email-masked]>
Date: Wed, 25 Sep 2019 16:32:27 -0700

Ludwig - see inline

-----Original Message-----
From: COSE <[email-masked]> On Behalf Of Ludwig Seitz
Sent: Wednesday, September 25, 2019 12:24 AM
To: [email-masked]
Subject: [COSE] Review of draft-ietf-cose-hash-algs-01

Hello group,

==

The draft talks about identifying objects with hashes, should we add an informal reference to RFC 6920?

[JLS] I am not sure what you think the purpose of this would be.  One could potentially use the "ni" URI form inside of the URL, one could just say "Oh, here is a way we did not choose to use."  I don't see that either of these would be especially useful.  What type of text do you think would go with such a reference?

==

2.

[JLS] High School Musical - the film? https://en.wikipedia.org/wiki/High_School_Musical
Fixed.

==

2.1

"There is no definition here of what goes into the 'any' value and how it would be included in the computed hash value."

[JLS]  I did the following:
1.  Rewrite the additional data bullet to be:
            Additional data, this can be something as simple as a random value to make finding hash collisions slightly harder as the value handed to the application cannot have been selected to have a collision, or as complicated as a set of processing instructions that are used with the object that is pointed to.
            The additional data can be dealt with in a number of ways, prepending or appending to the content, but it is strongly suggested to it either be a fixed known size, or the lengths of the pieces being hashed be included.
            (Encoding as a CBOR array accomplished this requirement.)

2. Remove the second sentence that was included above.
3. Remove the sentence fragment on appending from the CDDL structure.

==

2.1

there needs to be a manual line break for readability in the COSE_Hash_V example.
[JLS] It is really there - this was an xml2rfc error

==

3.3

The reference for SHA-3 is wrong. FIPS-180-4 does not mention SHA-3 or SHAKE. The reference should be FIPS-202.

[JLS] That makes me feel kind of foolish, I did not even bother to look.

==
3.3 Table 3

Any specific reasons why we do not specify identifiers for SHA3-224, SHA3-256, SHA3-384 and SHA3-512?

[JLS]  I cannot address what other bodies are going to do, but the general consensus for the IETF seems to have resolved on using the SHAKE hash functions rather than using the SHA-3 hash functions.  This is true for Ed448, for the new CMS algorithms being defined by LAMPS.  It would also be better to use SHAKE as this is also the set of functions that would later be used for KMAC.   Based on that, and the fact that the SHAKE algorithms come with truncation already included, I did not see any reason to use the SHA-3 algorithms.  I am not positive, but I believe I saw something that said SHAKE was faster than SHA-3 as well.  Don't quote me on that.

==

Section 4:

Does this need to be in the final document? It feels more like a hint for IANA and designated experts when deciding on the value of the identifier, so I think it should be prepended with "RFC Editor: Please remove this paragraph"

[JLS] I have tagged for removal -It is really a justification for the DE to use when assigning numbers.

Jim

==

Regards,

Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51