Forbid empty `headers` parameter as it's subject to replay attacks.

[ioggstream]

I expect

headers should either be:

• present and populated, eg Signature: headers="foo bar", ...
• or absent

You should nevers sign an empty string.

Instead

The following is allowed

A headers parameter value without any headers MAY be provided, but since it results in a signature of an empty string it is of almost no utility and SHOULD NOT be used. This is distinct from not specifying a headers parameter at all.

Note

Allowing an empty header parameter is then:

• insecure and subject to replay attacks, as the same signature
  can be attached to multiple messages and potentially be used to identify the sender.
• confusing, as it's different from no headers;
• semantically inconsistent, as just signs nothing;

@msporny @liamdennehy do you agree?

[liamdennehy]

I disagree. A HTTP Message can have a header with no value provided. It is semantically meaningful to provide a parameter without a value, which is distinct from not providing the parameter at all. A value of null or zero is not the same as not providing a value. This is why I cleaned up up the language in #47.

If implementations permit empty headers, that's their choice, but I don't think we should be dictating that.

[ioggstream]

A HTTP Message can have a header with no value provided

Ok, but how is that related with a blank headers parameter?

eg.

Signature: headers="", ...

If implementations permit empty headers, that's their choice

imho permitting an empty headers parameter means that a compliant implementation must support that. We are actually forcing to support a weak part of the spec.

In that case, we should warn about reply attacks in the Security Considerations.

So the questions:

• is that worth?
• which are the legitimate use cases for sending something which we already advise to be

of almost no utility and SHOULD NOT be used

?

[liamdennehy]

My mistake, I read this as forbidding HTTP message headers with empty values, not an empty headers parameter in the Signature header.

The PR that introduced that language only cleaned up an ambiguity in the wording, it was not the intention to suggest this is a good idea. As you quote in the current version, it states this is of almost no utility.

I'm happy to forbid an empty headers, but then we should also talk about the minimums, since a signature with only Content-Type or Accepts would be similarly useless as these are also largely static.

[ioggstream]

My mistake, I read this as forbidding HTTP message headers with empty values

I think we should refactor the terminology, I have been confused for months :D

I'm happy to forbid an empty headers

+1

we should also talk about the minimums, since a signature with only Content-Type or Accepts would be similarly useless

Very true :) I'll open another issue for that.

[ioggstream]

@liamdennehy https://github.com/w3c-dvcg/http-signatures/pull/70

[dlongley]

I'm +1 to forbidding signing an empty string which is almost certainly a mistake. As long as that's what we're talking about disallowing here, I'm in favor.

[ioggstream]

70 is addressing this issue.

[ioggstream]

Closed in #70