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

Tobias Heer <heer@cs.rwth-aachen.de> Fri, 21 October 2011 16:04 UTC

Return-Path: <heer@informatik.rwth-aachen.de>
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 D848D1F0C84 for <hiprg@ietfa.amsl.com>; Fri, 21 Oct 2011 09:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level:
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
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 a-Ch-SnON6hw for <hiprg@ietfa.amsl.com>; Fri, 21 Oct 2011 09:04:58 -0700 (PDT)
Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id E7B511F0C76 for <hiprg@irtf.org>; Fri, 21 Oct 2011 09:04:57 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LTF001N1BC24IK0@mta-2.ms.rz.RWTH-Aachen.de> for hiprg@irtf.org; Fri, 21 Oct 2011 18:04:50 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.69,386,1315173600"; d="scan'208";a="66968420"
Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Fri, 21 Oct 2011 18:04:51 +0200
Received: from umic-i4-137-226-45-203.nn.rwth-aachen.de ([unknown] [137.226.45.203]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LTF00D89BC2JR70@relay-auth-2.ms.rz.rwth-aachen.de> for hiprg@irtf.org; Fri, 21 Oct 2011 18:04:50 +0200 (CEST)
From: Tobias Heer <heer@cs.rwth-aachen.de>
In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CF18DF86B@XCH-NW-10V.nw.nos.boeing.com>
Date: Fri, 21 Oct 2011 18:04:51 +0200
Message-id: <727A9046-EED3-46C8-BC48-E127BEE5BA41@cs.rwth-aachen.de>
References: <FD98F9C3CBABA74E89B5D4B5DE0263B9379F111483@XCH-NW-12V.nw.nos.boeing.com> <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> <FD98F9C3CBABA74E89B5D4B5DE0263B9379F1116CA@XCH-NW-12V.nw.nos.boeing.com> <7CC566635CFE364D87DC5803D4712A6C4CF18DF86B@XCH-NW-10V.nw.nos.boeing.com>
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
X-Mailer: Apple Mail (2.1084)
Cc: "hiprg@irtf.org" <hiprg@irtf.org>
Subject: Re: [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: Fri, 21 Oct 2011 16:04:58 -0000

Am 21.10.2011 um 17:33 schrieb Henderson, Thomas R:

> 
> 
>> -----Original Message-----
>> From: Ahrenholz, Jeffrey M
>> Sent: Friday, October 21, 2011 8:00 AM
>> To: Henderson, Thomas R; hiprg@irtf.org
>> Subject: RE: use of sha-1 in the DHT interface draft
>> 
>>> 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.
>> 
>> The DHT server does use SHA-1 internally to process removes. If the
>> client uses another hash function, the secret given in the DHT remove
>> will not match the SHA-1 hash used in the put.
> 
> I did not catch that detail since it is not very clear from the API document, but it makes more sense that it operates that way.
> 
>> 
>> The draft does not currently require a modified OpenDHT/Bamboo server.
>> It states in sections 3 and 7 that the server MAY/SHOULD be modified
>> for signature and host ID verification (it looks like the "MAY" in
>> section 3 should be changed to "SHOULD".)  Use of another hash
>> algorithm would require further server modifications (and specifying an
>> interface that deviates from OpenDHT.)
>> 
>>> - 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"
>> 
>> I would prefer the above option. The security considerations section
>> can include text about deviating from the OpenDHT interface in order to
>> support other hash functions. The original intent of the draft was to
>> re-use the freely-available OpenDHT interface in an interoperable
>> fashion.
>> 
> 
> In light of the above, I would lean towards your recommendation as well.  
> 
+1
Same here. If compatibility is an issue, it outweighs the other reasons. Having an API that is incompatible to the system makes little sense.

Tobias

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://www.comsys.rwth-aachen.de/team/tobias-heer/
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi
pgp id: AEECA5BF