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

From: <[email-masked]>
Date: Thu, 20 Oct 2011 10:11:06 -0400

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.

---

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
> 
> 
> 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
> 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:
> The Introduction uses the spelled out acronym without putting (HIP)
> after it if you want to define it here as well.

Fixed.

>    to form Host Identity Tags (HITs), which appear as large random

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.

>    retained in the DHT records and will determine the preferred address

Fixed.

> Section 4, paragraph 4: Consider changing the following sentence
> (joining two thoughts not three) and 'address publish' does not read
> quite right:

Fixed. Also reworded "address publish."
 
> 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.