Re: HTTP Signing

["Richard Backman, Annabelle" <[e-mail]>]

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

– 
Annabelle Richard Backman
AWS Identity
 

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

    Hi A.
    
    Il giorno ven 22 nov 2019 alle ore 12:10 Richard Backman, Annabelle
    <[e-mail]> 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.
    
    > 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" <[e-mail]> wrote:
    >
    >     Hi Rob & co,
    >
    >     Il giorno ven 22 nov 2019 alle ore 07:05 Rob Sayre <[e-mail]>
    >     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.
    >
    >     > [1] https://www.youtube.com/watch?v=CYBhLQ0-fwE
    >     > [2] https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html
    >
    >     Regards,
    >     R.
    >
    >
    >