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

[<[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Miika Komu
> Sent: 21 October 2011 07:15
> To: [e-mail]
> 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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hiprg
>