Subject: Re: [http-auth] Review Request for third draft of "Signing HTTP Messages"

From: Manu Sporny <[email-masked]>
Date: Sun, 20 Jul 2014 20:45:35 -0400

On 05/18/2014 08:33 PM, Mark Nottingham wrote:
> This is looking pretty good IMO.

Hey Mark, sorry for the very delayed response to your comments. My four
day jobs got in the way. Responses and fixes below.

> * I think you need to strip out all of the motivation text (i.e., 
> substantial portions of 1.x); it makes claims that are hard to 
> justify about how this helps with pervasive monitoring, and it also 
> omits a lot of other potential uses for the spec. Just keep it 
> simple.

Done:

https://github.com/web-payments/web-payments.org/commit/406758440f22291f115fc54cd6491572dcf6a393

> * Section 2.1.3 - Is Date the default value if no ‘headers’ is 
> specified, or is it always in the set of headers? It isn’t clear
> from this text.

It's the default value if no 'headers' are specified. It is not always
in the set of headers. For example, if the developer doesn't include it
in the list of headers, it's not automagically added. I've tried to
clarify the text:

https://github.com/web-payments/web-payments.org/commit/c25f8c5c969f5500c3fd7868d98a5989bde0b1c8

> * Section 2.3. - How is whitespace around field-values handled — is 
> it included in the value or not? Note that as per 
> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#section-3.2>,
> it isn’t (but it would be good if you made this explicit, both in
> spec and with examples)

Whitespace around field values is not included. The spec now refers to
the appropriate section in draft-ietf-httpbis-p1-messaging-26:

https://github.com/web-payments/web-payments.org/commit/2e00f1a30dc99e80b18deebb30f4d4b03d4b4a75

> * Section 2.3 - Request-line is HTTP/1 specific, and — again — the 
> HTTP version is a hop-by-hop attribute of the message, so you’re 
> going to get signature failures through intermediaries. Suggestion: 
> use HTTP/2’s :method, :authority and :path pseudo-headers.

Are you asking me to:

1) Change the name `(request-line)` to something else like
   `(request-target)`?
2) Specify that the header field value should be constructed by
   concatenating the lowercased :method, an ASCII space,
   the :authority, an ASCII space, and :path pseudo-headers?

I'm assuming that you think that :scheme shouldn't be included because
it'll break when proxied internally between https->http? Speaking about
proxies, isn't using :authority going to break the signature from
hop-to-hop? Is it worth specifying that servers sitting behind a proxy
should use the X-Forwarded-Host or Forwarded-Host headers as a
replacement for :authority when recreating the signature? Now I'm
wondering if there is an attack that allows an attacker to inject both
X-Forwarded-Host and Forwarded-Host that would result in a compromised
signature.

I made both changes above, let me know if that's not what you wanted.

https://github.com/web-payments/web-payments.org/commit/495584b09f88acd439734fcfa9f9826bf40173c3

> * Can trailers be included in a signature?

In theory, yes. We've got another spec in the works about how to do this
(although it's horribly out of date and we don't know if we're going to
finish it any time soon... not much demand for it as far as we can tell):

https://web-payments.org/specs/source/http-signature-trailers/

I imagine that if/when we do, we'll require something like this header:

Signature: location=trailer

and then have the actual signature in the trailers.

> * Can a Signature header be included in the message trailers?

In theory, yes. We need to spec exactly how this would work. The feature
was deemed low-priority and out of scope for the base Signing HTTP
Messages spec.

> * You talk (often implicitly) about how a signature is created, but 
> not what constitutes a valid signature. This is going to be 
> especially important for the authentication scheme.

I tried to clarify by adding two sections. The first specifies how a
signature is created, and the second specifies how a signature is verified:

https://github.com/web-payments/web-payments.org/commit/d535b92c05f676c040c3e4efd417bd2e5b68ef68

... but don't know if that's what you were looking for.

Thanks a bunch for the input, let me know if some of the changes aren't
in line w/ what you wanted.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

---

From: Manu Sporny <[email-masked]>
Date: Sun, 20 Jul 2014 21:35:51 -0400

On 05/22/2014 02:04 AM, Yoav Nir wrote:
> Interesting draft. I finally found the time to go over it.

Hi Yoav, thanks and apologies for the very belated response.

> * I agree with Mark about keeping the motivation part simpler.
> Signing prevents forgeries, not monitoring.

I've tried to fix this issue here:

> * To my mind, the main motivation for this is that HTTP (and HTTPS) 
> are often not deployed end-to-end. There are internal proxies, 
> decrypting proxies, next-generation firewalls, load balancers, TLS 
> routers, and probably a dozen others I’ve forgotten. Each hop of an 
> HTTP connection may or may not be protected by TLS, may or may not 
> strip the encryption, and may or may not re-encrypt (and 
> re-authenticate) for the next hop. Signing requests are responses 
> provides end-to-end integrity, which current HTTP(S) does not
> provide.

