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

Miika Komu <mkomu@cs.hut.fi> Sat, 22 October 2011 07:18 UTC

Return-Path: <mkomu@cs.hut.fi>
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 8E2AE11E80B7 for <hiprg@ietfa.amsl.com>; Sat, 22 Oct 2011 00:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 snEB+UrOM32D for <hiprg@ietfa.amsl.com>; Sat, 22 Oct 2011 00:18:33 -0700 (PDT)
Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id C48F411E80A2 for <hiprg@irtf.org>; Sat, 22 Oct 2011 00:18:32 -0700 (PDT)
Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1RHVqg-0002RK-8d for hiprg@irtf.org; Sat, 22 Oct 2011 10:18:30 +0300
Message-ID: <4EA26E28.7020808@cs.hut.fi>
Date: Sat, 22 Oct 2011 10:18:00 +0300
From: Miika Komu <mkomu@cs.hut.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: hiprg@irtf.org
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> <727A9046-EED3-46C8-BC48-E127BEE5BA41@cs.rwth-aachen.de>
In-Reply-To: <727A9046-EED3-46C8-BC48-E127BEE5BA41@cs.rwth-aachen.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Sat, 22 Oct 2011 07:18:33 -0000

Hi,

On 21/10/11 19:04, Tobias Heer wrote:
>>> 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.

+1 (needs to be documented well in Security Considerations as mentioned 
by Lloyd Wood)