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

From: Manu Sporny <[email-masked]>
Date: Mon, 15 Sep 2014 21:31:19 -0400

On 07/27/2014 09:38 PM, Mark Nottingham wrote:
>> 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
>>
>>
>> 
> 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).

I've updated the spec to clarify
concatenate-delimit-with-comma-plus-single-space character and added an
example to make sure we're crystal clear in the spec about this:

https://github.com/web-payments/web-payments.org/commit/921c90dbd1a1c92ac2e56dadf9ef82669fd4dd02

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

I couldn't find the :-prefix pseudo header in RFC7230 or
draft-ietf-httpbis-http2-14. Using the effective Request URI would
include the protocol scheme and host in the signature string and could
break checking the signature in certain http->https proxy scenarios
(among others), right?

We've had to avoid specifying the mandatory use of scheme, port, and
hostname because there are edge cases where proxies that want to check
the signature before proxying the request on would generate the improper
signature string during the check. We recommend the following
pseudo-headers in the current spec:

:method :path

Is that an issue?

>>> * Can trailers be included in a signature?
>> 
> 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.

Oh hey, that's way better, thanks!

If you're good w/ the changes we've made above, then the comments on the
spec have slowed down to the point that we're going to do a final call
for implementations to get the 4 current libraries updated to the latest
version of the spec and get any other new implementations started.

-- 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: Yutaka OIWA <[email-masked]>
Date: Sat, 20 Sep 2014 11:47:51 +0900

Dear Manu,

> pseudo-headers in the current spec:

Could you explain a bit more about the "edge case"?
IMO, the hostname is quite essential for the verification
of message source in any cases, even though the
intermediate reverse-proxy is deployed.

Even in the existence of the reverse-proxy, the end server
could generally know how the content is delivered to the client
(iow, for which URL the client is requesting a resource),
even though the actual URL the proxy is requsting for
the server is different from that.
As far as this holds, there is no problem for including
the host part to the signature.
(Also, it is anyway required for generating 3XX responses,
 Refresh: header and other absolute URLs from applications.)

Our Mutual-Auth proposa  has a slightly resembling
requirement (for verifying the source host of the response).
The server-side module has a configuration parameter
for the host-string and TLS certificate hash,
which will override the default values acquired from
the server configuration and used for generation of
verification tokens, and it works.

2014-09-16 10:31 GMT+09:00 Manu Sporny <[email-masked]>:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

-- 
Yutaka OIWA, Ph.D.                 Leader, System Life-cycle Research Group
                               Research Institute for Secure Systems (RISEC)
     National Institute of Advanced Industrial Science and Technology (AIST)
                       Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Sep 2014 09:54:17 -0700

Hey Manu,

Thanks for following up. Some responses below.

> https://github.com/web-payments/web-payments.org/commit/921c90dbd1a1c92ac2e56dadf9ef82669fd4dd02

I think that’s pretty good. There are some quibbles that might come out in review later, but it’s pretty good. (hint: they’ll likely come from Julian).

> break checking the signature in certain http->https proxy scenarios

I meant <http://http2.github.io/http2-spec/#PseudoHeaderFields>

Specifically, :scheme :authority and :path.

WRT breaking the signature in proxy situations — yes, it will, and I’d argue that that’s the responsibility of the people doing that reverse proxying. The origin (scheme, host, port) is CRITICAL in the Web security model, and leaving it out of any signature scheme simply doesn’t make sense.

> pseudo-headers in the current spec:

See above.

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