Subject: draft-ietf-httpbis-message-signatures, a closer look

From: Watson Ladd <[email-masked]>
Date: Wed, 14 Jul 2021 14:03:02 -0700

Dear all,

I've taken a look at  draft-ietf-httpbis-message-signatures and think
there are some issues and unfortunate limitations, beyond the
algorithm field issue. By canonicalizing the request into a bit string
before signature verification, but not necessarily ensuring
implementation semantics match that canonicalization, all sorts of
problems may ensue.

Applications MUST ensure that headers that change the meaning of other
headers that are signed are included. Otherwise things go badly.
Ideally applications would only look at the signed data, but that
isn't really possible in HTTP.

In cases where signatures are validated by a proxy, but the request is
interpreted by a server, all the usual problems of request smuggling
rear their ugly head. It should be a requirement that requests are
treated with extremely strict RFC compliance ahead of verification.

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.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

---

From: Eric J Bowman <[email-masked]>
Date: Wed, 14 Jul 2021 14:48:25 -0700

---- On Wed, 14 Jul 2021 14:03:02 -0700 Watson Ladd <mailto:[email-masked]> wrote ----

 ...

...

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

---

From: Nick Harper <[email-masked]>
Date: Wed, 14 Jul 2021 15:10:16 -0700

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 <[email-masked]> wrote:

> ---- On Wed, 14 Jul 2021 14:03:02 -0700 *Watson Ladd
> <[email-masked] <[email-masked]>>* wrote ----
>
>
> ...
>
> 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
>
>
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 15 Jul 2021 10:01:46 +1000

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:
> 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, 14 Jul 2021 14:03:02 -0700 *Watson Ladd <[email-masked]>* wrote ----
> >> 
> >> ...
> >>

---

From: Justin Richer <[email-masked]>
Date: Thu, 15 Jul 2021 13:57:30 -0400

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 <[email-masked]> wrote:
>