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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf