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

[marcelo bagnulo braun <marcelo at it.uc3m.es>]

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