Re: Artart last call review of draft-ietf-httpbis-message-signatures-16

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

As Justin mentioned, AWS uses a proprietary HTTP request signature algorithm called "Signature V4” or “SigV4”, which uses a similar pattern as HTTP Message Signatures. Version 4 has been in use for over a decade, and today SigV4 signatures are required on nearly all authenticated HTTP requests to AWS APIs. While many clients use the implementation that AWS provides as part of our SDKs, some clients opt to write their own implementations. (a simple Google search for “aws sigv4 implementation"<https://www.google.com/search?q=aws+sigv4+implementation> shows several non-AWS implementations on Github, NPM, etc.)

You can find a complete description of SigV4 in the AWS General Reference guide<https://docs.aws.amazon.com/general/latest/gr/signing-aws-api-requests.html>.

Note that like HTTP Message Signatures, SigV4 is not a complete security protocol. It’s simply an algorithm for crafting a detached signature over portions of an HTTP request. AWS combines it with other systems (e.g., AWS Identity and Access Management, AWS Security Token Service) to complete the picture. The authors similarly expect HTTP Message Signatures to be plugged into existing security protocols such as OAuth 2.0, where there are already well-defined mechanisms for establishing and managing keys, identifying parties, etc. Extending HTTP Message Signatures to make it more of a full security protocol would thus be duplicative, and significantly limit its utility.

On 7 Mar 2023, at 19:43, Harald Alvestrand <[e-mail]<mailto:[e-mail]>> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Thanks for the comments on the review!

One particular point, which I think is the most important:

On 3/7/23 18:39, Justin Richer wrote:

IF it is possible to:
- Describe 2 or more “applications” (in the document’s terminology)
that serve
an useful function in securing some part of the ecosystem against some
attack -
Implement these functions in a way that exercises a fairly
comprehensive subset
of the behaviors mandated in this document - Run the resulting
application in a
real environment for some significant period of time, and observe that the
number of canonicalization errors resulting in validation failure is
insignificant to zero THEN it seems to me reasonable to place this on the
standards track.

Until then, I think this best belongs as an experimental protocol that
people
can implement to gather experience with, not something that the IETF
should
publish as a consensus standards-track protocol.


There are many very real applications from which this draft’s text was
distilled over the last few years. The general approach in this document
has been in use for well over a decade, in production and at scale, in
multiple deployed systems.

Amazon’s SIGv4 is probably the most well-exercised version of this
approach, and it’s still in use today (I can’t speak for Amazon’s plans
but they are sponsoring one of the editors to work on this draft):
https://docs.aws.amazon.com/general/latest/gr/signing-aws-api-requests.html <https://docs.aws.amazon.com/general/latest/gr/signing-aws-api-requests.html>

The engineers behind this original work at Amazon published their
original I-D back in 2013, known as the Cavage draft in the community.
This has many implementations in different versions on different
systems:
https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-00
<https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-00>

One of the bigger ones out there is the Mastodon ecosystem, which uses
its own version of the Cavage draft:
https://docs.joinmastodon.org/spec/security/#http
<https://docs.joinmastodon.org/spec/security/#http>

As do financial profiles including FAPI, PSD2, and the Berlin Group’s
work. This is to say nothing of other efforts out there that have
invented or re-invented parts of this specification for their own purposes.


Given the number of current users cited - is it possible to get at least
one of those to document their approach and why it works for them, in a
form that we could include at least as an informational reference?

A *lot* of my concerns would be assuaged if we could see a worked
example of an application using this toolkit.

Harald