- From: Justin Richer <jricher@mit.edu>
- Date: Thu, 15 Jul 2021 13:57:30 -0400
- To: Martin Thomson <mt@lowentropy.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
The editors actually agree that application-level profiling is required for this, and we’d be happy to have suggestions on how to make section 1.5 (and any other places) be more clear. The reason for this approach, as argued before, is that the usage space of this spec is SO WIDE that a lot of things that make obvious sense for one set of use cases are in fact impossible or counterproductive in others. We’re trying to carefully define the tools and give instructions for using those tools, not specific instructions on what you’re trying to build using those tools. Also, want to point out that Nick Harper is exactly correct below — the URL elements can be covered as their own speciality elements and the body is covered by signing the digest header. The editors talked about having a “body digest” specialty identifier, but there didn’t seem to be a lot of value in that as a separate element. I’d be interested to know if there is interest in defining something like that — we’d need to coordinate that with however the new Digest draft works. — Justin > On Jul 14, 2021, at 8:01 PM, Martin Thomson <mt@lowentropy.net> wrote: > > What I think is not obvious enough from the draft is that this is not a secure solution, it's a tool from which you might be able to build a secure solution. And even then, like all such things, success is not assured, because even if you do remember to include Digest, you also need to ensure Digest is present and that it uses an adequate hash algorithm. > > This goes back to concerns raised earlier, that probably aren't worth rehashing (no pun intended). However, I find that Section 1.5 is not direct enough in its applicability claims. It seems like this enables security outcomes, but it is the profiles based on this work that will do that. It's almost like this needs a big "don't use this specification without a profile" warning label. > > On Thu, Jul 15, 2021, at 08:10, Nick Harper wrote: >> Parameters in the URL would be covered by the @request-content content >> identifier. The body of a POST request could be covered by a digest >> content identifier, assuming that the request includes a Digest HTTP >> header. >> >> On Wed, Jul 14, 2021 at 2:51 PM Eric J Bowman <mellowmutt@zoho.com> wrote: >>> __ >>> ---- On Wed, 14 Jul 2021 14:03:02 -0700 *Watson Ladd <watsonbladd@gmail.com>* wrote ---- >>>> >>>> ... >>>> >>>> As far as I could tell post parameters are not covered by a signature, >>>> and thus are vulnerable to modification. Modifying posted form data >>>> could be very problematic. It's fine if out of scope, but feels like >>>> it should be included to be useful, especially given that form data >>>> can interact with URL query parameters. >>> >>> ... >>> >>> Pardon my antiquated beliefs and terminology, but... >>> >>> POST parameters are just an URL and it's up to Layer 7 to validate URLs. They're meant to be modified, some folks call it a Web API. IMO, "message signature" applies to a payload not an URL. Feature not bug. >>> >>> -Eric >>> >>> >
Received on Thursday, 15 July 2021 17:57:45 UTC