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

"Ahrenholz, Jeffrey M" <jeffrey.m.ahrenholz@boeing.com> Fri, 21 October 2011 15:10 UTC

Return-Path: <jeffrey.m.ahrenholz@boeing.com>
X-Original-To: hiprg@ietfa.amsl.com
Delivered-To: hiprg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B191F0C68; Fri, 21 Oct 2011 08:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.2
X-Spam-Level:
X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja8qSaWBrGpB; Fri, 21 Oct 2011 08:10:37 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 924FA1F0C62; Fri, 21 Oct 2011 08:10:37 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p9LF9xPq012936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Oct 2011 10:10:00 -0500 (CDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p9LF9xFK023841; Fri, 21 Oct 2011 08:09:59 -0700 (PDT)
Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p9LF9wdm023828 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 21 Oct 2011 08:09:59 -0700 (PDT)
Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 21 Oct 2011 08:09:58 -0700
From: "Ahrenholz, Jeffrey M" <jeffrey.m.ahrenholz@boeing.com>
To: "kathleen.moriarty@emc.com" <kathleen.moriarty@emc.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "hiprg@irtf.org" <hiprg@irtf.org>
Date: Fri, 21 Oct 2011 08:10:01 -0700
Thread-Topic: Gen-ART review for draft-irtf-hiprg-dht-04
Thread-Index: AcyPMhu12S232/FYTZeFIp5WqSol+QAMOigQ
Message-ID: <FD98F9C3CBABA74E89B5D4B5DE0263B9379F1116D7@XCH-NW-12V.nw.nos.boeing.com>
References: <AE31510960917D478171C79369B660FA0E092F8A8D@MX06A.corp.emc.com>
In-Reply-To: <AE31510960917D478171C79369B660FA0E092F8A8D@MX06A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-irtf-hiprg-dht.all@tools.ietf.org" <draft-irtf-hiprg-dht.all@tools.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [hiprg] Gen-ART review for draft-irtf-hiprg-dht-04
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2011 15:10:38 -0000

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@emc.com [mailto:kathleen.moriarty@emc.com]
> Sent: Thursday, October 20, 2011 7:11 AM
> To: gen-art@ietf.org; Ahrenholz, Jeffrey M
> Cc: ietf@ietf.org; draft-irtf-hiprg-dht.all@tools.ietf.org
> 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.