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

From: Manu Sporny <[email-masked]>
Date: Thu, 08 May 2014 17:41:55 -0400

After feedback from Mark Nottingham[1], Julian Reschke[2], folks in the
HTTP Auth WG, and people in the Web Payments CG, we've modified the HTTP
Signatures specification in the following ways:

1. The specification has been renamed to "Signing HTTP Messages".
2. The specification now covers both a signature-based Authorization
   mechanism (client-to-server) as well as a general mechanism to sign
   HTTP messages (client-to-server and server-to-client).
3. A new "Signature" header has been introduced.
4. The layout has been modified heavily to streamline the information
   conveyed in the spec.
5. New registries have been created for the algorithms referred to in
   the specification.
6. We're now more specific in the way certain canonicalizations are
   performed.
7. More examples have been added, including how to digitally sign
   the body of an HTTP message.

The basic mechanism of generating the signatures has not changed (and
has been stable for over a year).

The newest spec can be found here:

http://tools.ietf.org/html/draft-cavage-http-signatures-02

The diff is here:

http://tools.ietf.org/rfcdiff?url2=draft-cavage-http-signatures-02.txt

Matt, Yoav, Kathleen, if there are no show stopping review comments, I'd
like to push this spec onto the RFC track in the HTTP Auth WG, or
HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize that
HTTP Auth may be shutting down next month, so what's the next step to
get the HTTP Signatures spec further down the IETF RFC track?

-- manu

[1] http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.html
[2] http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0036.html

-- 
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: Melvin Carvalho <[email-masked]>
Date: Fri, 9 May 2014 00:53:55 +0200

> 5. New registries have been created for the algorithms referred to in

Thanks for updating this, it looks great.

One thing, I'm slightly confused as to how algorithms should be specified.

For example: SHA256

Appears in the document and both lower case and upper case.

It also appears both with a hyphen and without a hyphen.

I'm also currently using sha-256 as specified in RFC 6920

I'd like to start using things like ECDSA signature as defined in crypto
currencies, but I am finding it challenging to find an easy to spot pattern
in the naming.

Any guidance would be appreciated.

> [1]
> http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.html
> [2]
> http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0036.html
>
> --

---

From: Manu Sporny <[email-masked]>
Date: Thu, 15 May 2014 16:29:52 -0400

On 05/08/2014 06:53 PM, Melvin Carvalho wrote:
> For example: SHA256 Appears in the document and both lower case and
> upper case. It also appears both with a hyphen and without a hyphen. 

It depends on where you're using it.

If you use it in the Digest header, it's "SHA-256" per RFC 5843:
http://tools.ietf.org/html/rfc5843#section-1.1

If you use it in the algorithm parameter of the Signature header or Auth
scheme, or you're specifying a particular signature algorithm, you
should use the value out of the signature algorithm registry:

http://tools.ietf.org/id/draft-cavage-http-signatures-02.html#rfc.appendix.E.2

> I'd like to start using things like ECDSA signature as defined in
> crypto currencies, but I am finding it challenging to find an easy to
> spot pattern in the naming.
> 

I spent a lot of time looking at how this sort of stuff is specified and
I couldn't see a pattern. Most of the RFC authors just specify the
values in the documents themselves. I also searched the entire IANA
registry for generic signature or hashing algorithm registries and
didn't find anything. Some do exist, but they tend to be very specific
to particular technologies (like TLS). Perhaps someone more
knowledgeable in this area, like Julian, could shed some light on a
general registry for hashing or signing algorithms.

If there are none, the spec requests that IANA create one here:

http://tools.ietf.org/id/draft-cavage-http-signatures-02.html#rfc.appendix.E.2

-- manu

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 May 2014 10:33:59 +1000

Hi Manu,

This is looking pretty good IMO.

A bit more feedback:

* 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.

* 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.

* 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)

* 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.

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

* 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.

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 22 May 2014 09:04:30 +0300

Hi, Manu

Interesting draft. I finally found the time to go over it. A few comments in no particular order:

I agree with Mark about keeping the motivation part simpler. Signing prevents forgeries, not monitoring. 
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.
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. 
The URL of signature schemes ( http://www.iana.org/assignments/signature-algorithms ) is broken and I couldn’t figure out the one you meant.
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)
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.

Regards,

Yoav