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

Miika Komu <mkomu@cs.hut.fi> Fri, 21 October 2011 06:15 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 2CF8311E8087 for <hiprg@ietfa.amsl.com>; Thu, 20 Oct 2011 23:15:47 -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 CiD1ZoGCEeeI for <hiprg@ietfa.amsl.com>; Thu, 20 Oct 2011 23:15:46 -0700 (PDT)
Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE7B11E807F for <hiprg@irtf.org>; Thu, 20 Oct 2011 23:15:46 -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 1RH8OO-0002S2-7E for hiprg@irtf.org; Fri, 21 Oct 2011 09:15:44 +0300
Message-ID: <4EA10DFB.2070001@cs.hut.fi>
Date: Fri, 21 Oct 2011 09:15:23 +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>
In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com>
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: Fri, 21 Oct 2011 06:15:48 -0000

Hi,

On 21/10/11 02:57, Henderson, Thomas R wrote:
> 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.

if crypto agility is not an option, I 'd suggest to change both to SHA-256.