Subject: Partial signatures on the Via header

From: Justin Richer <[email-masked]>
Date: Fri, 10 Sep 2021 15:54:53 -0400

One of the foundational goals of the HTTP Message Signatures draft is that a signed message can be reasonably robust against expected transformations by intermediaries. The editors want some feedback from the experts in the community on a particular transformation: 

It seems that a fairly common case is for an intermediary to add a Via header to a message as it’s passed through. The originating client won’t have access to the value of this header, and therefore wouldn’t be likely to sign it. But an intermediary that adds the Via header might add its own signature covering that header, thereby giving downstream parties some assurance about the identity of the intermediary named in the header. Another intermediary :after: that first one would then add its own Via header, which would break the signature created by the first intermediary. This same process could be repeated N times as a message is passed through different intermediaries for processing.

Previously the HTTP Message Signatures draft had a feature that allowed a signer to sign a list-prefix of [n] items for any list-valued items, designed to allow an intermediary to sign the value of the Via header so-far but indicate that more would probably be added. However, this was defined in terms of Structured Fields, which Via is not defined as. Therefore, the target use case The list-prefix function was removed from the signatures draft because of that mismatch.

With the definition of several new specialty message components in the latest (-06) draft, the editors would like to propose an alternative approach for handling Via headers that might be more robust:

Instead of relying on structured fields directly and trying to make this a general purpose solutions could instead define an “@via” component identifier that takes a single numeric parameter indicating which value of the Via headers are signed. So if you had two Via headers (or one header with two values), you could sign “@via”;index=0 and “@via”;index=1 to indicate the specific values you’re signing. Someone downstream can add their own Via and sign “@via”;index=2, ignoring the other values if they want. 

This could possibly be extended to any list-format header, but it seems to make some sense to call out Via specifically because:

 - It is additive in nature; intermediaries tack on themselves to the existing list (right?)
 - It’s expected to be modified in this specific way most of the time

Since this is pretty specific functionality, it could also be targeted to an extension instead of the core signatures document, or it could just be another specialty identifier added to the current list.

Thanks in advance for your input,

 — Justin and Annabelle

---

From: Eric J Bowman <[email-masked]>
Date: Fri, 10 Sep 2021 13:20:36 -0700

> - It is additive in nature; intermediaries tack on themselves to the existing list (right?) 

Many rural/3rd-world ISPs use intermediaries to inject adware on the last hop, without tacking themselves onto the Via list.

-Eric

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 10 Sep 2021 15:22:05 -0700

> On Sep 10, 2021, at 12:54 PM, Justin Richer <[email-masked]> wrote:
> 
> It seems that a fairly common case is for an intermediary to add a Via header to a message as it’s passed through.

Yes, that's the entire purpose of the Via field. In particular, it describes the message path as it was received by that intermediary. It has no security or integrity purpose, whatsoever, since each intermediary has complete control over the field contents (including not sending them at all, replacing names with pseudonyms, etc.). A signature would be counterproductive.

I suggest that Via be excluded from your draft's message signature.

....Roy

---

From: Justin Richer <[email-masked]>
Date: Sat, 11 Sep 2021 12:02:07 +0000

I meant that's how it's used when it's used, not that it was required. 

-Justin
________________________________________
From: Eric J Bowman [[email-masked]]
Sent: Friday, September 10, 2021 4:20 PM
To: Justin Richer
Cc: HTTP Working Group
Subject: Re: Partial signatures on the Via header

-Eric

---

From: Justin Richer <[email-masked]>
Date: Sat, 11 Sep 2021 12:01:28 +0000

Via can already be excluded by simply not signing it. Are you suggesting that we explicitly say that it should not be signed, for the reasons you mention? 

-Justin
________________________________________
From: Roy T. Fielding [[email-masked]]
Sent: Friday, September 10, 2021 6:22 PM
To: Justin Richer
Cc: HTTP Working Group
Subject: Re: Partial signatures on the Via header

....Roy

---

From: Eric J Bowman <[email-masked]>
Date: Sat, 11 Sep 2021 05:26:56 -0700

I understand that. But I'm not seeing a use case where it's reliable, unless control of intermediaries (intranet) is guaranteed. If the goal of your draft is robust messaging over the open Internet, I think you're barking up the wrong tree by signing Via headers, even *if* you could make it required.

