Attacks on Cryptographic Hashes in Internet Protocols
draft-hoffman-hash-attacks-04

[Ballot comment]
This review from Lakshminath Dondeti is quite critical but I don't want to block the document. Specifically, I don't think this is the right place to tackle the MD5 issue - that is something we want to do, but independently.

-----------------

Review recommendation:  This draft needs another revision before publication.

First, let me note that both Paul H., and Bruce S., know this stuff much better than I do (and I read Bruce Schneier's cryptogram regularly).

The first part of this draft is very well written and I am happy to see that considering this might be read by folks who are not active in the security area.  However, I find it incomplete in other respects, again considering that same audience.  Furthermore, there is some information that I expected to see there, and would like to run that by for the authors' and the AD's consideration.

1. Generating meaningful MD5 collisions is not all that difficult.  I think this I-D/RFC should be used to drill into the IETF community that we should stop using MD5 as soon as practically possible.  M. Daum and S. Lucks have generated (http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/) two meaningful postscript documents that have the same MD5 hash.  I think their work makes a compelling case to that effect.

Their example also better illustrates the points being made toward the end of Section 4.

2.  In Section 4, I don't quite understand the concept of "automated non-repudiation."  I was wondering whether the intent is to say that "Hash collisions are much more effective on the message authentication property of signatures."  In other words, the party signing might know the intent, but an independent party, with the signing party not present, has no option but to accept the signature and the data that is claimed to be "signed" as long as the hash of the supplied data can be verified with the signature (unless of course the verifying party declares that it won't accept, say, signed MD5 hashes :-)).

3.  Section 5 is somewhat hard to read/parse.

More importantly, I was hoping to see more information on adding random information to hashes before they are signed.

At the risk of being incorrect or saying things the wrong way, and while reassuring everyone that I am not a cryptographer ...

I was told that random information as added -- or more correctly appended -- to a hash as in PSS encoding is not all that useful in the face of collision attacks on the hash function being used.  A more appropriate way would be to prepend the random information or add the random information to every block as Hugo K., et. al., randomized hashing I-D suggests, or intersperse the random information.

I would like to see this I-D generally discuss how the random information might be added to the "hash plus sign" process to be effective.

4. Section 6 might be updated to say that people should stop specifying MD5, and where practical stop using MD5 (HMAC-MD5,  OTOH, Hugo tells us, is ok).

Further, Section 6 might talk about possibly three things we could do:

a) continue to use SHA-1, keeping the reduced strength in mind.
b) for signatures, consider using new randomness encoding methods (e.g., Randomized hashing)
c) start planning to use SHA-256 or other hash functions.

5. (with apologies for going back in text) I was wondering if the last item in the list in Section 3 belongs with the first two items in being affected by collisions.  Isn't that a reference to MD5 values of files made available for sanity checking ftp downloads?  Since no keys are involved in that process, wouldn't an attack similar to that described by Daum and Lucks be possible?  If so, the text immediately following the list should be revised to reflect that.

6. In Security considerations, I would like to see a summary of recommendations, and also caveats in mitigating hash attacks (e.g., summarize how to and how not to add random information before signing).  A summary of the ongoing debate in the Hash BoF list might also be worthwhile, in that, each of the recommendations, e.g., a, b, and c above have some risks associated with them. (there are people who doubt the effectiveness of randomized hashing and others who are not quite sure about SHA-256 -- I think because that hash family hasn't quite received the analysis/attention that SHA-0 and SHA-1 family did).

[Ballot comment]
This review from Lakshminath Dondeti is quite critical but I don't want to block the document. Specifically, I don't think this is the right place to tackle the MD5 issue - that is something we want to do, but independently.

-----------------

Review recommendation:  This draft needs another revision before publication.

First, let me note that both Paul H., and Bruce S., know this stuff much better than I do (and I read Bruce Schneier's cryptogram regularly).

The first part of this draft is very well written and I am happy to see that considering this might be read by folks who are not active in the security area.  However, I find it incomplete in other respects, again considering that same audience.  Furthermore, there is some information that I expected to see there, and would like to run that by for the authors' and the AD's consideration.

1. Generating meaningful MD5 collisions is not all that difficult.  I think this I-D/RFC should be used to drill into the IETF community that we should stop using MD5 as soon as practically possible.  M. Daum and S. Lucks have generated (http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/) two meaningful postscript documents that have the same MD5 hash.  I think their work makes a compelling case to that effect.

Their example also better illustrates the points being made toward the end of Section 4.

2.  In Section 4, I don't quite understand the concept of "automated non-repudiation."  I was wondering whether the intent is to say that "Hash collisions are much more effective on the message authentication property of signatures."  In other words, the party signing might know the intent, but an independent party, with the signing party not present, has no option but to accept the signature and the data that is claimed to be "signed" as long as the hash of the supplied data can be verified with the signature (unless of course the verifying party declares that it won't accept, say, signed MD5 hashes :-)).

3.  Section 5 is somewhat hard to read/parse.

More importantly, I was hoping to see more information on adding random information to hashes before they are signed.

At the risk of being incorrect or saying things the wrong way, and while reassuring everyone that I am not a cryptographer ...

I was told that random information as added -- or more correctly appended -- to a hash as in PSS encoding is not all that useful in the face of collision attacks on the hash function being used.  A more appropriate way would be to prepend the random information or add the random information to every block as Hugo K., et. al., randomized hashing I-D suggests, or intersperse the random information.

I would like to see this I-D generally discuss how the random information might be added to the "hash plus sign" process to be effective.

4. Section 6 might be updated to say that people should stop specifying MD5, and where practical stop using MD5 (HMAC-MD5,  OTOH, Hugo tells us, is ok).

Further, Section 6 might talk about possibly three things we could do:

a) continue to use SHA-1, keeping the reduced strength in mind.
b) for signatures, consider using new randomness encoding methods (e.g., Randomized hashing)
c) start planning to use SHA-256 or other hash functions.

5. (with apologies for going back in text) I was wondering if the last item in the list in Section 3 belongs with the first two items in being affected by collisions.  Isn't that a reference to MD5 values of files made available for sanity checking ftp downloads?  Since no keys are involved in that process, wouldn't an attack similar to that described by Daum and Lucks be possible?  If so, the text immediately following the list should be revised to reflect that.

6. In Security considerations, I would like to see a summary of recommendations, and also caveats in mitigating hash attacks (e.g., summarize how to and how not to add random information before signing).  A summary of the ongoing debate in the Hash BoF list might also be worthwhile, in that, each of the recommendations, e.g., a, b, and c above have some risks associated with them. (there are people who doubt the effectiveness of randomized hashing and others who are not quite sure about SHA-256 -- I think because that hash family hasn't quite received the analysis/attention that SHA-0 and SHA-1 family did).