Subject: Re: [p2p-hackers] Re: draft-thiemann-hash-urn-00

From: Zefram <[email-masked]>
Date: Tue, 2 Sep 2003 15:02:57 +0100

Peter Thiemann wrote:
>I've seen this wish before, but I don't think that the name SHA-1
>should be attached to the longer variants.

That wasn't what was suggested.  I think the idea was that

  urn:hash:::abcdefghijklmnopqrstuvwxyz234567

means

  urn:hash::sha1:abcdefghijklmnopqrstuvwxyz234567

and

  urn:hash:::abcdefghijklmnopqrstuvwxyz234567abcdefghijklmnopqrs0====

means

  urn:hash::sha256:abcdefghijklmnopqrstuvwxyz234567abcdefghijklmnopqrs0====

and so on.  "sha1", "sha256", "sha384", and "sha512" would all be
supported hash identifiers, with their normal meaning.  Only when the
hash scheme identifier is omitted would the hash scheme be determined
from the length of the hash value.

I think it's a good solution to the problem of wanting a default hash
scheme but also needing to avoid the default becoming obsolete.

-zefram
-- 
Andrew Main (Zefram) <[email-masked]>

---

From: Peter Thiemann <[email-masked]>
Date: 02 Sep 2003 15:35:23 +0200

>>>>> "zooko" == zooko  <[email-masked]> writes:

    zooko> Since SHA-1, SHA-256, and SHA-512 are unambiguously distinguishable by the 
    zooko> length of the hash value, one could specify that "one of the three SHA 
    zooko> standards" is the default, and which one is determined by
    zooko> the length.

I've seen this wish before, but I don't think that the name SHA-1
should be attached to the longer variants. I see two approaches for
including the longer SHA standard in the identifiers:
1. change hash-scheme from "sha1" to "sha" and distinguish the
   variants by the length of the hash;
2. add hash-schemes "sha256", "sha384", and "sha512".

    zooko> By the way, hash-127 is not a cryptographically secure
    zooko> hash.

hash-127 is not mentioned in the current revision
draft-thiemann-hash-urn-00 (the appended document was cbuid-urn-00,
its precursor). 

-Peter

---

From: Peter Thiemann <[email-masked]>
Date: 24 Aug 2003 12:58:18 +0200

>>>>> "zefram" == zefram  <[email-masked]> writes:

    zefram> draft-thiemann-hash-urn-00 specifies that SHA-1 hashes are to be
    zefram> encoded in base32, but the example you give shows base16 encoding.
    zefram> Furthermore, the text specifying the use of base32 says the encoded hash
    zefram> value "consists of 20 BASE32DIG"; this is inconsistent with the later
    zefram> description of base32 encoding that requires padding of
    zefram> the encoded data.

Thanks for the observation, I'll fix it.

    zefram> I wonder whether defaulting the hash scheme (to SHA-1) is really any more
    zefram> useful than it is unclear.  A few years ago, the default hash scheme (in
    zefram> people's minds) was MD5; now it's SHA-1; in a few years it could well be
    zefram> SHA-256 or SHA-512 (which have already been defined).  I suggest that
    zefram> in ten years almost all hash URNs being generated will need the hash
    zefram> scheme explicitly specified, so we don't win much by having a default.
    zefram> Rather, the effect of the default will be to make the meaning of such
    zefram> hash URNs unclear, especially when the default scheme becomes an obscure
    zefram> historical relic.  We're seeing the very beginning of this problem now
    zefram> with systems that made MD5 the default.

My original ID for this namespace (appended) allowed for variation in
the hash scheme for exactly the reasons that your are
mentioning. However, during the discussion of that ID a preference
emerged to hardwire the schemes into the namespace definition. The
following concerns were articulated (quotes from the discussion, see
the URN NIDs mailing list archive at
http://lists.research.netsol.com/pipermail/urn-nid, the relevant
postings are in 2003-July)  

* I don't like the idea of making 'hash-scheme' extensible. It's not
  "easy" to add a new hash scheme, because old software would have to
  be updated.
* there will be different ids for the same resource-- impractical
  when you try to look it up under one id, but it's stored under
  another
* In order to avoid chosen-algorithm attacks, the set of standardized
  hashes should be kept very small and directly under the control of
  the IETF and at the guidance of the CFRG.  By having it as a top
  level URN scheme such as urn:sha1, implementors will tend to focus
  on the algorithm itself rather than the notion of generic hash-based
  naming. 
* We must avoid having a generic hash name space that allows
  developers to add new hashes willy-nilly.  I believe that many non
  crypto-savvy developers would tend to support every algorithm
  specified in the name space without understanding that by supporting
  multiple agorithms you introduce a weakest-link condition. 

There are certainly arguments in either direction. My conclusion from
the discussion is to hardwire a chosen set of hash schemes into the
namespace definition. If another hash scheme emerges as the de facto
standard or if one of the hash schemes becomes broken, then it will be
easy to post a revised namespace definition to add or remove hash
schemes. [Of course, this does not preclude anyone from ignoring the
namespace definition and use it in whatever way they please.] 

    zefram> While we're on defaulting, the media type: it seems more useful to me to
    zefram> say that the default is that the media type is simply not specified by
    zefram> the hash URN.  This is particularly useful if the application generating
    zefram> the URN doesn't know the media type (all too common).  An application
    zefram> reading a URN that doesn't specify media type may still be able to find
    zefram> out the media type itself from other sources, or make reasonable guesses,
    zefram> possibly based on contextual information that was not available to the
    zefram> URN generator.  Forcing application/octet-stream handling in the absence
    zefram> of specific knowledge is unwise.

My reading of the definition of application/octet-stream covers
exactly the case were the actual media type is not known and it's up
to the application to figure out what to do with it. To quote from
RFC2046, sec 4.5.1: 

   The "octet-stream" subtype is used to indicate that a body contains
   arbitrary binary data.
   [...]
   The recommended action for an implementation that receives an
   "application/octet-stream" entity is to simply offer to put the data
   in a file, with any Content-Transfer-Encoding undone, or perhaps to
   use it as input to a user-specified process.

-Peter

---

From: "Zooko" <[email-masked]>
Date: 1 Sep 2003 09:19:24 -0400

Since SHA-1, SHA-256, and SHA-512 are unambiguously distinguishable by the 
length of the hash value, one could specify that "one of the three SHA 
standards" is the default, and which one is determined by the length.

By the way, hash-127 is not a cryptographically secure hash.

My apologies if this has already been discussed -- I am travelling and have 
not followed the discussion closely.

Regards,

Bryce "Zooko" Wilcox-O'Hearn

http://zooko.com/

---

From: Peter Thiemann <[email-masked]>
Date: 04 Sep 2003 17:35:14 +0200

This message contains the first revision of ID
draft-thiemann-hash-urn-00.txt, which contains a namespace
application. All comments have been considered.