Instance Digests in HTTP (RFC3230)
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
Instance Digests in HTTP (RFC3230)
by Anthony Bryan
::
Rate this Message:
I'd like to update the Hypertext Transfer Protocol (HTTP) Digest
Algorithm Values registry [1] created by RFC3230. Current values are MD5, SHA, UNIXsum, UNIXcksum. I'd like to add SHA-224, SHA-256, SHA-384, and SHA-512. My metalinkhttp ID [2] lists these in the IANA considerations section. I'd also like to find out about current support of Instance Digests on the client & server side. Should I keep these registrations in the metalinkhttp ID, or separate them [attached]? They're not specifically tied to metalinkhttp. Other questions... Current registry: MD5 lists both RFC1521 and RFC20456 for base64 encoding. Should this draft update it to refer to just one? Current registry: SHA link ( http://csrc.nist.gov/fips/fip180-1.txt ) is no longer valid. Should this draft update it? If we update SHA in the registry, should this draft refer to SHS or RFC3174? -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads [1] http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [2] http://tools.ietf.org/html/draft-bryan-metalinkhttp Network Working Group A. Bryan Internet-Draft Metalinker Project Intended status: Informational September 29, 2009 Expires: April 2, 2010 Hypertext Transfer Protocol (HTTP) Digest Algorithm Values Registry Update draft-bryan-http-digest-algorithm-values-update-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 2, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract [RFC3230] created the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" which defines values for Bryan Expires April 2, 2010 [Page 1] Internet-Draft HTTP Digest Algorithm Values Registry September 2009 digest algorithms used in HTTP. This draft adds new values to the registry. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 4. Normative References . . . . . . . . . . . . . . . . . . . . . 4 Appendix A. Acknowledgements and Contributors . . . . . . . . . . 4 Appendix B. Document History (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 Bryan Expires April 2, 2010 [Page 2] Internet-Draft HTTP Digest Algorithm Values Registry September 2009 1. Introduction The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" defines values for digest algorithms used in HTTP. This registry was created by [RFC3230] in 2002 and some useful values could be added to it. [[ Discussion of this draft should take place on IETF HTTP WG mailing list at ietf-http-wg@... or directly to the author. ]] 1.1. Examples Examples of Instance Digest for SHA-256: Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ== 2. IANA Considerations This document makes use of the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" specified in [RFC3230]. Accordingly, IANA has made the following registrations: Digest Algorithm: SHA-224 Description: The SHA-224 algorithm [SHS]. The output of this algorithm is encoded using the base64 encoding [RFC2045]. Reference: [SHS] [RFC2045] Digest Algorithm: SHA-256 Description: The SHA-256 algorithm [SHS]. The output of this algorithm is encoded using the base64 encoding [RFC2045]. Reference: [SHS] [RFC2045] Digest Algorithm: SHA-384 Description: The SHA-384 algorithm [SHS]. The output of this algorithm is encoded using the base64 encoding [RFC2045]. Reference: [SHS] [RFC2045] Digest Algorithm: SHA-512 Description: The SHA-512 algorithm [SHS]. The output of this algorithm is encoded using the base64 encoding [RFC2045]. Reference: [SHS] [RFC2045] Bryan Expires April 2, 2010 [Page 3] Internet-Draft HTTP Digest Algorithm Values Registry September 2009 3. Security Considerations Same as [RFC3230]. 4. Normative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC 3230, January 2002. [SHS] National Institute of Standards and Technology (NIST), "Secure Hash Standard", FIPS PUB 180-3, October 2008, <htt p://csrc.nist.gov/publications/fips/fips180-3/ fips180-3_final.pdf>. Appendix A. Acknowledgements and Contributors Thanks to Mark Nottingham, Eran Hammer-Lahav, and Nils Maier. Appendix B. Document History (to be removed by RFC Editor before publication) [[ to be removed by the RFC editor before publication as an RFC. ]] Known issues concerning this draft: o Current registry: MD5 lists both RFC1521 and RFC20456 for base64 encoding. Should this draft update it to refer to just one? o Current registry: SHA link ( http://csrc.nist.gov/fips/fip180-1.txt ) is no longer valid. Should this draft update it? o If we update SHA in the registry, should this draft refer to SHS or RFC3174? -00 : September 08, 2009. o Initial draft. Bryan Expires April 2, 2010 [Page 4] Internet-Draft HTTP Digest Algorithm Values Registry September 2009 Author's Address Anthony Bryan Metalinker Project Email: anthonybryan@... URI: http://www.metalinker.org Bryan Expires April 2, 2010 [Page 5] |
|
|
Re: Instance Digests in HTTP (RFC3230)
by Lisa Dusseault-3
::
Rate this Message:
Isn't more digest values worse for interoperability? Is there an overriding security concern that would justify worse interoperability?
Lisa On Mon, Sep 28, 2009 at 11:27 PM, Anthony Bryan <anthonybryan@...> wrote: I'd like to update the Hypertext Transfer Protocol (HTTP) Digest |
|
|
Re: Instance Digests in HTTP (RFC3230)
by Anthony Bryan
::
Rate this Message:
Interoperability seems rather lax, especially because I haven't been
able to find if there is actually any server side support (in shipping code) for anything to interoperate with. Does anyone know of any? I know of a few clients with support. >From RFC3230, 4.3.2 Digest A Digest header field MAY contain multiple instance-digest values. This could be useful for responses expected to reside in caches shared by users with different browsers, for example. A recipient MAY ignore any or all of the instance-digests in a Digest header field. A sender MAY send an instance-digest using a digest-algorithm without knowing whether the recipient supports the digest-algorithm, or even knowing that the recipient will ignore it. Because there are no recent values in the registry, I see download clients do this (3x variants of SHA1, 2x of other hashes): Want-Digest: MD5;q=0.3, MD-5;q=0.3, SHA1;q=0.8, SHA;q=0.8, SHA-1;q=0.8, SHA256;q=0.9, SHA-256;q=0.9, SHA384;q=0.9, SHA-384;q=0.9, SHA512;q=1, SHA-512;q=1 (IANA registry Hash Function Textual Names http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml has updated values). Various organizations warn... http://www.kb.cert.org/vuls/id/836068 "Do not use the MD5 algorithm Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use." http://csrc.nist.gov/groups/ST/hash/policy.html "Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010... Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols." And various organizations have put it into practice: https://fedoraproject.org/wiki/Features/StrongerHashes ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/7.2/CHECKSUM.SHA256 ftp://iso5.us.netbsd.org/pub/NetBSD/iso/5.0.1/SHA512 On Thu, Oct 1, 2009 at 7:22 PM, Lisa Dusseault <lisa.dusseault@...> wrote: > Isn't more digest values worse for interoperability? Is there an overriding > security concern that would justify worse interoperability? > > Lisa > > On Mon, Sep 28, 2009 at 11:27 PM, Anthony Bryan <anthonybryan@...> > wrote: >> >> I'd like to update the Hypertext Transfer Protocol (HTTP) Digest >> Algorithm Values registry [1] created by RFC3230. >> >> Current values are MD5, SHA, UNIXsum, UNIXcksum. >> >> I'd like to add SHA-224, SHA-256, SHA-384, and SHA-512. >> My metalinkhttp ID [2] lists these in the IANA considerations section. >> >> I'd also like to find out about current support of Instance Digests on >> the client & server side. >> >> Should I keep these registrations in the metalinkhttp ID, or separate >> them [attached]? They're not specifically tied to metalinkhttp. >> >> Other questions... >> Current registry: MD5 lists both RFC1521 and RFC20456 for base64 >> encoding. Should this draft update it to refer to just one? >> >> Current registry: SHA link ( http://csrc.nist.gov/fips/fip180-1.txt ) >> is no longer valid. Should this draft update it? >> >> If we update SHA in the registry, should this draft refer to SHS or >> RFC3174? >> >> -- >> (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] >> )) Easier, More Reliable, Self Healing Downloads >> >> [1] http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml >> [2] http://tools.ietf.org/html/draft-bryan-metalinkhttp > > -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads |
|
|
Re: Instance Digests in HTTP (RFC3230)
by Henrik Nordstrom-5
::
Rate this Message:
tor 2009-10-01 klockan 16:22 -0700 skrev Lisa Dusseault:
> Isn't more digest values worse for interoperability? Is there an > overriding security concern that would justify worse interoperability? Additional digest values do not make interop much worse than it already is, but there should be a minimum required set on both clients and servers. Related to this the negotiation aspect of RFC3230 should generally not be used on cachable responses as doing so would create yet another set of instances varying on the set of client indicated supported hashes. On such responses the server should just spew out the set of hashes it prefers to support with both interop and security in mind (i.e. usually one or two hashes today, maybe three). Regards Henrik |
|
|
Re: Instance Digests in HTTP (RFC3230)
by Nicolas Alvarez-2
::
Rate this Message:
Anthony Bryan wrote:
> On Thu, Oct 1, 2009 at 7:22 PM, Lisa Dusseault wrote: >> Isn't more digest values worse for interoperability? Is there an >> overriding security concern that would justify worse interoperability? > > Because there are no recent values in the registry, I see download > clients do this (3x variants of SHA1, 2x of other hashes): > > Want-Digest: MD5;q=0.3, MD-5;q=0.3, SHA1;q=0.8, SHA;q=0.8, > SHA-1;q=0.8, SHA256;q=0.9, SHA-256;q=0.9, SHA384;q=0.9, SHA-384;q=0.9, > SHA512;q=1, SHA-512;q=1 Clearly, if we don't add SHA-1 to the registry, people will use it anyway, but won't decide on a single name for it. *That's* worse for interoperability. |
|
|
Re: Instance Digests in HTTP (RFC3230)
by Lisa Dusseault-3
::
Rate this Message:
These responses do convince me why we need to add at least a couple more digest types to the registry. Since changes to this registry require a specification, I can offer to shepherd that specification (it can be an individual submission to Informational status, I'm pretty sure).
Thanks, Lisa On Tue, Oct 6, 2009 at 9:30 AM, Nicolas Alvarez <nicolas.alvarez@...> wrote: Anthony Bryan wrote: |
|
|
Re: Instance Digests in HTTP (RFC3230)
by Anthony Bryan
::
Rate this Message:
I take it you want these split out of metalinkhttp ID? They're not
specifically tied to metalinkhttp, so I've just submitted it separately as an individual submission with Informational status. Other questions: Current registry: MD5 lists both RFC1521 and RFC20456 for base64 encoding. Should this draft update it to refer to just one? Current registry: SHA link ( http://csrc.nist.gov/fips/fip180-1.txt ) is no longer valid. Should this draft update it? If we update SHA in the registry, should this draft refer to SHS or RFC3174? A new version of I-D, draft-bryan-http-digest-algorithm-values-update-00.txt has been successfuly submitted by Anthony Bryan and posted to the IETF repository. Filename: draft-bryan-http-digest-algorithm-values-update Revision: 00 Title: Hypertext Transfer Protocol (HTTP) Digest Algorithm Values Registry Update Creation_date: 2009-10-06 WG ID: Independent Submission Number_of_pages: 5 Abstract: [RFC3230] created the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" which defines values for digest algorithms used in HTTP. This draft adds new values to the registry. On Tue, Oct 6, 2009 at 3:09 PM, Lisa Dusseault <lisa.dusseault@...> wrote: > These responses do convince me why we need to add at least a couple more > digest types to the registry. Since changes to this registry require a > specification, I can offer to shepherd that specification (it can be an > individual submission to Informational status, I'm pretty sure). > > Thanks, > Lisa > > On Tue, Oct 6, 2009 at 9:30 AM, Nicolas Alvarez <nicolas.alvarez@...> > wrote: >> >> Anthony Bryan wrote: >> > On Thu, Oct 1, 2009 at 7:22 PM, Lisa Dusseault wrote: >> >> Isn't more digest values worse for interoperability? Is there an >> >> overriding security concern that would justify worse interoperability? >> > >> > Because there are no recent values in the registry, I see download >> > clients do this (3x variants of SHA1, 2x of other hashes): >> > >> > Want-Digest: MD5;q=0.3, MD-5;q=0.3, SHA1;q=0.8, SHA;q=0.8, >> > SHA-1;q=0.8, SHA256;q=0.9, SHA-256;q=0.9, SHA384;q=0.9, SHA-384;q=0.9, >> > SHA512;q=1, SHA-512;q=1 >> >> Clearly, if we don't add SHA-1 to the registry, people will use it anyway, >> but won't decide on a single name for it. *That's* worse for >> interoperability. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads |
|
|
Re: Instance Digests in HTTP (RFC3230)
by Anthony Bryan
::
Rate this Message:
New version incorporates comments from Pasi Eronen.
-02 : October 15, 2009. o New title. o "Note: This is unrelated to HTTP Digest Authentication." o Remove SHA-224 and SHA-384. o "Changes compared to RFC3230" section added. A new version of I-D, draft-bryan-http-digest-algorithm-values-update-02.txt has been successfuly submitted by Anthony Bryan and posted to the IETF repository. Filename: draft-bryan-http-digest-algorithm-values-update Revision: 02 Title: Additional Hash Algorithms for HTTP Instance Digests Creation_date: 2009-10-15 WG ID: Independent Submission Number_of_pages: 5 Abstract: [RFC3230] created the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" which defines values for digest algorithms used in HTTP. This draft adds new values to the registry and updates previous values. On Tue, Oct 6, 2009 at 3:09 PM, Lisa Dusseault <lisa.dusseault@...> wrote: > These responses do convince me why we need to add at least a couple more > digest types to the registry. Since changes to this registry require a > specification, I can offer to shepherd that specification (it can be an > individual submission to Informational status, I'm pretty sure). > > Thanks, > Lisa > > On Tue, Oct 6, 2009 at 9:30 AM, Nicolas Alvarez <nicolas.alvarez@...> > wrote: >> >> Anthony Bryan wrote: >> > On Thu, Oct 1, 2009 at 7:22 PM, Lisa Dusseault wrote: >> >> Isn't more digest values worse for interoperability? Is there an >> >> overriding security concern that would justify worse interoperability? >> > >> > Because there are no recent values in the registry, I see download >> > clients do this (3x variants of SHA1, 2x of other hashes): >> > >> > Want-Digest: MD5;q=0.3, MD-5;q=0.3, SHA1;q=0.8, SHA;q=0.8, >> > SHA-1;q=0.8, SHA256;q=0.9, SHA-256;q=0.9, SHA384;q=0.9, SHA-384;q=0.9, >> > SHA512;q=1, SHA-512;q=1 >> >> Clearly, if we don't add SHA-1 to the registry, people will use it anyway, >> but won't decide on a single name for it. *That's* worse for >> interoperability. >> >> >> > > -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads |
|
|
Re: Instance Digests in HTTP (RFC3230)
by Anthony Bryan
::
Rate this Message:
Revision 03 has tiny changes (RFC3230 -> RFC 3230), and earlier
incorporated suggestions from secdir list. ---------- Forwarded message ---------- From: IETF I-D Submission Tool <idsubmission@...> Date: Wed, Oct 21, 2009 at 6:42 PM Subject: New Version Notification for draft-bryan-http-digest-algorithm-values-update-03 To: anthonybryan@... A new version of I-D, draft-bryan-http-digest-algorithm-values-update-03.txt has been successfuly submitted by Anthony Bryan and posted to the IETF repository. Filename: draft-bryan-http-digest-algorithm-values-update Revision: 03 Title: Additional Hash Algorithms for HTTP Instance Digests Creation_date: 2009-10-21 WG ID: Independent Submission Number_of_pages: 5 Abstract: [RFC3230] created the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" which defines values for digest algorithms used in HTTP. This draft adds new values to the registry and updates previous values. The IETF Secretariat. On Thu, Oct 15, 2009 at 10:53 AM, Anthony Bryan <anthonybryan@...> wrote: > New version incorporates comments from Pasi Eronen. > > -02 : October 15, 2009. > o New title. > o "Note: This is unrelated to HTTP Digest Authentication." > o Remove SHA-224 and SHA-384. > o "Changes compared to RFC3230" section added. > > > A new version of I-D, > draft-bryan-http-digest-algorithm-values-update-02.txt has been > successfuly submitted by Anthony Bryan and posted to the IETF > repository. > > Filename: draft-bryan-http-digest-algorithm-values-update > Revision: 02 > Title: Additional Hash Algorithms for HTTP Instance Digests > Creation_date: 2009-10-15 > WG ID: Independent Submission > Number_of_pages: 5 > > Abstract: > [RFC3230] created the IANA registry named "Hypertext Transfer > Protocol (HTTP) Digest Algorithm Values" which defines values for > digest algorithms used in HTTP. This draft adds new values to the > registry and updates previous values. > > On Tue, Oct 6, 2009 at 3:09 PM, Lisa Dusseault <lisa.dusseault@...> wrote: >> These responses do convince me why we need to add at least a couple more >> digest types to the registry. Since changes to this registry require a >> specification, I can offer to shepherd that specification (it can be an >> individual submission to Informational status, I'm pretty sure). >> >> Thanks, >> Lisa >> >> On Tue, Oct 6, 2009 at 9:30 AM, Nicolas Alvarez <nicolas.alvarez@...> >> wrote: >>> >>> Anthony Bryan wrote: >>> > On Thu, Oct 1, 2009 at 7:22 PM, Lisa Dusseault wrote: >>> >> Isn't more digest values worse for interoperability? Is there an >>> >> overriding security concern that would justify worse interoperability? >>> > >>> > Because there are no recent values in the registry, I see download >>> > clients do this (3x variants of SHA1, 2x of other hashes): >>> > >>> > Want-Digest: MD5;q=0.3, MD-5;q=0.3, SHA1;q=0.8, SHA;q=0.8, >>> > SHA-1;q=0.8, SHA256;q=0.9, SHA-256;q=0.9, SHA384;q=0.9, SHA-384;q=0.9, >>> > SHA512;q=1, SHA-512;q=1 >>> >>> Clearly, if we don't add SHA-1 to the registry, people will use it anyway, >>> but won't decide on a single name for it. *That's* worse for >>> interoperability. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads |
| Free embeddable forum powered by Nabble | Forum Help |
