Re: [http-auth] HTTP Signatures specification updated

Hey Mark,

Thanks a bunch for your feedback, responses to your comments below:

On 02/03/2014 09:54 PM, Mark Nottingham wrote:
> * There are many ways that signatures could be useful in HTTP, and 
> this is just one way. So, "HTTP Signatures" is a terrible name for 
> this; it's way to generic. Please change it. Suggestion: "The 
> 'Signature' HTTP Authentication Scheme' (but see Julian's comment 
> below).

Changed to what you suggested:

https://github.com/web-payments/web-payments.org/commit/3e22397d0d0222983d9d3a64342654e30eac5854

As I mentioned to Julian, we may change the spec to provide both client
to server and server to client authentication (or verifiability of
header fields where a receiving application can assume authentication
based on the digital signature). We'd love to hear your thoughts on the
best way to do that. For example, should we introduce a new HTTP header
field called "Signature" or "Verification"? Or should we extend the
"Authentication" header field in the response from the server to the client?

So, the name of the spec may change to:

"HTTP Security Rock Goddess version 3.awesome"

... which I'm sure we can all agree is a way better name that anything
that has been proposed to date. :P

> * Abstract - The term 'origin' is defined by RFC6454, and I don't 
> think that's how you're using it here; at best, you're
> authenticating the client *to* the origin.

Changed it to "server" since that's what I think the original author meant:

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

> * 1. Introduction - this is a protocol extension, not a protocol in 
> and of itself.

Fixed:

https://github.com/web-payments/web-payments.org/commit/b48b4a76f84cbe268992afcd877b2f9da60d4e03#diff-d50cc99f156dfafd46bcd16c22ee2187L85

> * 1. Introduction - "However, it is common place..." -- this
> sentence is probably going to get you in more trouble than it's worth
> :) Recommend dropping it. Also, you don't cover why Digest auth
> isn't good.

https://github.com/web-payments/web-payments.org/commit/95d724119b6cc7e797f42841338dbcbbedacd53b

> * 2.1.1.2 algorithm - "The full list of supported signature 
> mechanisms is listed below."  This sort of thing is usually
> delegated to a registry, so that you don't have to revise the whole
> spec to modify the list.  Also, "supported" is odd here, because this
> is a protocol specification, not a product specification.

Done:

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

and fixed the text here:

https://github.com/web-payments/web-payments.org/commit/9b1f24dfbc7b9da2c2d0d5b48ed636c5ad79a168

> * 2.1.1.3 headers - Signing the *whole* request-line is a very bad 
> idea, because the HTTP version is a hop-by-hop artefact, not 
> end-to-end. Also, the spacing of the request-line can be irregular. 
> I'd suggest you define how to canonicalise the request method + URI 
> (ideally, the effective request URI, *not* the request-target; see 
> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#section-5.5>).

Fixed the algorithm to generate the request line:

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

I'm hesitant to require the use of the effective request URI since the
Host can be digitally signed as well. I realize that there is still an
issue if an HTTP-based request is replayed over HTTPS, but if that's a
concern then the application should be using nonces.

If there is a stronger attack vector than that, we could use the
effective request URI. I'm just concerned that some applications may not
know whether they're going to submit the request over HTTP or HTTPS. I
mean, most of them should know that, but some of them might not? Looking
for guidance here because this is not an area that I know much about
(other than "this sounds like it might be a pain for developers and not
really increase the security of protocol extension enough to warrant the
increase in complexity").

> * 2.1.2 Signature String Construction - You need to define how to 
> canonicalise headers before processing, taking into account that 
> headers can recur, have varying whitespace between the field-name, 
> colon and value, whitespace at the EOL and varying line termination.

Addressed the headers recurring issue here:

https://github.com/web-payments/web-payments.org/commit/e8c14fa0b2fdc291473f1aa7302281e4915ee66e#diff-d50cc99f156dfafd46bcd16c22ee2187R208

We don't specify how to deal with whitespace in the field name because
we don't want to get into canonicalization. We could do a lighter form
of canonicalization (strip all whitespace at beginning and end of
string), but we'd rather the signature just not work for the
applications than have funky whitespace than try to explain how
canonicalization happens. The approach is: We'll sign whatever you give
us for the header field name. How has this approach worked out in the
past? I have a good idea of what your response is going to be. :)

I think we're fairly explicit about line termination being LF (aka
"\n"), what am I missing? We don't explicitly state LF or use hex values
in the spec, do you want us to do that?

