Document: draft-ietf-csi-hash-threat-10 Reviewer: Pete McCann Review Date: 23 September 2010 IETF LC End Date: 27 September 2010 IESG Telechat date: unknown Summary: Not quite ready Major issues: Section 3.2: For this attack to succeed the attacker needs to predict the content of all fields (some of them are human-readable) appearing before the public key including the serial number and validity periods. Even though a relying party cannot verify the content of these fields, the CA can identify the forged certificate, if necessary. This section omits a lot of discussion that was in the previous version of the draft. It seems like a forged certificate, even with falsified serial numbers and validity periods, could still do damage. Detecting the forgery after-the-fact by the CA doesn't really help. Or are you saying that the client should use OCSP to check the current validity of the signature? How does it run OCSP before it gets Internet connectivity? Section 3.3: Since the structure of the Neighbor Discovery messages is well defined, it is not possible to use this vulnerability in real world attacks. Need a little more discussion here justifying this statement. Are you saying that the attacker does not have enough flexibility in choosing the message contents to carry out the collision attack? Minor issues: Nits/editorial comments: Section 1 Introduction: Discovery(ADD) SHOULD BE: Discovery (ADD) The document SHOULD BE: This document Section 3: theaforementioned SHOULD BE: the aforementioned protocols . SHOULD BE: protocols. Section 3.1: Since CGAs do not provide non-repudiation features anyway. SHOULD BE: CGAs do not provide non-repudiation features anyway. Section 3.2: an certificate SHOULD BE: a certificate