Subject: RE: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 10:42:21 -0700

I am supportive of updating *a* registry.

The OAuth working group has an open requirement for standard identifiers to describe hash/digest functions.

What is not clear to me is the relationship of this registry and:

http://www.iana.org/assignments/hash-function-text-names/

which seems to overlap.

I am not sure why we need both, and if we do (because they are protocol specific and required for interoperability), how should a new specification decide which to use or if a new registry is required. For example my uneducated reading of 4572 suggests it is not exactly the same use case as the previous RFCs using that registry.

In addition, using different tokens for the same algorithm across protocols seems like a bad idea (lower case, upper case, SHA vs sha-1).

And since both include MD5... arguments about appropriate hash algorithm to increase security fail.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:ietf-announce-
> [email-masked]] On Behalf Of The IESG
> Sent: Friday, December 04, 2009 6:44 AM
> To: IETF-Announce
> Subject: Last Call: draft-bryan-http-digest-algorithm-values-update
> (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC
> 
> The IESG has received a request from an individual submitter to consider the
> following document:
> 
> - 'Additional Hash Algorithms for HTTP Instance Digests '
>    <draft-bryan-http-digest-algorithm-values-update-03.txt> as an
> Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2010-01-01. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm-
> values-update-03.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
> 19094&rfc_flag=0
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 22:34:20 -0700

This raises the obvious question - shouldn't we take greater action than simply update one of them? Should we consider combining them? Perhaps update the reason why we have them and make them more useful for other use cases?

I am just looking for clarifications.

EHL

> From: Anthony Bryan [mailto:[email-masked]]
> Sent: Friday, December 04, 2009 5:21 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; HTTP Working Group ([email-masked])
> Subject: Re: Last Call: draft-bryan-http-digest-algorithm-values-update
> Eran, to my knowledge there is no relationship between the two registries,
> besides some overlap. The registry you mention appears to be just hash
> function names and references a few X.509 RFCs.  I don't know about the
> history but it seems to be a more generic list. (We reference that registry in
> draft-bryan-metalink).
> 
> Here is the registry draft-bryan-http-digest-algorithm-values-update
> would update:
> Hypertext Transfer Protocol (HTTP) Digest Algorithm Values
> http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml
> 
> RFC 3230, which created this registry, doesn't refer to it by name, which isn't
> too helpful in finding it. The algorithms haven't been updated, so the newest
> entry is SHA, and some other references were inconsistent (different base64
> RFCs) and outdated (SHA), which this draft fixes. It also includes values which
> are not in the other
> registry: UNIXsum, UNIXcksum. "All digest-algorithm values are case-
> insensitive."
> (We also reference this registry in draft-bryan-metalinkhttp).
> 
> I agree, SHA vs sha-1 in the registries could be confusing but both these
> registries have co-existed for 7 years. I don't know how much either has
> been used in practice, besides our 2 drafts.
> 
> On Fri, Dec 4, 2009 at 12:42 PM, Eran Hammer-Lahav
> <[email-masked]> wrote:
> > I am not sure why we need both, and if we do (because they are protocol
> specific and required for interoperability), how should a new specification
> decide which to use or if a new registry is required. For example my
> uneducated reading of 4572 suggests it is not exactly the same use case as
> the previous RFCs using that registry.
> >
> > In addition, using different tokens for the same algorithm across protocols
> seems like a bad idea (lower case, upper case, SHA vs sha-1).
> >
> >> The IESG has received a request from an individual submitter to
> >> consider the following document:
> >>
> >> The IESG plans to make a decision in the next few weeks, and solicits
> >> final comments on this action.  Please send substantive comments to
> >> the [email-masked] mailing lists by 2010-01-01. Exceptionally,
> >> comments may be sent to [email-masked] instead. In either case, please
> >> retain the beginning of the Subject line to allow automated sorting.
> >>
> --
> (( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
>   )) Easier, More Reliable, Self Healing Downloads

---

From: Anthony Bryan <[email-masked]>
Date: Fri, 4 Dec 2009 20:21:16 -0500

Eran, to my knowledge there is no relationship between the two
registries, besides some overlap. The registry you mention appears to
be just hash function names and references a few X.509 RFCs.  I don't
know about the history but it seems to be a more generic list. (We
reference that registry in draft-bryan-metalink).

RFC 3230, which created this registry, doesn't refer to it by name,
which isn't too helpful in finding it. The algorithms haven't been
updated, so the newest entry is SHA, and some other references were
inconsistent (different base64 RFCs) and outdated (SHA), which this
draft fixes. It also includes values which are not in the other
registry: UNIXsum, UNIXcksum. "All digest-algorithm values are
case-insensitive."
(We also reference this registry in draft-bryan-metalinkhttp).

I agree, SHA vs sha-1 in the registries could be confusing but both
these registries have co-existed for 7 years. I don't know how much
either has been used in practice, besides our 2 drafts.

---

From: Anthony Bryan <[email-masked]>
Date: Mon, 7 Dec 2009 14:30:35 -0500

Indeed, that was my first reaction as well.

Both RFCs are standards track, which I have been told updating is an
involved process, especially since RFC3230 hasn't seen much
implementation until we started using it (AFAIK). Now we have a few
clients and more on the way.

I was advised just to update the registry. It is out of date and
contains inconsistencies.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Dec 2009 22:11:39 -0500

Changing the digest algorithm in DIGEST is pointless.

If you are going to make changes to align the scheme with modern
practice you would replace the digest function with a MAC such as
HMAC.

But there really is no point in doing that because

1) Implementations would still be vulnerable to downgrade attacks.
This is actually a problem with BASIC continuing to exist.

2) The on-the wire protocol is subject to a brute force attack over
the space of possible passwords. Unless we can persuade people to use
passwords longer than 25 characters that is going to be the weakest
point in the system no matter what the algorithm is.

3) RSA is now out of patent, that was the main constraint on DIGEST,
the algorithms had to be unencumbered.

I would be more interested in doing something like using self signed
SSL certs, putting a digest of the cert into the DNS and hoping that
DNSSEC is un-doofused some time this century.

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 10 Dec 2009 13:59:21 -0500

> Changing the digest algorithm in DIGEST is pointless.

Careful... from the Introduction to the draft:

        Note: This is unrelated to HTTP Digest Authentication.

---

From: Anthony Bryan <[email-masked]>
Date: Thu, 10 Dec 2009 17:17:34 -0500

>        Note: This is unrelated to HTTP Digest Authentication.

I have updated the abstract and introduction to (hopefully) be more clear.

Abstract

The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest
Algorithm Values" defines values for digest algorithms used by
Instance Digests in HTTP. Instance Digests in HTTP provide a digest,
also known as a checksum or hash, of an entire representation of the
current state of a resource. This draft adds new values to the
registry and updates previous values.

Introduction

The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest
Algorithm Values" defines values for digest algorithms used by
Instance Digests in HTTP.

Note: This is unrelated to HTTP Digest Authentication. Instance
Digests in HTTP provide a digest, also known as a checksum or hash, of
an entire representation of the current state of a resource.