> * You don't define a corresponding challenge. Your use cases might 
> not require a 401 + WWW-Authenticate, but have you considered that 
> some will want this?

Yes, we did consider it. We wanted this to be a mostly "you're verified
or you're not" mechanism. We didn't really want any sort of
back-and-forth negotiation. That said, it's a weak argument because you
probably want to be able to notify clients that they could access the
resource if they provided a signature.

If we decide that this is going to use the "Authorization" header (and
not some new kind of header), we'll define the WWW-Authenticate bits of
it. I've raised an issue to track it:

https://github.com/web-payments/web-payments.org/issues/23

>> 1) The spec seems to be confused about whether it defines an HTTP 
>> authentication scheme or not. If it does, it needs to follow the 
>> requirements in 
>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#authentication.scheme.registry;
>>
>> it does not, it shouldn't use the "Authorization" header field.
> 
> See especially 
> <http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-25#section-5.1.2>.

Ok, I've gone down the list and attempted to address each item (or make
a note that we need to deal w/ the item in the spec):

> HTTP authentication is presumed to be stateless

Check, it's stateless.

> The authentication parameter "realm" is reserved

We don't use it.

> The "token68" notation was introduced for compatibility with
> existing authentication schemes and can only be used once per
> challenge or credential.

We use the auth-param approach and stay far away from token68.

> When the auth-param syntax is used, all parameters ought to support 
> both token and quoted-string syntax, and syntactical constraints 
> ought to be defined on the field value after parsing (i.e., 
> quoted-string processing).

We were not doing this, it's been clarified in the spec now by removing
the ABNF, which was largely unnecessary:

https://github.com/web-payments/web-payments.org/commit/3b37035ae0c8c94c8705c4cb103fd801daa4b96f

> Definitions of new schemes ought to define the treatment of unknown
> extension parameters.

Fixed:

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

> Authentication schemes need to document whether they are usable in 
> origin-server authentication (i.e., using WWW-Authenticate), and/or
> proxy authentication (i.e., using Proxy-Authenticate).

Waiting on feedback from Julian and you to address this issue. It's
being tracked here:

https://github.com/web-payments/web-payments.org/issues/23

> Therefore, new authentication schemes that choose not to carry 
> credentials in the Authorization header field (e.g., using a newly 
> defined header field) will need to explicitly disallow caching

I'm sure someone more versed in HTTP knows what this means, but I'm
having a hard time figuring out if this applies to us. My reading on it is:

If you chose to use some information that's outside of the Authorization
header that is used by the authorization scheme in some way, you need to
be explicit about whether or not the request should be cached.

I don't think this applies to this spec because we are okay with a
response being cached if the digital signature on the request is the
same (ie: a botnet of clients requesting the exact same document with
the same set of headers signed).

That said, I'm probably not the best person to make this determination,
do you have any thoughts on the matter?

>> - If this is the Digest header field defined in 
>> <http://tools.ietf.org/html/rfc3230#section-4.3.2> then the spec 
>> should say so.
> 
> This confused me too.

Fixed:

https://github.com/web-payments/web-payments.org/commit/3e3d215d30ae7069703061b5be7db3917888fa00

Thanks a ton for the feedback Mark! It's very much appreciated. If you
could let us know your thoughts on how we should extend the spec to
cover both client to server and server to client verified HTTP headers,
that'd be swell. It doesn't seem like it would be much work, but we're
struggling wrt. a proper approach that would fit in with the larger body
of work on HTTP. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Worlds First Web Payments Workshop
http://www.w3.org/2013/10/payments/

Received on Friday, 7 February 2014 17:35:10 UTC