Re: feedback on draft-ietf-httpbis-message-signatures-13

On Mon, Oct 17, 2022 at 3:06 PM Backman, Annabelle <richanna@amazon.com>
wrote:

> there is no guidance to an implementer when HTTP Message Signatures would
> be preferable to other signature mechanisms.
>
>
> We attempt address this in the Introduction (Section 1)
> <https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#name-introduction>, which
> describes the limitations of TLS and challenges posed by HTTP itself.
>

There are other ways to provide signature mechanisms.


>
> We can add text to this effect under Requirements (Section 1.2)
> <https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#name-requirements>
> .
>
> There are a number of common deployment models where HTTP Message
> Signature will not preserve @target-uri as the @target-uri is different at
> the application server than what the client called.
>
> One of these is where a CDN such as CloudFront serves both static and
> dynamic content. The CDN routes requests that match certain paths to
> different hosts. For example when receiving a call to
> https://www.example.com/api/v1/* the CDN may proxy the call to
> https://v1.api.example.com/*
>
> Another is where messages are routed between microservices. A message
> router may route calls to https://www.example.com/api/v1/people/* to
> http://people within the services network.
>
> That would help.


>
> This is addressed in Application of HTTP Message Signatures (Section 1.4)
> <https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#section-1.4-2.5>,
> and in two Security Considerations: Message Component Source and Context
> (Section 7.4.3)
> <https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#name-message-component-source-an>
>  and Multiple Message Component Contexts (Section 7.4.4)
> <https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#name-multiple-message-component->.
> 1.4 and 7.4.3 in particular explain that the verifier may apply
> application-specific logic when deriving the context for a signature in
> order to account for transformations that are expected. 7.4.4 includes a
> non-normative example of how a reverse proxy such as a load balancer could
> add a `Forwarded` header field and its own signature to requests in order
> to allow a downstream verifier to verify the client's signature and verify
> that the transformations made to the @target-uri are acceptable.
>

"application-specific logic" is leaving the deficiencies when using a load
balancer as an exercise to the user. Perhaps writing a standard way to
resolve this would enable developers to use common infrastructure rather
than bespoke and potentially flawed implementations?

Are there any plans for AWS to add the signature mechanism and the
"Forwarded" header?


>
> the canonicalization was non-trivial
>
>
> Canonicalization has been brought up before, and I confess to being very
> confused every time it is raised, as pretty much the only
> "canonicalization" in HTTP Message Signatures is the lower-casing of HTTP
> header field names…which I'd like to think is a relatively safe move.
>

Unlike JOSE where the JSON is taken as an exact string, HTTP headers are
liberal in what they accept. For example, the Authorization header when
using an OAuth 2 access token could use Bearer or bearer, and may be
delineated by one or more white spaces. An intermediate processing of the
HTTP message may "clean" up extra white space, changing the content of what
is signed.

Per my own experience, I had mistyped the twitter.com URL to have HTTP
instead of HTTPS.

there were a number of non-deterministic flows
>
>
> The authors' believe the spec is deterministic. Have you identified ways
> or places where it is not?
>

I was referring to the implementation of XML-DSIG that we worked on

I also recall trying to do SigV4 by hand one time because the AWS service I
was testing out was in beta and there was no library for me to use with my
preferred language. I never did get it working -- I chose to wait for a
library.

I think the authors have done a laudable job of specifying how to make this
work. It is a HUGE spec and based on my experience and limitations above --
I would suggest seeing more interoperable implementations before moving to
WGLC so that you can smoke out other issues.

/Dick