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

[Sheng Jiang <[e-mail]>]

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:[e-mail]] 
> Sent: Monday, September 21, 2009 3:40 PM
> To: Ana Kukec; Suresh Krishnan; JiangSheng 66104; [e-mail]
> Subject: comments on draft-ietf-csi-hash-threat-03
> 
> 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
> 
> 
> 
>