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

<L.Wood@surrey.ac.uk> Fri, 21 October 2011 16:24 UTC

Return-Path: <L.Wood@surrey.ac.uk>
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 E173A1F0C81 for <hiprg@ietfa.amsl.com>; Fri, 21 Oct 2011 09:24:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
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 Brsy74icIb9r for <hiprg@ietfa.amsl.com>; Fri, 21 Oct 2011 09:24:54 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8A61F0C8B for <hiprg@irtf.org>; Fri, 21 Oct 2011 09:24:54 -0700 (PDT)
Received: from [195.245.230.131:26525] by server-1.bemta-3.messagelabs.com id 1D/E5-26599-4DC91AE4; Fri, 21 Oct 2011 16:24:52 +0000
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-2.tower-78.messagelabs.com!1319214291!89762735!1
X-Originating-IP: [131.227.200.39]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11520 invoked from network); 21 Oct 2011 16:24:52 -0000
Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-2.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 21 Oct 2011 16:24:52 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.171]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Fri, 21 Oct 2011 17:24:51 +0100
From: <L.Wood@surrey.ac.uk>
To: <mkomu@cs.hut.fi>, <hiprg@irtf.org>
Date: Fri, 21 Oct 2011 17:22:23 +0100
Thread-Topic: [hiprg] use of sha-1 in the DHT interface draft
Thread-Index: AcyPuOLfR3PJdI5WQiOZoNNMOWcD8AAT36Jw
Message-ID: <FD7B10366AE3794AB1EC5DE97A93A373333E113238@EXMB01CMS.surrey.ac.uk>
References: <FD98F9C3CBABA74E89B5D4B5DE0263B9379F111483@XCH-NW-12V.nw.nos.boeing.com> <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> <4EA10DFB.2070001@cs.hut.fi>
In-Reply-To: <4EA10DFB.2070001@cs.hut.fi>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: wes@mti-systems.com
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:24:57 -0000

I have a broader comment on this, having been here before.

I ran into a similar problem when using MD5 in a protocol
in a non-security context for purely error-checking purposes,
and endured much criticism from self-professed security types
for even considering or mentioning MD5 at all.

That experience from 2007 onward eventually fed into some
carefully-worded text in:
RFC 6151   Updated Security Considerations for
           the MD5 Message-Digest and the HMAC-MD5 Algorithms
           March 2011

but we're still specifying MD5 use as an optional checksum,
because it's lightweight and useful for rejecting errors in
file transfers and supporting the end-to-end principle.

For SHA-1, the equivalent document is:
RFC 6194   Security Considerations for
           the SHA-0 and SHA-1 Message-Digest Algorithms
           March 2011

my thoughts are:

- text explaining use of SHA-1 in a none-security context
  will need to mention RFC 6194, or kick off an update to
  RFC 6194.
- since any crypto/hash algorithm is going to be subject to
  attacks, flexibility in handling a variety of algorithm
  options is key, as soon SHA-256 will Just Not Be Good
  Enough. If you want wide deployment, you don't want
  a full protocol redesign every couple of years...
- a fixed-length field is indeed a bit of a design problem.
- mentioning MD5 or SHA-1 should not immediately be a red
  flag; context is important.
- SHA-1 is the new MD5.
- SHA-256 will be the new SHA-1, which is to say
  the new new MD5.
- Since it's 160 bits, hey, you could specify MD5 too!
  At this point, probably as useful.
- Security is fashion. Red is the new black.

Lloyd Wood
http://saratoga.sf.net/

> -----Original Message-----
> From: hiprg-bounces@irtf.org [mailto:hiprg-bounces@irtf.org] 
> On Behalf Of Miika Komu
> Sent: 21 October 2011 07:15
> To: hiprg@irtf.org
> Subject: Re: [hiprg] use of sha-1 in the DHT interface draft
> 
> 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.
> _______________________________________________
> hiprg mailing list
> hiprg@irtf.org
> https://www.irtf.org/mailman/listinfo/hiprg
>