Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-csi-hash-threat-10

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 23 Sep 2010 11:30:25 -0400

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 29 Sep 2010 01:18:26 -0400

Hi Pete,
   Thanks for the comments. Please find responses inline.

> of the signature?  How does it run OCSP before it gets Internet

The sec-dir reviews pointed out that this discussion is already covered 
in the normative references and should not be repeated here. That is why 
we removed it.

As far as forged certificates go, the client will use CRLs to verify the 
certificate. As specified in section 6.3.1. of SEND (RFC3971) the client 
will accept the certificate provisionally since it does not have any 
internet connectivity. Once internet connectivity is established, the 
client will perform the CRL check. If the CRL check fails or if the 
router interferes with the CRL check the client will stop using the 
router as a default router as specified in RFC3971.

> choosing the message contents to carry out the collision attack?

Yes. Not only is the structure of the messages fixed. A lot of the 
contents inside the ND message fields only have a small range of valid 
values.

>    provide non-repudiation features anyway.

I will fix all of these typos in a new revision.

Thanks
Suresh