[Gen-art] Gen-ART Telechat Review of draft-ietf-csi-hash-threat-09

["McCann Peter-A001034" <[e-mail]>]

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-csi-hash-threat-09
Reviewer: Pete McCann
Review Date: 09 March 2010
IESG Telechat date: 11 March 2010

Summary:  A couple of minor issues, 
          and numerous editorial fixes are needed before publication.

Major issues:  None.

Minor issues:

Introduction:
   There is a great variaty of hash functions, but only MD5 and SHA-1
   are in the wide use, which is also the case for SEND
This sentence makes a statement about MD5 and SHA-1 being the only
widely
used hash functions, but I can't figure out what it is saying about
SEND.
Is it saying that SEND is widely used?  Or did you mean to say that SEND
implementations typically only implement MD5 and SHA-1?

Section 3:
   Supposing that the hash function
   produces an n-bit long output, since each output is equally likely,
   an attack takes an order of 2^n operations to be successful.
SHOULD SAY: "on the order of".  But this sentence is just plain
incorrect (see below).
  Due to
   the birthday attack, if the hash function is supplied with a random
   input, it returns one of the k equally-likely values, and the number
   of operations can be reduced to the number of 1.2*2^(n/2) operations.
There is no "birthday attack."  And I think you meant 2^n instead of k.
The result you give is due to an equation that is commonly illustrated
with
a problem known as the "birthday paradox."

Nits/editorial comments:

Abstract:
   possible threats
   and the impact of recent
SHOULD BE:
   possible threats,
   and the impact of recent

   Current SEND specification
SHOULD BE:
   The current SEND specification

   support for the hash algorithm agility
SHOULD BE:
   support for hash algorithm agility

   The purpose of the document
SHOULD BE:
   The purpose of this document

   encode the hash agility
SHOULD BE:
   encode hash agility

Introduction:
   Key Hash field and
SHOULD BE:
   Key Hash field, and

   variaty
SHOULD BE:
   variety

   in the wide use
SHOULD BE:
   in wide use

   which has been well known for its weaknesses.
SHOULD BE:
   which has well known weaknesses.

   First
   hash attacks affected the compression function of MD5
SHOULD BE:
   Early
   hash attacks affected the compression function of MD5

   significantlly
SHOULD BE:
   a significantly

   on the way how
SHOULD BE:
   on the way in which

   underlaying
SHOULD BE:
   underlying
(repeated twice)

   way of use
SHOULD BE:
   use

   keep the protocol
   immune,
SHOULD BE:
   keep the protocol
   secure,

   matter of the hash
SHOULD BE:
   matter the hash

   with shared secrets, fingerprints,
SHOULD BE:
   with shared secrets, and fingerprints,

   The rest of the
   section
SHOULD BE:
   The rest of this
   section

   on SEND by the cases of use.
SHOULD BE:
   on SEND by each use case.

   the hash agility
SHOULD BE:
   hash agility

Section 3.1:
   the CGA hash agility
SHOULD BE:
   CGA hash agility

Section 3.2:
   allowe
SHOULD BE:
   allow

   biggest concer are
SHOULD BE:
   the biggest concerns are

   (if the IP prefix range
   used),
SHOULD BE:
   (if the IP prefix range were
   used);

   although, not broader than the prefix range
SHOULD BE:
   although, it could not be broader than the prefix range

   to the
   such human-readble data such 
SHOULD BE:
   to
   such human-readble data

   attack improve
SHOULD BE:
   attack improves

Section 3.3:
   ND message and other fields, e.g. the Message
   Type Tag and ND options,
SHOULD BE:
   ND message, and other fields (e.g. the Message
   Type Tag and ND options),

   field the example of the non-repudiation digital singature,
SHOULD BE:
   field is an example of a digital singature that needs
non-repudiation,

   more then
SHOULD BE:
   more than

   but in real-world situation is to achieve it.
SHOULD BE:
   but in a real-world situation it would be difficult to achieve it.

Section 3.4:
   provides the integrity
SHOULD BE:
   provides integrity

4. Support for the hash agility in SEND
SHOULD BE:
4. Support for hash agility in SEND

   Previous section showed
SHOULD BE:
   The previous section showed

   SEND context prevents those attacks of
   almost any use
SHOULD BE:
   The SEND context prevents these attacks from
   being of almost any use

   for the future
SHOULD BE:
   for future

   suggest the support for the hash and algorithm
   agility in SEND.
SHOULD BE:
   suggest support for hash and algorithm
   agility be added to SEND.

   secure would
SHOULD BE:
   secure method would

   then defining
SHOULD BE:
   than defining

   Possible solution is also the hybrid
SHOULD BE:
   Another possible solution is a hybrid

   One of possible solutions is the negotiation
      approach for the SEND hash agility
SHOULD BE:
   One possible solution is the negotiation
      approach for SEND hash agility

Section 6:
   offeres
SHOULD BE:
   offers

   providing solution for the hash
SHOULD BE:
   providing a solution for hash

   for the hash agility
SHOULD BE:
   for hash agility