[hiprg] use of sha-1 in the DHT interface draft

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Thu, 20 October 2011 23:58 UTC

Return-Path: <thomas.r.henderson@boeing.com>
X-Original-To: hiprg@ietfa.amsl.com
Delivered-To: hiprg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DED3D21F8ACA for <hiprg@ietfa.amsl.com>; Thu, 20 Oct 2011 16:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OkmwpHq2c1h7 for <hiprg@ietfa.amsl.com>; Thu, 20 Oct 2011 16:58:10 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3284121F88AB for <hiprg@irtf.org>; Thu, 20 Oct 2011 16:58:10 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com []) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p9KNw0SC013081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <hiprg@irtf.org>; Thu, 20 Oct 2011 16:58:07 -0700 (PDT)
Received: from slb-av-01.boeing.com (localhost []) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p9KNvxQw018346 for <hiprg@irtf.org>; Thu, 20 Oct 2011 16:58:00 -0700 (PDT)
Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com []) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p9KNvxTi018341 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <hiprg@irtf.org>; Thu, 20 Oct 2011 16:57:59 -0700 (PDT)
Received: from XCH-NW-10V.nw.nos.boeing.com ([]) by XCH-NWHT-05.nw.nos.boeing.com ([]) with mapi; Thu, 20 Oct 2011 16:57:59 -0700
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: "hiprg@irtf.org" <hiprg@irtf.org>
Date: Thu, 20 Oct 2011 16:57:58 -0700
Thread-Topic: use of sha-1 in the DHT interface draft
Thread-Index: AcyPMhu12S232/FYTZeFIp5WqSol+QAHb2kgAAxGKRA=
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com>
References: <FD98F9C3CBABA74E89B5D4B5DE0263B9379F111483@XCH-NW-12V.nw.nos.boeing.com>
In-Reply-To: <FD98F9C3CBABA74E89B5D4B5DE0263B9379F111483@XCH-NW-12V.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [hiprg] use of sha-1 in the DHT interface draft
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: Thu, 20 Oct 2011 23:58:11 -0000

We've received a comment during Gen-ART review of draft-irtf-hiprg-dht-04 that merits list discussion.  The comment, from Kathleen Moriarty, is below:

> 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.

The usage of SHA-1 is as follows.

1) OpenDHT uses a SHA-1 hash in the "put" method as follows:
secret_hash: SHA-1 hash of a secret that can be used to remove the put later (optional)

Please see http://www.opendht.org/users-guide.html for more details.

However, my understanding is that the DHT server does not enforce the use of SHA-1; modified clients (that are HIP-aware) could use SHA-256 truncated to 160 bits.

2) SHA-1 is used to generate a 160-bit name (Section 4.1); any hashing function would do here so long as the result fits into 160-bits.  We are not relying on the security properties here.

So, it seems like there are a few choices to proceed:

- keep the draft as is, citing that OpenDHT interface prescribes SHA-1, and that the other usage of SHA-1 is not trying to obtain any crypto properties.  However, the implication of this is we will need to add more text in the security section and elsewhere to defuse this "red flag"

- keep the OpenDHT interface aspect at SHA-1 (to avoid changing the existing interface in this regard) but make the other name hash into SHA-256 (truncated) to avoid controversy on that point.

- change both to SHA-256.  Since we are already talking about clients modified to support HIP, and it doesn't impact servers, this would just be one more small change to clients.

Any opinions on this?  

There were a number of other comments that can be resolved in a draft update that Jeff will post shortly.

- Tom