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

Harald Alvestrand <harald@alvestrand.no> Tue, 07 March 2023 19:45 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28CBC151B0B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Mar 2023 11:45:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level:
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdxHsfrV3DJz for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Mar 2023 11:45:45 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47E3C151B0A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 7 Mar 2023 11:45:45 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1pZdDh-008uwt-C8 for ietf-http-wg-dist@listhub.w3.org; Tue, 07 Mar 2023 19:43:33 +0000
Resent-Date: Tue, 07 Mar 2023 19:43:33 +0000
Resent-Message-Id: <E1pZdDh-008uwt-C8@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <harald@alvestrand.no>) id 1pZdDf-008uw1-7r for ietf-http-wg@listhub.w3.org; Tue, 07 Mar 2023 19:43:31 +0000
Received: from smtp.alvestrand.no ([65.21.189.24]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <harald@alvestrand.no>) id 1pZdDc-007CkJ-2K for ietf-http-wg@w3.org; Tue, 07 Mar 2023 19:43:31 +0000
Received: from [192.168.3.110] (unknown [185.71.208.122]) by smtp.alvestrand.no (Postfix) with ESMTPSA id 40A8848B22; Tue, 7 Mar 2023 20:43:17 +0100 (CET)
Message-ID: <fc560173-d90f-672b-78ac-2d76c660e874@alvestrand.no>
Date: Tue, 07 Mar 2023 20:43:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1
Content-Language: en-US
To: Justin Richer <jricher@mit.edu>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
References: <167814585078.47895.4452057535068050885@ietfa.amsl.com> <269E25AB-0D57-4F5A-BBDD-D04060C84E9E@mit.edu>
From: Harald Alvestrand <harald@alvestrand.no>
In-Reply-To: <269E25AB-0D57-4F5A-BBDD-D04060C84E9E@mit.edu>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=65.21.189.24; envelope-from=harald@alvestrand.no; helo=smtp.alvestrand.no
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1pZdDc-007CkJ-2K ae1e52df16447cc3cc4158f7c6eda9cf
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Artart last call review of draft-ietf-httpbis-message-signatures-16
Archived-At: <https://www.w3.org/mid/fc560173-d90f-672b-78ac-2d76c660e874@alvestrand.no>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/50817
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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