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

["Henderson, Thomas R" <[e-mail]>]

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