That's true and well said. We also needed a very simple way to
authenticate the caller in one message. OAuth1/2 was too complex for our
needs. Do you think we should put something about single message
authentication in to the introductory text? I've tried to address both
points here:

https://github.com/web-payments/web-payments.org/commit/c0f262910c5385f736e9a0f7c556d12205fca9af

> * About the text in section 1 regarding password cracking:
> 
> Digest authentication, while providing a little more protection,
> still leaves the scheme open to brute-force attacks that are capable
> of discovering a weak or random 8 character password in less than 3 
> hours using a single commodity computer
> 
> I’m not sure how you can crack 8-character random passwords on a 
> commodity computer in 3 hours. Brute force won’t get you there. I 
> suggest you either explain how, point to a reference, or even better,
> pull it out.

Yes, the figure was wrong. I've pulled the text out. That's what I get
for using buggy online brute force password attack calculators. :)

> * The URL of signature schemes (
> http://www.iana.org/assignments/signature-algorithms ) is broken and
> I couldn’t figure out the one you meant.

There isn't one as far as I know. I'm requesting that IANA create one,
see Appendix E.2:

http://web-payments.org/specs/source/http-signatures/#sa-registry

> * 2.1.3: some headers may appear more than once (if their value is 
> defined as a comma-separated list). If there are such header lines, 
> I’m guessing the signature applies to all or none, right?  (that’s 
> not a bad thing - just a clarification question)

The signature applies to all of them, correct. See section 2.3 Signature
String Construction:

https://web-payments.org/specs/source/http-signatures/#canonicalization

Specifically, this sentence:

"""
If there are multiple instances of the same header field, all header
field values associated with the header field MUST be concatenated and
used in the order in which they will appear in the transmitted HTTP message.
"""

I'm not positive that this algorithm would survive all proxies, but I
couldn't think of a better approach.

> * I’m wondering if the WWW-Authenticate header should have a
> “headers” parameter. Otherwise, the server demands a signature, and
> then the client signs something, which may or may not cover
> everything the server policy says should be signed. This could be
> pre-arranged between client and server, but then the client should
> also know in advance when to sign. So I think the server should
> specify which fields need to be included in the signature.

You're right, that's a problem. I've tried to remedy that here:

https://github.com/web-payments/web-payments.org/commit/deefa4df47446c5ba6944e85021bd6b90659bfc3

Do you think it should be possible for the server to specify a
particular challenge as well? The challenge could be used to prevent
replay attacks of digitally signed messages. That said, it would
complicate the protocol and would be re-implementing TLS to a degree. It
would be useful for non-TLS connections, but I would imagine that those
sorts of connections would be using a nonce of some kind anyway. We've
kept this challenge-response feature out for the time being to simplify
the protocol.

Thanks for the feedback, Yoav. Let me know if those responses don't
address all of your concerns.

-- manu

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Jul 2014 11:38:54 +1000

Hi Manu,

This looks really good. A couple of comments below.

> https://github.com/web-payments/web-payments.org/commit/2e00f1a30dc99e80b18deebb30f4d4b03d4b4a75

Is this straight concatenation, or with a comma?

E.g., if you have

Cache-Control: max-age=60
Cache-Control: must-revalidate

Would the canonicalised string be:

Cache-Control: max-age=60must-revalidate

or

Cache-Control: max-age=60,must-revalidate

or...?

While your text isn't ambiguous really, people are very used to concatenate-delimit-with-comma (plus some whitespace, usually), and it might be good to point out what you mean (even if with an example).

> https://github.com/web-payments/web-payments.org/commit/495584b09f88acd439734fcfa9f9826bf40173c3

I meant mostly (2). 

What I'd suggest is to actually use the :-prefix that http/2 specifies, because it can't be part of a valid http header field-name. The method isn't part of the request-target, so that would leave you with these "special" header field names:

:method
:uri

For :uri, I'd refer to the Effective Request URI in RFC7230 Section 5.5; that's the concept you're looking to hook onto, I think, and it should be stable between HTTP versions.

> and then have the actual signature in the trailers.

Cool. Note that the Trailer header <http://tools.ietf.org/html/rfc7230#section-4.4> already allows this; e.g. you'd have:

Trailer: Signature

to indicate that Signature is coming in the trailers.

> was deemed low-priority and out of scope for the base Signing HTTP

OK. 

> ... but don't know if that's what you were looking for.

That looks like a good start.

Cheers,

--
Mark Nottingham   https://www.mnot.net/