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