Subject: [COSE] Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Mon, 01 Jun 2020 21:33:15 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-cose-hash-algs-04: Yes

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

— Abstract —

   There are however circumstances where
   hash algorithms are used, such as indirect signatures where the hash
   of one or more contents are signed, and X.509 certificate or other
   object identification by the use of a fingerprint.

I found this hard to parse, and had to read it a few times.  How about this?:

NEW
   There are, however, circumstances where
   hash algorithms are used, such as in indirect signatures, where the hash
   of some content is signed, and for fingerprinting of X.509 certificates or
   other objects.
END

— Introduction —

   This omission was intentional as a structure consisting of
   just a digest identifier, the content, and a digest value does not by
   itself provide any strong security service.

Nit: this needs a few more commas... one after “intentional”, and one before
and one after “by itself”.

   One of the primary things that has been identified by a hash
   function for secure message is a certificate.

Another that I had trouble parsing.  Maybe, “One of the primary things related
to secure messages that has been identified by a hash function is a
certificate.”

— Section 2 —

   hash functions is part of the base design as cryptographic advances
   are sure to reduce the strength of a hash function.

Nit: this needs a comma after “design”.

   The standard "Collision Attack" is one where an attacker can
   find two different messages that have the same hash value.  If a
   collision attack exists, then the function SHOULD NOT be used for a
   cryptographic purpose.

I’m uncomfortable with having this document give a brief tutorial on
cryptographic hashing, as it has to be oversimplified... and it is.  If it’s
going to stay, I’d like to see ar least one minor change, though I’ll defer to
the Sec ADs on this point: for any hash alg, it is always possible to encounter
a collision, and the text isn’t clear about what “if a collision attack exists”
really means.  I think it means not to use it if a collision attack is
practical, and maybe this is a better way to say it?:

NEW
   A "collision attack" is one where an attacker can
   find two different messages that have the same hash value.  A
   hash function that is susceptible to collision attacks, SHOULD
   NOT be used for cryptographic purposes.
END

   checked to see if they are the correct one.

“They are the correct one?”  Oof.  How about, “to find the correct one,” or
(maybe better), “to see if they are suitable.”?

   If the fingerprint is
   used to verify that it is the correct certificate, then that usage is
   subject to a collision attack as above.  If however, the fingerprint
   is used to sort through a collection of certificates

“then that usage is a cryptographic one and is subject to the warning above
about collision attacks.”  And “however” also needs a comma before it, as well
as after.

   In this case, one still needs to
   validate that the public key validates the signature

Make the first “validate” say “confirm” instead, to avoid the awkward double
use of “validate”.

   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.

Might it be better to have the new column be called “cryptographic use”, with
values of “yes” and “no”?  Hint: I think it would.  Hint#2: this is a
non-blocking comment, so you might disagree.

— Section 2.1 —

   *  Additional data, this can be something as simple as a random value

Nit: make the comma a semicolon.

      appending to the content, but it is strongly suggested to it

Nit: change “to it” to “that it”.

— Section 3.1 —

   Because of the known issues for SHA-1 and the fact that is should no

Nit: change “that is” to “that it”.

— Section 3.2 —

      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.

Locations?  And do you mean to use “analysis” as a verb?  Maybe this?:

NEW
      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.
END

— Section 3.3 —

   One of the benefits of this
   differences is that when computing a shorter SHAKE hash value

Nit: “difference”, singular.

— Section 5 —

   that need the cryptographic properties, i.e. collision resistance,
   and properties that correspond to possible object identification.

Collision resistance isn’t the only cryptographic property (there’s also, for
example, preimage resistance), so change “i.e.” to “such as”.  This is another
example of the hazard of trying to explain hashing in a simple document such as
this one.

   This is
   the difference between collision resistance and second pre-image
   resistance.

If you have collision resistance, don’t you automatically have second preimage
resistance?  What’s he point of mentioning second preimage resistance here,
when you don’t mention it nor need it anywhere else?

   are under constant attack and the strength of hash algorithms will be
   reduced over time.

I would say “the cryptographic strength”.

---

From: Jim Schaad <[email-masked]>
Date: Tue, 2 Jun 2020 12:16:48 -0700

-----Original Message-----
From: Barry Leiba via Datatracker <[email-masked]> 
Sent: Monday, June 1, 2020 9:33 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Ivaylo Petrov <[email-masked]>; [email-masked]
Subject: Barry Leiba's Yes 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.)

— Abstract —

NEW

[JLS] I have a bit of a problem with this.  If you look at things correctly then almost all of the current signature algorithms would fit this, but it does not match what I am trying to say.  ECDSA hashes a content and then computes the signature math on that hash value.  This is not what we want to call an indirect signature even though it could be considered to be one.  This is as oppose to Pure EdDSA where the entire content (with modifications) is hashed internally to the signature code.  How about

"where the content to be signed contains the hash of one or more external object,"

— Introduction —

Nit: this needs a few more commas... one after “intentional”, and one before and one after “by itself”.
[JLS] Done

Another that I had trouble parsing.  Maybe, “One of the primary things related to secure messages that has been identified by a hash function is a certificate.”

[JLS] How about "Many applications use the hash of a certificate to replace the certificate itself, this allows for uniquely identifying the certificate while using fewer bytes."

— Section 2 —

[JLS] Done

I’m uncomfortable with having this document give a brief tutorial on cryptographic hashing, as it has to be oversimplified... and it is.  If it’s going to stay, I’d like to see ar least one minor change, though I’ll defer to the Sec ADs on this point: for any hash alg, it is always possible to encounter a collision, and the text isn’t clear about what “if a collision attack exists”
really means.  I think it means not to use it if a collision attack is practical, and maybe this is a better way to say it?:

NEW

[JLS] Done.  Given how fast we are at getting hash algorithms changed, I don't know that the trigger I would use is that the attack is practical.  Just the ability to find a collision at all is the trigger that we need to start changing the hash algorithms we are using.  People have talked about SHA-1 collisions for the last twenty years, but only in the last two have they become practical.  Should we be suggesting the SHOULD earlier than 2017?

“They are the correct one?”  Oof.  How about, “to find the correct one,” or (maybe better), “to see if they are suitable.”?
[JLS] How about "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."

   If the fingerprint is

“then that usage is a cryptographic one and is subject to the warning above about collision attacks.”  And “however” also needs a comma before it, as well as after.
[JLS] Done

Make the first “validate” say “confirm” instead, to avoid the awkward double use of “validate”.
[JLS] Done

Might it be better to have the new column be called “cryptographic use”, with values of “yes” and “no”?  Hint: I think it would.  Hint#2: this is a non-blocking comment, so you might disagree.
[JLS] I did think about this, the issue is that I do not know what the correct value would be to place in that column for "AES-GCM-128".  The table has things which are not hash algorithms.

— Section 2.1 —

[JLS] Done

[JLS] Done

— Section 3.1 —

[JLS] Done

— Section 3.2 —

NEW
[JLS] Cleaner - done

— Section 3.3 —

[JLS] Done

— Section 5 —

Collision resistance isn’t the only cryptographic property (there’s also, for example, preimage resistance), so change “i.e.” to “such as”.  This is another example of the hazard of trying to explain hashing in a simple document such as this one.
[JLS] Done

   This is

If you have collision resistance, don’t you automatically have second preimage resistance?  What’s he point of mentioning second preimage resistance here, when you don’t mention it nor need it anywhere else?

[JLS] Looking at this, the two sentences do not really follow from what preceded it so I deleted the two sentences.  Yes a second preimage attack would imply a collision attack.  But looking at what Warren is having problems with, there is a difference between the originator of the message providing two different external objects which have the same hash value and an attacker trying to find a second external object that has the same hash value in order to get the bad firmware installed.

[JLS] Done.

Jim

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Jun 2020 16:10:48 -0400

Thanks for the response, Jim, and your counter-suggestions all look good.
I appreciate your considering my comments.

On this:
> Might it be better to have the new column be called “cryptographic use”,
> with values of “yes” and “no”?  Hint: I think it would.  Hint#2: this is a

[JLS] I did think about this, the issue is that I do not know what the
correct value would be to place in that column for "AES-GCM-128".  The
table has things which are not hash algorithms.

You couldn’t say “yes” to “cryptographic use” for AES-GCM-128?  Why would
“Recommend” “yes” be better?  I kind of feel (though not that strongly, so
I’ll let this be my last comment on it unless you want to continue to chat
about it) that “Recommend” is an odd column heading.  The name raises a
question for me about why the entry would be there if it’s not Recommended.

b

---

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

Hi Jim!

> From: iesg <[email-masked]> On Behalf Of Jim Schaad
> Sent: Tuesday, June 2, 2020 3:17 PM
> To: 'Barry Leiba' <[email-masked]>; 'The IESG' <[email-masked]>
> Cc: 'Ivaylo Petrov' <[email-masked]>; [email-masked]; draft-ietf-cose-hash-
> [email-masked]; [email-masked]
> Subject: RE: Barry Leiba's Yes 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.)
> 
> 

[snip]

> cryptographic hashing, as it has to be oversimplified... and it is.  If it’s going to
> stay, I’d like to see ar least one minor change, though I’ll defer to the Sec ADs
> on this point: for any hash alg, it is always possible to encounter a collision, and
> the text isn’t clear about what “if a collision attack exists”
> [JLS] Done.  Given how fast we are at getting hash algorithms changed, I don't
> know that the trigger I would use is that the attack is practical.  Just the ability
> to find a collision at all is the trigger that we need to start changing the hash
> algorithms we are using.  People have talked about SHA-1 collisions for the last
> twenty years, but only in the last two have they become practical.  Should we
> be suggesting the SHOULD earlier than 2017?

Perhaps we simply state the guiding design principal.  Say:

A "collision attack" is one where an attacker can find two different messages that have the same hash value.  A hash function that is susceptible to practical collision attacks SHOULD NOT be used for cryptographic purposes.  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.

Regards,
Roman

---

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

-----Original Message-----
From: Roman Danyliw <[email-masked]> 
Sent: Monday, June 8, 2020 8:13 PM
To: Jim Schaad <[email-masked]>; 'Barry Leiba' <[email-masked]>; 'The IESG' <[email-masked]>
Cc: 'Ivaylo Petrov' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with COMMENT)

Hi Jim!

> Cc: 'Ivaylo Petrov' <[email-masked]>; [email-masked]; 
> draft-ietf-cose-hash- [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Ivaylo Petrov <[email-masked]>; [email-masked]
> 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

[snip]

> cryptographic hashing, as it has to be oversimplified... and it is.  
> If it’s going to stay, I’d like to see ar least one minor change, 
> though I’ll defer to the Sec ADs on this point: for any hash alg, it 
> is always possible to encounter a collision, and the text isn’t clear about what “if a collision attack exists”
> [JLS] Done.  Given how fast we are at getting hash algorithms changed, 
> I don't know that the trigger I would use is that the attack is 
> practical.  Just the ability to find a collision at all is the trigger 
> that we need to start changing the hash algorithms we are using.  
> People have talked about SHA-1 collisions for the last twenty years, 
> but only in the last two have they become practical.  Should we be suggesting the SHOULD earlier than 2017?

[JLS] That makes sense.

Regards,
Roman