Thanks for reviewing this DHT draft. Comments are inline below. I plan to post an updated draft once we work out the SHA-1 issues on the hiprg list. -Jeff > -----Original Message----- > From: kathleen.moriarty@xxxxxxx [mailto:kathleen.moriarty@xxxxxxx] > Sent: Thursday, October 20, 2011 7:11 AM > To: gen-art@xxxxxxxx; Ahrenholz, Jeffrey M > Cc: ietf@xxxxxxxx; draft-irtf-hiprg-dht.all@xxxxxxxxxxxxxx > Subject: Gen-ART review for draft-irtf-hiprg-dht-04 > > > 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. SHA-1 is prescribed by the OpenDHT interface that this draft aims to support. > > 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. Fixed. > 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." Fixed. > > 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. Yes, SHA-1 is prescribed by OpenDHT; it was not a choice made for this protocol. This is open for discussion on the hiprg list. > 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." Fixed. > 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." Fixed. Also reworded "address publish." > 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. > SHA-1 is used in two ways: 1) put / remove operation 2) reduce the size of the name string for name lookups Usage #1 is defined by the OpenDHT interface. Usage #2 is not relying on crypto properties of the hash, just reducing the string length to fit in 160 bits. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf