Subject: HTTP Signing

From: Rob Sayre <[email-masked]>
Date: Thu, 21 Nov 2019 22:02:09 -0800

Hi,

I saw the "HTTP Signing" presentation in the SECDISPATCH meeting on
YouTube[1], and it seems like it's going to end up in this WG. Given the
people that spoke up at the mic, I'd like to suggest adopting something
very similar to AWSv4.

I've implemented the server side of AWSv4 in the past (not at Amazon). The
issues raised about splitting the HTTP request signing from higher-level
concerns are valid. However, I can also tell you that it's possible to use
off-the-shelf AWSv4 client SDKs, make up your own "service" name, and
implement the server side of the protocol. It's not too hard to imagine
what the server code might do if you read the example client code[2].

thanks,
Rob

[1] https://www.youtube.com/watch?v=CYBhLQ0-fwE
[2]
https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html

---

From: Roberto Polli <[email-masked]>
Date: Fri, 22 Nov 2019 09:48:43 +0100

Hi Rob & co,

Il giorno ven 22 nov 2019 alle ore 07:05 Rob Sayre <[email-masked]>
ha scritto:
> I saw the "HTTP Signing" presentation in the SECDISPATCH meeting on YouTube[1], and it seems like it's going to end up in this WG.
Interesting thread: the video is at
https://www.youtube.com/watch?v=CYBhLQ0-fwE&t=3000

>  I'd like to suggest adopting something very similar to AWSv4.
iiuc the approach of draft-cavage and signed-exchange is very similar
and the signed-exchange workgroup made a lot of progresses.
AWSv4 seems to me quite limited and IMHO if you expand it you'll
eventually end with
draft-cavage or http-signatures.

> I've implemented the server side of AWSv4 [...]
> it's possible to use off-the-shelf AWSv4 client SDKs, make up your own "service" name, and implement the server side of the protocol
Understand, though AWS can change that sdk in the future as that's
tied to their infrastructure.

> [2] https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html

Regards,
R.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 22 Nov 2019 11:20:14 +0100

On Thu, Nov 21, 2019 at 10:02:09PM -0800,
 Rob Sayre <[email-masked]> wrote 
 a message of 46 lines which said:

> YouTube[1] <https://www.youtube.com/watch?v=CYBhLQ0-fwE>.

For the record, this starts at 49:50.

Note that draft-cavage-http-signatures, which he mentioned, is both
implemented and widely deployed (fediverse software, such as Mastodon,
Pleroma, PeerTube, PixelFed, etc).

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 22 Nov 2019 11:10:00 +0000

There are some conceptual similarities between AWS Signature Version 4 (SigV4) and draft-cavage-http-signatures. Both signing mechanisms provide some flexibility regarding what protocol elements are covered by the signature, but cavage goes further here. Conversely, SigV4 has more rigorous canonicalization language. Ultimately these two concepts are the key to success here.

I believe the best path is for us to produce a core signing specification that defines signature generation and validation without getting prescriptive about what elements get signed. That can then be profiled (here in http, in oauth, in OpenID FAPI, ...) as needed, with profiles getting more or less prescriptive as is appropriate. That core spec is what I am currently working on, starting from cavage. I hope to have an I-D ready to present to the working group for adoption before the end of this year.

Here are a couple links, in case anyone is interested in learning more about SigV4:
 - Public documentation: https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html
 - Informational presentation I gave at IETF 105: https://www.youtube.com/watch?v=tUmT5qqlKik&feature=youtu.be&t=6400

– 
Annabelle Richard Backman
AWS Identity

On 11/22/19, 4:52 PM, "Roberto Polli" <[email-masked]> wrote:

    Hi Rob & co,

    

    Regards,
    R.

---

From: Roberto Polli <[email-masked]>
Date: Fri, 22 Nov 2019 13:43:51 +0100

Hi A.

Il giorno ven 22 nov 2019 alle ore 12:10 Richard Backman, Annabelle
<[email-masked]> ha scritto:
> [..] flexibility regarding what protocol elements are covered by the signature,
> [..and ..] rigorous canonicalization language.
> [..] these two concepts are the key to success here.

Agree, though AWS4 serialization could avoid specifying payload serialization
and delegate it to Digest (see https://github.com/martinthomson/http-mice and
the resulting revision of
https://httpwg.org/http-extensions/draft-ietf-httpbis-digest-headers.html).
Serializing the payload body brings the same problems that affected Content-MD5
 https://github.com/httpwg/http-core/issues/93

> [..] produce a core signing specification that defines signature generation and validation
> without getting prescriptive about what elements get signed.
> That can then be profiled (here in http, in oauth, in OpenID FAPI, ...) as needed.

My experience with pre-11 draft-cavage resulted in insecure
implementations due to under-specification
about which fields to sign. Please see
https://github.com/w3c-dvcg/http-signatures/issues/35 between the
others.
While we can define the general procedures, we should provide a table
or something of required fields
thus avoiding to address issues in future docs (eg. see JWT and
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/).

> That core spec is what I am currently working on, starting from cavage.
> I hope to have an I-D ready to present to the working group for adoption before the end of this year.

It would be great to see your ongoing work!
I'm following the draft-cavage implementation
from some time now, and we should try to make some merge work.
I think we should take into consideration all the work done by
https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html.

Thanks for sharing
and have a nice day,
R.

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 22 Nov 2019 13:56:01 +0000

> Agree, though AWS4 serialization could avoid specifying payload serialization and delegate it to Digest...
I'm looking forward to discussing how we should approach this in the working group. I think there's work to be done on message body signing, particularly for streaming. Neither stock SigV4 nor cavage (IIUC) handles that particularly well.

> My experience with pre-11 draft-cavage resulted in insecure implementations due to under-specification about which fields to sign.
From what I could tell, even on the thread you linked there was disagreement over whether Date and Expires should be included. __ Date is tricky because signature creation time seems obviously important but the signer may not have access to the value of that header. SigV4 and cavage work around this by providing alternate ways of specifying the creation time (X-Amz-Date, the created parameter). My inclination is that the core singing spec should be as non-prescriptive as possible, but it could offer guidance to profilers.

– 

On 11/22/19, 8:45 PM, "Roberto Polli" <[email-masked]> wrote:

    Hi A.

    

    
    
    Thanks for sharing
    and have a nice day,
    R.

---

From: Roberto Polli <[email-masked]>
Date: Fri, 22 Nov 2019 15:38:11 +0100

Il giorno ven 22 nov 2019 alle ore 14:56 Richard Backman, Annabelle
<[email-masked]> ha scritto:
> I'm looking forward to discussing how we should approach this in the working group.
> I think there's work to be done on message body signing, particularly for streaming.
> Neither stock SigV4 nor cavage (IIUC) handles that particularly well.
During last httpwg there was a discussion about sending multiple trailers.
That could be of some interest there: WDYT?

> From what I could tell, even on the thread you linked there was disagreement
> over whether Date and Expires should be included.
>  __ Date is tricky because signature creation time seems obviously important
> but the signer may not have access to the value of that header.
Agree!

> SigV4 and cavage work around this by providing alternate ways
> of specifying the creation time (X-Amz-Date, the "created" parameter).
Yes, I proposed to use `created` and `expires` to avoid that
the signature had to rely such headers. So while I thought that those
information
should be provided by the spec, I advocated not being prescriptive about
the `Date` header.

> My inclination is that the core singing spec should be
> as non-prescriptive as possible, but it could offer guidance to profilers.
If you mean that the specification should contain all the required informations
without prescribing the headers to be signed then it's ok :)

My 2¢,
R.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 22 Nov 2019 13:55:39 -0800

On Fri, Nov 22, 2019 at 12:48 AM Roberto Polli <[email-masked]> wrote:

> YouTube[1], and it seems like it's going to end up in this WG.

It is quite limited, and imho that's a good thing. The idea Annabelle has
put forth regarding a core signing specification seems like a good idea. In
my mind, that would hopefully build in something similar to AWSv4, while
also allowing others to build more complex and/or flexible features on top
of it.

Unrelatedly: one use case for these features are media uploads. It's pretty
common to break them up into several requests so they can be resumed and
retried at some level of granularity. AWS has some APIs that do this, but
their chunk sizes are quite large. Lots of mobile apps end up building
similar features with much smaller chunk sizes. For these use cases,
signing the payload in a trailer isn't so important, since the chunks are
pretty small anyway.

thanks,
Rob

---

From: Jeffrey Yasskin <[email-masked]>
Date: Sat, 23 Nov 2019 08:16:52 +0800

On Fri, Nov 22, 2019, 9:59 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> I think there's work to be done on message body signing, particularly for
> streaming. Neither stock SigV4 nor cavage (IIUC) handles that particularly
> well.

A small point: please be precise about whether you need to create the body
as a stream (incrementally), read it incrementally, or both. They seem to
lead to very different designs.

Jeffrey