Subject: Re: [hiprg] Gen-ART review for draft-irtf-hiprg-dht-04

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Fri, 21 Oct 2011 08:10:01 -0700

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: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 20, 2011 7:11 AM
> To: [email-masked]; Ahrenholz, Jeffrey M
> Cc: [email-masked]; [email-masked]
> 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.