I've only ever coded Via headers as an exercise in protocol pedantry, as a placeholder for accomplishing something useful down the road. But even validating messages between an origin server and a front-end cache on the same network can be achieved by other means. Via's nice in theory, but useless in practice...

-Eric

________________________________________ 
From: Eric J Bowman [mailto:[email-masked]] 
Sent: Friday, September 10, 2021 4:20 PM 
To: Justin Richer 
Cc: HTTP Working Group 
Subject: Re: Partial signatures on the Via header 

 
-Eric

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 12 Sep 2021 04:17:10 +1200

> Via can already be excluded by simply not signing it. Are you suggesting that we explicitly say that it should not be signed, for the reasons you mention?

That might be useful.

Amos

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 11 Sep 2021 09:30:02 -0700

> On Sep 11, 2021, at 5:01 AM, Justin Richer <[email-masked]> wrote:
> 

Unless the goal is to fail verification, signing Via is unwise because it is supposed to be changed by recipients as the message is received (usually before the message semantics are processed). I don't think I would go as far as making it a SHOULD NOT requirement, but I would never sign it myself.

....Roy

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 13 Sep 2021 10:04:10 +1000

On Sun, Sep 12, 2021, at 02:30, Roy T. Fielding wrote:
> Unless the goal is to fail verification, signing Via is unwise because 
> it is supposed to be changed by recipients as the message is received 
> (usually before the message semantics are processed). I don't think I 
> would go as far as making it a SHOULD NOT requirement, but I would 
> never sign it myself.

This almost obvious enough that writing it down is unnecessary :)

In cases where intermediaries add information that needs to be authenticated (asking why this might be is a worthwhile exercise), perhaps they can copy the information to a header field that is specific to that purpose.

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 13 Sep 2021 01:21:48 +0100

On Mon, 13 Sep 2021, 01:08 Martin Thomson, <[email-masked]> wrote:

> In cases where intermediaries add information that needs to be
> authenticated (asking why this might be is a worthwhile exercise), perhaps
> they can copy the information to a header field that is specific to that
> purpose.
>

"Via" had practical deployment problems enough as it is, without people
trying to sign and validate it. I think special casing it in this draft is
a nudge in the wrong direction. But I agree that maybe there is some merit
in considering intermediary treatment of headers, CDN-Loop comes to mind.

Cheers
Lucas

---

From: Justin Richer <[email-masked]>
Date: Mon, 13 Sep 2021 17:30:25 -0400

Jumping back on the top of the thread to summarize the next steps: 

This was some pretty clear and strong feedback, thanks everyone for providing it. The editors will add a note about this header to the security considerations section (namely, saying that it can’t really be relied on) but will neither put a normative requirement nor a special-cased field to support it.

Thanks,
 — Justin

> On Sep 10, 2021, at 3:54 PM, Justin Richer <[email-masked]> wrote:
>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 14 Sep 2021 07:40:39 +1000

On Tue, Sep 14, 2021, at 07:30, Justin Richer wrote:
> This was some pretty clear and strong feedback, thanks everyone for 
> providing it. The editors will add a note about this header to the 
> security considerations section (namely, saying that it can’t really be 
> relied on) but will neither put a normative requirement nor a 
> special-cased field to support it.

I think maybe you want a simple note, with Via only referenced as an example.  That is:

Any field that might be added to or altered by an intermediary might cause signatures to become invalid. This might be the case for Via, Forwarded-For, and CDN-Loop (or pick your own favourite examples).

---

From: Mike Bishop <[email-masked]>
Date: Thu, 16 Sep 2021 18:55:46 +0000

Can I suggest "is expected to be" rather than "might be"?  Any header field *might* be altered by an intermediary.

-----Original Message-----
From: Martin Thomson <[email-masked]> 
Sent: Monday, September 13, 2021 5:41 PM
To: [email-masked]
Subject: Re: Partial signatures on the Via header

On Tue, Sep 14, 2021, at 07:30, Justin Richer wrote:
> security considerations section (namely, saying that it can’t really 
> be relied on) but will neither put a normative requirement nor a