Subject: [CGA-EXT] comments on draft-ietf-csi-hash-threat-03

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 21 Sep 2009 09:39:46 +0200

Hi,

I have reviewed this document and i have some comments:

Substantial:
=============

Issue #1
---------

In section 3.3. Attacks against the Digital Signature in the SEND 
Universal Signature option

I don't think the document should make an analysis of the SEND universal 
signature option yet to be defined and for whicht he WG has no consensus 
yet.
I think the hash analysis required is to be performed about the current 
rfc3971 spec.
So I suggest to remove all the text referring to the PK-agility and 
leave only the text about the signature option as defined in rfc3971

Issue #2
--------

Then in section 3.3. it reads:

The possible attack on such explicit digital signature is a
   typical non-repudiation attack, i.e. the Digital Signature field is
   vulnerable to the collision attack.  An attacker produces two
   different messages, m and m', where hash(m) = hash(m').  He underlays
   one of the messages to be signed with the key authorized through
   CGAs, but uses another message afterwards.  However, as denoted in
   [rfc4270], the structure of at least one of two messages in a
   collision attack is strictly predefined.  The previous requirement
   complicates the collision attack, but we have to take into account
   that a variant of SHA-1 was already affected by recent collision
   attacks and we have to prepare for future improved attacks.

I fail to understnad what is the impact of this attack. I mean, it means 
that the attacker could manage to make a host to sign one message and 
then present another one. I understnad that. How this applies in the 
cntext of SeND? could you make an more clear example of what can be done 
in the actual send protocol?

Issue #3
--------

In section 3.4. Attacks against the Key Hash in the SEND Universal 
Signature option it covers the analysis for the SeND universal signature 
option.
Similarly, remove that part and only cover the fields defined in rfc3971

Issue #4
--------

In section 4.1. The negotiation approach for the SEND hash agility
it reads:

   None of the previous solutions supports the negotiation of the hash
   function.  Therefore we propose the negotiation approach for the SEND

I don't think this document proposes anything. I think this should be 
rephrased as another possible option in order to support hash agility 
(like the others that have been described earlier in the section)

Issue #5
--------

In section 3, the attacks against the one property are described in 
detail but the one against the collision property is not. Sionce the 
last one is the one we care the most, i would suggest some text is added 
describing it with the same level of detail.

regards, marcelo

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 22 Sep 2009 15:12:08 +0800

Hi, Marcelo,

Thanks  so much for your comments. They are reasonable for me. They will be
reflected in the next version that we are working on now. Ana has the token
of editing now. She will modified this draft accordingly, then submit a new
update version soon.

Best regards,

Sheng

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Monday, September 21, 2009 3:40 PM
> To: Ana Kukec; Suresh Krishnan; JiangSheng 66104; [email-masked]
> Subject: comments on draft-ietf-csi-hash-threat-03
> 
> Hi,
> 
> In section 3.3. Attacks against the Digital Signature in the 
> SEND Universal Signature option
> 
> I don't think the document should make an analysis of the 
> SEND universal signature option yet to be defined and for 
> whicht he WG has no consensus yet.
> So I suggest to remove all the text referring to the 
> PK-agility and leave only the text about the signature option 
> as defined in rfc3971
> 
> Issue #2
> --------
> 
> I fail to understnad what is the impact of this attack. I 
> mean, it means that the attacker could manage to make a host 
> to sign one message and then present another one. I 
> understnad that. How this applies in the cntext of SeND? 
> could you make an more clear example of what can be done in 
> the actual send protocol?
> 
> Issue #3
> --------
> 
> In section 3.4. Attacks against the Key Hash in the SEND 
> Universal Signature option it covers the analysis for the 
> SeND universal signature option.
> In section 4.1. The negotiation approach for the SEND hash 
> agility it reads:
> 
> I don't think this document proposes anything. I think this 
> should be rephrased as another possible option in order to 
> support hash agility (like the others that have been 
> described earlier in the section)
> 
> Issue #5
> --------
> 
> In section 3, the attacks against the one property are 
> described in detail but the one against the collision 
> property is not. Sionce the last one is the one we care the 
> most, i would suggest some text is added describing it with 
> the same level of detail.
> 
> regards, marcelo
> 
> 
> 
>