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

[Suresh Krishnan <[e-mail]>]

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

On 10-09-23 11:30 AM, McCann Peter-A001034 wrote:
> 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?

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.

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

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.

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

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

Thanks
Suresh