Re: [hiprg] comments on draft-irtf-hiprg-dht-02.txt

["Ahrenholz, Jeffrey M" <[e-mail]>]

> 1) it is stated that secret_hash is an optional SHA-1 hash of 
> secret value.  Does it have to be specified that this is 
> SHA-1; couldn't it be any other hash function?  It seems to 
> me that this value is just opaque to the server so maybe the 
> draft should just state that the secret_hash is recommended 
> to be a pseudo-random value (such as generated by a hash function)

The SHA-1 secret hash is prescribed by OpenDHT; the server does not treat this as opaque; the put operation includes the secret hash and the rm (remove) has the secret value, which must match when hashed.

This page mentions SHA-1 vulnerabilities and alternate hash functions (but OpenDHT is no longer under active development): http://opendht.org/faq.html

> 2) should it be possible (or is it desirable or not) to 
> return error code 3 for the rm operation?  I'm guessing that 
> OpenDHT may not return this and hence you do not include this 
> case, but you talk about modifying DHT servers and it may be 
> advantageous to allow a server to optionally return an error 
> code 3 on a rm operation in case something went wrong (such 
> as nonexistent record or bad secret_hash).

Seems like a good idea, but apparently nonexistent records and bad secrets are OK due to replication inconsistencies, according to the last answer on this page: http://opendht.org/faq.html

> 3) I would recommend to classify the references as Normative 
> vs Informative.  It seems that RFCs 2045, 4843, 5201, 5205, 
> and I-D.cert are normative.  Is there a normative reference 
> for OpenDHT interface (rather than listing the website url in 
> the body of the draft)?

OK, this is probably a good normative reference for OpenDHT:
OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten Godfrey, Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005. 

thanks for the comments!

-Jeff