- From: Anthony Bryan <anthonybryan@gmail.com>
- Date: Sun, 4 Oct 2009 02:21:48 -0400
- To: Lisa Dusseault <lisa.dusseault@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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@gmail.com> 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@gmail.com> > 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
Received on Sunday, 4 October 2009 06:22:22 UTC