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

It sounds reasonable to me to expand the history sections to mention this kind of thing. I think it's a fine line though, because the security analysis would need to be specific to this document - if you built on sigv4 then you would want to re- assess against this document in your new system, even though the core approach is the same.

I proposed a binding to OAuth access tokens for the work but the OAuth wg has not picked it up as an item yet: https://datatracker.ietf.org/doc/html/draft-richer-oauth-httpsig

We appreciate your input and review comments.
________________________________
From: Harald Alvestrand <harald@alvestrand.no>
Sent: Thursday, March 30, 2023 2:15 AM
To: Backman, Annabelle <richanna@amazon.com>
Cc: Justin Richer <jricher@mit.edu>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Artart last call review of draft-ietf-httpbis-message-signatures-16


Thanks for the additional information! (and apologies for being slow in responding!)

So from this reviewer's viewpoint, the draft would be a much better candidate for the standards track if it included a section on precedents and their usages, something like:

History
====

This specification was inspired by the AWS "SigV4" signature mechanism, which is used in systems like AWS Identity and AWS Security Token Service.

When building a complete security system based on this toolkit, it is recommended to study those existing systems and their security considerations in order to offer a service that achieves the security goals of the system.

---------------

(Of course a spec that showed how to plug this mechanism into OAuth2, and discussing the security properties of that solution, would also satisfy my concern. The big issue I have is that people may use this framework without having performed appropriate security analysis, and thus build insecure systems.)

Harald


On 3/15/23 13:46, Backman, Annabelle wrote:
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 <harald@alvestrand.no<mailto:harald@alvestrand.no>> 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><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><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