Subject: [COSE] Comments on draft-ietf-cose-hash-algs-00

From: John Mattsson <[email-masked]>
Date: Thu, 21 Mar 2019 08:34:30 +0000

Well-written. I think the selection of algorithms is correct. Great to see more work on the work on the very useful COSE format.

In Table 1: "SHA-1 Hash" -> "SHA-1 160-bit Hash" to align with Table 2

- "The trade-off is that the odds that a collision will occur increase proportionally"

Correct in an English language kind of way, but not what mathematicians call proportionally, I would suggest removing " proportionally"

-"*SHA-256* is probably the most common hash function"

Let's hope so, but I would probably still bet my money on SHA-1...., maybe remove this sentence anyway as it may not be true in the future, and the "probably" indicates that we do not really know.

"SHA-256 is the most efficient hash algorithm for 32-bit hardware."

I suggest changing to "very efficient" as there are likely some exceptions.

- "SHA-512/256 .... offers the same security levels as SHA-256."

SHA-512/256 offers much better resistance against length extension attacks than SHA-256. I suggest changing to

"SHA-512/256 .... offers the same collision resistance as SHA-256.

Length extension attacks is probably one of the things that should be discussed in the security considerations. SHA-256 should not be recommended for application where length extension attacks are a problem.

OLD: "SHAKE-128", "SHAKE-256"
NEW: "SHAKE128" "SHAKE256"

OLD: "The SHA-3 hash algorithms have a significantly different structure than the SHA-3 hash algorithms"
NEW: "The SHA-3 hash algorithms have a significantly different structure than the SHA-2 hash algorithms"

- The need to define new algorithms for each truncation is a bit limiting. For the specific use case in X.509, I do not see any need.

COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ]

The length is already encoded in hashValue, SHA-256/64 = TBD1 just encodes the same information also in hashAlg. At least in this use case, an attacker that can truncate hashValue can also change hashAlg. 

In other cases (like Group OSCORE and EDHOC) there is a need to uniquely identify and algorithm and all its parameters, but is that case it could be more flexible to define a parameterised algorithm as

paraAlg = [alg: int / tsrt, parameters: * any]

and define

SHA-256/64  as [TBD2, 64] or [TBD2, 8]
SHA-512/256 as [TBD4, 256] or [TBD4, 32]

Nits:

"wsa"