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

[Harald Alvestrand <[e-mail]>]

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