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

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 20 Oct 2011 16:57:58 -0700

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.

- Tom

---

From: Miika Komu <[email-masked]>
Date: Fri, 21 Oct 2011 09:15:23 +0300

Hi,

> 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.

---

From: Tobias Heer <[email-masked]>
Date: Fri, 21 Oct 2011 13:59:45 +0200

Hello,

> 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:
[...]
> - 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.
I would prefer this option. It does not seem to break the interface and legacy compatibility does not seem an issue. However, I am not sure about the practical security benefits of truncated SHA-256 compared to SHA-1.

Best regards,

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

---

From: Samu Varjonen <[email-masked]>
Date: Fri, 21 Oct 2011 16:34:03 +0300

> I would prefer this option. It does not seem to break the interface and legacy compatibility does not seem an issue. However, I am not sure about the practical security benefits of truncated SHA-25…

+1

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Fri, 21 Oct 2011 07:59:57 -0700

> 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.

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.

-Jeff

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 21 Oct 2011 08:33:26 -0700

> -----Original Message-----
> From: Ahrenholz, Jeffrey M
> Sent: Friday, October 21, 2011 8:00 AM
> To: Henderson, Thomas R; [email-masked]
> Subject: RE: use of sha-1 in the DHT interface draft
> 
> 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.)
> 
> 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.  

- Tom

---

From: Tobias Heer <[email-masked]>
Date: Fri, 21 Oct 2011 18:04:51 +0200

> 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

---

From: <[email-masked]>
Date: Fri, 21 Oct 2011 17:22:23 +0100

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/

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Miika Komu
> Sent: 21 October 2011 07:15
> To: [email-masked]
> Subject: Re: [hiprg] use of sha-1 in the DHT interface draft
> 
> Hi,
> 
> > 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:
> >
> >> 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.
> >
> > secret_hash: SHA-1 hash of a secret that can be used to 
> remove the put 
> > later (optional)
> >
> > 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.
> >
> > - 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.
> 
> _______________________________________________
> hiprg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hiprg
>

---

From: Miika Komu <[email-masked]>
Date: Sat, 22 Oct 2011 10:18:00 +0300

Hi,

> 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)