search

ioggstream / draft-polli-resource-digests-http

THIS REPO WAS MOVED TO https://github.com/httpwg/http-extensions/
https://httpwg.org/http-extensions/draft-ietf-httpbis-digest-headers.html
Other
0 stars 1 forks source link

Remove non-cryptographic algorithms #16

Closed ioggstream closed 5 years ago

ioggstream commented 5 years ago

I expect

Non-crypto algorithms be deprecated and removed from this draft.

Because

Note

While crc2 and adler32 are mentioned in http-dig-alg registry I can't find any reference in RFC3230 nor in RFC5843.

@jyasskin does it sound good to you?

jyasskin commented 5 years ago

Note that SHA (SHA-1) is also subject to collisions (recently, chosen-prefix collisions) and should be deprecated with MD5.

If the use case of detecting random errors across multiple hops (#15) is important, I think it's reasonable to keep some of the non-cryptographic algorithms, even if they're no stronger than the transport-layer integrity protection that guards each hop.

To discourage mistakes, I'd advocate for deprecating the broken-cryptographic algorithms even if some of the never-cryptographic algorithms are still useful.

LPardue commented 5 years ago

Thanks for the input.

ioggstream commented 5 years ago

I integrated this discussion in the #19

I have no preferences between NOT RECOMMENDING broken cryptos vs deprecating.

Which is the correct way of deprecating though? Should we remove every reference of MD5 and SHA1 from this doc?

jyasskin commented 5 years ago

https://tools.ietf.org/html/rfc3864#section-4.2.1 defines a "status" field for https://www.iana.org/assignments/message-headers/message-headers.xhtml, which can take the values "obsoleted" or "deprecated". My guess is that draft-polli-resource-digests-http should list the complete contents that we want for https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1, including the new status column, but @mnot would know how to do it for sure.

We shouldn't just remove existing digest values from the registry, since that'll confuse people who see them in the wild. They need to be explicitly marked.

mnot commented 5 years ago

The draft should just list what it wants IANA to do to the registry as a set of operations; no need to re-populate the registry.

One of those steps should be updating the registry to point to this spec as its establishing document, right?

For deprecated entries, Security Considerations (or somewhere else, as appropriate) should list why.

ioggstream commented 5 years ago

I tried to fix it in #24.

ioggstream commented 5 years ago

When you have time, close if you like the solution (you should be able now) ;)

LPardue commented 5 years ago

Let's close this because #24 got merged.