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

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:

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

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

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

Received on Monday, 21 July 2014 01:36:23 UTC