Gen-ART review for draft-irtf-hiprg-dht-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-irtf-hiprg-dht-04
Reviewer: Kathleen Moriarty
Review Date: October 20, 2011
IETF LC End Date: 11/1/11
IESG Telechat date: (if known)

Summary: This draft requires further review.  There are just a few grammar nits listed below, but the use of SHA-1 should be updated or noted as a concern.

This is an experimental draft, building off of other experimental RFCs.  The IESG outlined a number of concerns at the start of RFC5201, at least one of which is also present in this document.  SHA-1 is no longer a preferred algorithm and there is no algorithm agility in the specification (it appears to be a field size limitation from previous RFCs, but there is no explanation).  This is not listed in the security considerations either.  If the IESG is still okay with experimental documents proceeding with SHA-1 specified, this should be discussed in the security considerations section at a minimum. It seems that the service described could use another hash algorithm since the exchanges are fully defined in this document.

If the algorithm cannot be updated, the description of the design in the abstract should be updated as HIP is not designed with the security features described in the following sentences.
"The protocol is
   designed to be resistant to denial-of-service (DoS) and man-in-the-
   middle (MitM) attacks.  When used together with another suitable
   security protocol, such as the Encapsulated Security Payload (ESP),
   it provides integrity protection and optional encryption for upper-
   layer protocols, such as TCP and UDP."

This could be a result of RFC5201 having a MUST statement for the use of SHA-1.  The earlier document, RFC4423 specifies a hash is to be used and at the time it was written, SHA-1 was the NIST recommendation (2003).

Major issues:

Minor issues:

Nits/editorial comments:
Abstract: Change: This document specifies a common interface for using HIP with a
To: "This document specifies a common interface for using Host Identity Protocol (HIP) with a"
The Introduction uses the spelled out acronym without putting (HIP) after it if you want to define it here as well.

Introduction: 3rd sentence, add a comma:
Change from: "These keys are hashed and prefixed
   to form Host Identity Tags (HITs) which appear as large random
   numbers."
To: "These keys are hashed and prefixed
   to form Host Identity Tags (HITs), which appear as large random
   numbers."

Section 2: Is there a reason why the hash value is limited to using SHA-1?  This should be a choice for algorithm agility if possible.

Section3, paragraph 6: Consider breaking this into two sentences:
"The host SHOULD
   retain the last Update ID value it used for each HIT across reboots,
   or perform a self lookup in the DHT, since that number may be
   retained in the DHT records and will determine the preferred address
   used by peers."

Section 4, paragraph 4: Consider changing the following sentence (joining two thoughts not three) and 'address publish' does not read quite right:
From: "The ttl_sec field used with address publish includes the time-to-
   live, the number of seconds for which the entry will be stored by the
   DHT, which SHOULD be set to the number of seconds remaining in the
   address lifetime."
To: "The ttl_sec field used with the address publish command includes the time-to-
   Live and the number of seconds for which the entry will be stored by the
   DHT, which SHOULD be set to the number of seconds remaining in the
   address lifetime."

Section 7: Security Considerations
If there is some reason why you can't use anything stronger than SHA-1 for a hash, this should also be listed as a security consideration.  I don't think the IETF is putting through documents that use SHA-1 anymore as standards track.


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]