Signed Headers should either mention representation metadata or forbid them

[ioggstream]

I expect

Representation metadata (Content-Type, Content-Encoding, Content-Language) should be either:

• included in Signed headers
• forbidden

Because: see notes

Instead

There's no clear indication about the relation between Digest and Representation modifier.

Notes

https://tools.ietf.org/html/rfc7231#section-3.1 indicates the following representations metadata

• Content-Type
• Content-Encoding - in requests too
• Content-Language
• Content-Location

As Digest must be calculated on the "selected representation" which is tied to representation metadata

We either should:

• forbid Content-Encoding in request
• add Content-Encoding to Signature headers

Probably, a similar reasoning should be done for Content-Language.

[ioggstream]

@mnot does it sound reasonable to you?

[mnot]

All of these headers can affect how a recipient interprets the message. Content-Type is the most obvious, of course. So I'd include them.

[msporny]

@ioggstream @mnot, yes, I agree that doing so would provide a smaller security attack surface. That said, we already have lots of deployed implementations in production (we have no idea exactly how many): https://github.com/w3c-dvcg/http-signatures/issues/1

Would it be acceptable if we stated that it is recommended that those items are signed as well, but for a base level conforming implementation, they don't need to be? Something to this effect:

If Content-Type, Content-Encoding, Content-Language, or Content-Location are included in headers, they SHOULD be included in the list of headers that are signed.

If Content-Digest is included in the list of headers that are signed, then Content-Type, Content-Encoding, Content-Language, and Content-Location SHOULD be included as well.

Could we generalize the language to something like?

If any Content-* header exists in the message, then it SHOULD be included in the list of headers that are signed.

[dlongley]

Most implementations verify after decoding content... so signing Content-Encoding may be tricky/the wrong thing to do.

[msporny]

signing Content-Encoding may be tricky/the wrong thing to do.

Ugh, right... In general, the spec tries not to be super prescriptive about which headers are signed because, in general, when we try to make a particular header mandatory, someone seems to appear with a legitimate reason why it doesn't work for their use case (e.g., proxies, wrong part of the processing pipeline, middle-boxes making it impossible to relay the message, etc.)

[ioggstream]

@msporny

the spec tries not to be super prescriptive about which headers are signed

That's clear. The point is:

1. Content-{Type,Encoding,Language,Location} representation metadata they act on the representation (aka the content)
   2. should I trust a signed request from somebody in the middle that tampered the representation?

As banking apis relies on this spec, I'd make it as simpler as possible, but not simpler;

If Content-Type, Content-Encoding, Content-Language, or Content-Location are included in headers, they SHOULD be included in the list of headers that are signed.

This SHOULD would open the door to broken implementations that hit badly JWT. Let's make different mistakes ;)

If Content-Digest is included

Do you mean Digest, or you're thinking to another header?

If any Content-* header exists in the message, then it SHOULD be included in the list of headers that are signed.

There are various non-standard Content-* headers (eg. Content-MD5) which are not representation metadata, so I'd rather reference "all representation metadata referenced in RFC7231". @mnot knows better than me.

[ioggstream]

@dlongley afaik as Digest is a property of the selected representation:

• MUST be calculated on the Content-Encoded payload
• MUST be validated before decoding.

so signing Content-Encoding may be tricky/the wrong thing to do.

I understand this position, but afaik "Content-Encoding" is part of the semantics: without content-encoding I cannot know whether I downloaded a "gzipped file" or a gzip-encoded html page object.

And when signatures are involved it means you have signed different things, that is:

• in the first case a text/html full of garbage bytes
• in the second, a proper text/html

[LPardue]

We have used Signature with Instance digests and ended up asking ourselves some similar questions, I posted these to the HTTP mailing list: https://lists.w3.org/Archives/Public/ietf-http-wg/2018AprJun/0192.html

One of the salient points of that discussion was from Julien Reschke:

AFAIR, there were arguments about whether RFC 3230 actually got the terminology right (it tries to clarify RFC 2616 but IMHO added even more confusion). If you are serious about this, you may want to update RFC 3230 based on the terminology in RFC 723*.

Since then there has been great progress on updating the core HTTP documents, but I think the fundamental concerns still remain.

[ioggstream]

@LPardue I had a brief discussion on updating RFC 3230 to reference "Selected Representation" here

• https://github.com/martinthomson/http-mice/issues/11#issuecomment-409415793

How did it end with your Digest header?

PS: check your 19jul emails ;)

[ioggstream]

@msporny probably the first step is to add all those considerations to the [Security] section.

[ioggstream]

We're addressing this in https://datatracker.ietf.org/doc/draft-polli-resource-digests-http/

[ioggstream]

Most implementations verify after decoding content... so signing Content-Encoding may be tricky/the wrong thing to do.

@dlongley in https://ioggstream.github.io/draft-polli-resource-digests-http/draft-polli-resource-digests-http.html#rfc.section.3 we introduce two identity digest algoritms:

• eg: id-sha-256=fafafafa= contains the sha256 of the representation with no content coding applied.

Still you should explicitly include Content-Encoding in the signature to protect the recipient from malicious intermediaries removing content-encoding and altering the semantic of the message.

This is now nicely explained in https://ioggstream.github.io/draft-polli-resource-digests-http/draft-polli-resource-digests-http.html#rfc.section.2