Re: [Acme] Signing HTTP Messages

[Richard Barnes <[e-mail]>]

On Fri, Dec 19, 2014 at 9:44 PM, Manu Sporny <[e-mail]>
wrote:
>
> On 12/19/2014 07:35 PM, Richard Barnes wrote:
> > Thanks for reaching out.  Just so the context is clear, there's
> > nothing in ACME currently that uses an HTTP header to convey a
> > signature structure.  It's all in the body.
>
> Good to know. My assumption was that ACME is being built on top of JOSE.
>
> > The draft-cavage- document had been pointed out to me before.  It's
> > too ambitious :)
>
> Haha, we were trying to do something sensible, not ambitious. :)
>
> > That draft tries to solve the problem of signing an HTTP message.
> > That's a fiendishly difficult problem because it involves headers,
> > whose complicated, ambiguous syntax is inimical to signing. Also,
> > middleboxes routinely tamper with headers.
>
> Yes, both rabbit-holes were taken into account when designing the spec.
> Just to be clear, we're not trying to sign /all/ HTTP headers in a
> message, the sender gets to pick which headers to sign, the server gets
> to decide whether or not that's good enough for the type of request.
>
> The developer can choose specific headers that don't have ambiguous
> syntax and ones that middleboxes are most likely not to modify.
>
> I think we address these two concerns in the "Signing HTTP Messages"
> spec as best we can.
>
> > All I want is to sign the body of the message.  HTTP treats the body
> > as an octet string, which means there's no c14n issues.  And
> > middleboxes tamper with bodies much less often.
>
> I think you can do this easily with the Signing HTTP Messages spec. Just
> digitally sign the Digest header (along with a few others to prevent
> replay attacks if doing so is important to the use case).
>
> There's an example of doing this in this section:
>
> https://tools.ietf.org/html/draft-cavage-http-signatures-03#section-3.1.2
>
> > Also, the draft-cavage- document invents its own signature syntax,
> > when it should just use JWS.
>
> What do you mean by "signature syntax"? Do you mean "the way the bytes
> are constructed in order to sign them"?
>
> The normative bits of the Signing HTTP Messages spec are roughly 5 pages
> in length vs. the 50+ pages in JWS. It didn't seem necessary to pull in
> all that unnecessary bloat just for signature string construction.
>
> It's true that maybe the length of the JWS spec is due to necessary
> security precautions that the Signing HTTP Messages spec overlooks, but
> if it does overlook something, we're not aware of it.
>
> Happy to be convinced otherwise, but I'd rather not expose implementers
> to JWS or JOSE in general.
>
> > So my proposal was: Start with a Content-Signature header that just
> > has a JWS covering the body.
>
> Sounds like a good idea. I think you could simplify it further and make
> it easier to implement.
>
> > In some cases that's all you want, and it's a more tractable problem
> > than covering HTTP messages as a whole.
>
> I think you may not quite understand what we're trying to do w/ that
> spec. Or, I don't understand the nuance that you're getting at. Either
> way, we're miscommunicating. :)
>
> > Then, if you want to protect HTTP headers later, you can add a
> > signed attribute to the JWS (e.g.,
> > digest(canonicalized-header-info)).
> >
> > Does that make sense?   Is that at all relevant to your use cases?
>
> What you're trying to do certainly makes sense, and if you want to use
> JWS to solve the problem, I guess you could do that. I still hold that
> the Signing HTTP Messages spec sounds like it could solve your problem
> in a much simpler way. For example, here's what a full solution might
> look like:
>
> ---------------------
> POST /foo HTTP/1.1
> Host: example.org
> Date: Tue, 07 Jun 2014 20:51:35 GMT
> Content-Type: application/json
> Digest: SHA-256=X48E9qOokqqrvdts8n...yWxBf7kbu9DBPE=
> Signature: keyId="Test",algorithm="rsa-sha256",
>   headers="(request-target) host date digest content-length",
>   signature="jgSqYK0yKclIHfF9zdA...NqNyAXKdxZZItOuhIs78w="
> Content-Length: 18
>
> {"hello": "world"}
> ---------------------
>


Just for context, here's the equivalent using JWS and protecting only the
body:

---------------------
POST /foo HTTP/1.1
Host: example.org
Date: Tue, 07 Jun 2014 20:51:35 GMT
Content-Type: application/json
Digest: SHA-256=X48E9qOokqqrvdts8n...yWxBf7kbu9DBPE=
Content-Signature: { "header": { "kid": "Test", "alg": "RS256" },
"signature": "jgSq...78w" }
Content-Length: 18

{"hello": "world"}
---------------------

Note that using JWS means that I can just toss the header into
JSON.parse(), whereas your construction requires custom parsing.  And if I
have a JOSE library already on hand (of which there are currently a
non-trivial number), I can just toss the whole thing in there and call
Verify().

Also, one thing I like about JWS is that you can make it self-verifying.
That is, you can replace the key ID ("kid") with the actual public key
("jwk"), so the verifier can just go ahead and verify without any
pre-provisioning of key IDs.  You can also include metadata like certs.
 (Yes, that starts to make the header a little big.  Deployment
consideration :) )

I wouldn't overestimate the complexity of JWS.  Lines of code is a better
metric than lines of spec.  It took me a couple of hours to write a JWS
library in Go; signing and verification take ~110 lines, most of which is
just algorithm mux/demux.
https://github.com/bifurcation/gose/blob/master/jws.go#L139

Finally, if you want to protect headers, you can add a protected header to
the above to bind in the header string by reference:

---------------------
{
  "header": { "kid": "Test", "alg": "RS256" },
  "protected": base64({
    "header": {
      "fields": "(request-target) host date digest content-length",
      "sha256": "KCBeV_VF5cEzgjY1cNEAkalw94mJwxtXdz874aRUbRM"
  })
  "signature": "jgSq...78w"
}
---------------------

... where the "sha256" field is the SHA-256 digest of the header string.

Is this making any more sense?  Basically: Use libraries and scale the
complexity to the problem.

--Richard



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