Open jyasskin opened 5 years ago
ioggstream
commented
5 years ago Hi @jyasskin!
The reason to use a digest is detailed in introduction and mentions SRI.
If I add the Signature use-case would it suffice?
I agree. I was just not sure whether deprecating that algorithms could limit the adoption of this draft, so I decided to ask the ietf. issue moved in #16.
LPardue
commented
5 years ago One use of digests is to ensure end-to-end integrity over multiple hops. While each hop has its own transport-layer integrity, there is a possibility that the true contents get somehow malformed (e.g. broken at rest, cosmic ray bit flips, buggy compressor, buggy manipulation etc.). Having an ability to validate integrity along the end-to-end path can help to reduce end-user errors. This has some nice side effect in certain deploments. One might imagine that intermediaries can detect errors from further up the chain and mitigate the problem before fanning out a known-bad resource to a large client population.
Another benefit is piecing together a resource from different sources (e.g. different servers that perhaps apply different content codings. The identiy digest allows the "final detination" to detect that the application-layer tasks completed properly, before handing off to say the HTML parser, video player etc.
For these reasons, I think that some use cases may want, and would benefit from, algorithms like MD5 etc. But I'm open to deprecating algorithms if there are good reasons. I tried to find some kind of official IETF document that makes recommendations in this space but came up empty handed.
jyasskin
commented
5 years ago I'm nervous about the end-to-end integrity use case for Digest: it only protects the representation data, while the headers are important for making sure the application interprets that data correctly. Buggy manipulation seems as likely to swap out a content-type, which wouldn't be caught by Digest, as to change the representation data, which would.
That said, if folks are actually using Digest to detect bugs, it makes sense to document what they're doing in this RFC.
LPardue
commented
5 years ago These are good points, thanks for writing them up.
I agree on its own that Digest has some limited guarantees, but the spec does try to highlight them.
The defenses here are mainly to avoid accidental or insipid errors, rather than malice. Defense in depth is required for that (using TLS for example).
Combining Digest with a Signature header (yours or Cavages) is one way to enhance the protections.
If we need to spell out things better in the spec, I think that's reasonable.
ioggstream
commented
5 years ago @jyasskin
[...] Digest: it only protects the representation data, while the headers are important
True, this is highlighted here but I filed #20 to move this discussion to a proper thread.
jyasskin
commented
5 years ago Note that end-to-end integrity against accidental corruption or errors (i.e. not attackers) could be ensured via a checksum-Digest that covers both the headers and the body. Only defense against attackers requires a signature or MAC by a trusted key.
ioggstream
commented
5 years ago I'm addressing those concerns here:
representation data]Feel free to emend!
LPardue
commented
5 years ago @jyasskin did we fulfilled your initial request for Digest use cases?
https://ioggstream.github.io/draft-polli-resource-digests-http/draft-polli-resource-digests-http.html#goals says a goal is "Digest coverage for either the resource’s representation data or selected representation data communicated via HTTP.", but it's not clear to me why a client and server would use a digest. Some options include:
Are there others? If those are the only ones, and message corruption isn't needed anymore, we could deprecate all the non-cryptographic digest algorithms.