From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org Sat Mar 16 23:01:11 2024 Return-Path: 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 672AEC15108B for ; Sat, 16 Mar 2024 23:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.858 X-Spam-Level: X-Spam-Status: No, score=-7.858 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="MCsWw5lF"; dkim=pass (2048-bit key) header.d=w3.org header.b="caVvKZCf"; dkim=pass (2048-bit key) header.d=gmail.com header.b="kI5rZacr" 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 l7O7clDFg8Sf for ; Sat, 16 Mar 2024 23:01:10 -0700 (PDT) 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 060CAC151075 for ; Sat, 16 Mar 2024 23:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:Cc:To:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=BBZb54/hty7ihbU+/1e64J+Ign+r46saK6Z64jbOwpM=; b=MCsWw5lFfI2FibmNoGxZm8qP54 5yizhsaTD/7wuKPK+F3FoIwi/o5zX54PgLcPW+3TpC9JDzQadGZT0pDuEN3fYcfTyjUQD8CvZ01Sj HSPd7lHM/KcJZ0jHdf3WB67XjabY9wSH094Ty8Ml7xilINOzLr4ljcH3cHTtDsiWSrs5P7SrToaNU JlUfU4u7zf64Sbjq+EMf0lKMNDkJnfDCYJ/qrju8hWV6YWBi+O8OT3WDDjTvcTv0Sdba5C84rS6pi /wIytQoqO742Y9CK6rvIgr4WzVW5wuLhVsLTMIZt0X3Wp1/AxsWs0vU/eC+8hnSBaGwC2RU5DAGEK 25WLlHww==; Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1rljXR-00E7t2-Gv for ietf-http-wg-dist@listhub.w3.org; Sun, 17 Mar 2024 05:58:29 +0000 Resent-Date: Sun, 17 Mar 2024 05:58:29 +0000 Resent-Message-Id: Received: from pan.w3.org ([3.222.182.102]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rljXO-00E7s1-PA for ietf-http-wg@listhub.w3.org; Sun, 17 Mar 2024 05:58:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=BBZb54/hty7ihbU+/1e64J+Ign+r46saK6Z64jbOwpM=; t=1710655106; x=1711519106; b=caVvKZCfUWyrJV06nlp1fKMyWqybmZckLiQ0cn1L7YAgQPQZ+mz6zpwyqfZVPioD8hYV8LKQpKW rJLFpmr459HrHqwJ30UDEW6ruJWH9JkzLSR8SZa37rUcON+g7er7HorKTcvLOQsiX2VqNb3SjnuJ+ 8prj8DCV0RKtlTUahsefUKvFHCCwxl3XztjVG1d/9baN8ZZtOaK4TXpXealF6Bgeq7AuatkD0aNpw cO7L2BBiDo6hROrZjgFifPPOZAnnXnzk8JyOCSFFRFhkpW9V14AN6X0x4ZBLMpkFBORqkQ7JYNY/a DDuAxrQGJ/vcTeyl3VTXmqqjzANMelq1rMpw==; Received-SPF: pass (pan.w3.org: domain of gmail.com designates 2a00:1450:4864:20::633 as permitted sender) client-ip=2a00:1450:4864:20::633; envelope-from=dschinazi.ietf@gmail.com; helo=mail-ej1-x633.google.com; Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by pan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1rljXN-00CFr2-30 for ietf-http-wg@w3.org; Sun, 17 Mar 2024 05:58:26 +0000 Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a46ba1a05e0so3732666b.3 for ; Sat, 16 Mar 2024 22:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710655102; x=1711259902; darn=w3.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BBZb54/hty7ihbU+/1e64J+Ign+r46saK6Z64jbOwpM=; b=kI5rZacrqDk3mfkVuLckBjz+YG+1vdgYcPjhQtH5M+2gv02yiVcQnuHXHurAgeUHGg slVy/gITHCFgiLnRRb39to+S5jNcqTRy+z4x3nzbX/jmakxGrJnFxic1SqEdDyLx2prN CF6VHME9shvI0BEoTMaVJkHrJsqCXBgbOb5EMolCC4im7eIVaO+ifaCwl0N0f7QeIuZ8 7ypGrlXpRFXfULJDAKKAP4yDNlY8/VXr1+D9Un1f50AvSy/3rHwVW9B2/UuGrrv2r9TQ juaIvBIo7qTcx+Qf6ZZvfYr5nPYEBl8VNRYYO7/nTxlwChC6FsKneBuvCS3ytCBMlCiD xpeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710655102; x=1711259902; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BBZb54/hty7ihbU+/1e64J+Ign+r46saK6Z64jbOwpM=; b=p1Cy8H2e0v9zikhR1w1sC0XNi6XOG60PjXGuBLmXK2DlrU7dn8x1Vvf5Erpl5YZG0I 3RiqHgmlIQXrOLFweTSRQ60TZK+vmo2idNr+VFQQT+pwjNfZnml42ROUQttp3RK5B9wF g+5AMzCxcVSaoT0RcCM/8PP1wfeYqMfxTyf+ZzVMijXJ6jZC5QdPqm0ImSQt2cBxLH5q 6b2lx0nD8+nsh0punMgRyDT9vC3TqHrsq2fKfJabza+zcll9eBPnl4y32k9TzclKcQyM hQ5ZfFrby404Tws0tjALeyai7DWi7Sjr2Q6DWii2WI17oJZ/pqRQ56eyikYbuKlw20iB Fn+Q== X-Gm-Message-State: AOJu0YypfBSGqwOVZzLQ/Wq4xXkusEZaBM35yl34Em8DHw3w909Jvhhk 4pfgNaMy2Jqk75HypehZM+T5zezIcw3ZB8NRGi9vb3PLALBB6e6aiWy58oVWvTMJRNBjuaSEgXp F7WMj2A84my+XXLCsnIKm8B9993gCwNgEvaMORg== X-Google-Smtp-Source: AGHT+IEj0n+W6msmSkPuIcY86HTz8/v/o7PvxRIFhOazf5gVapylt/oQenU/mUojXOI6/YUjnDhteg62M3RfRMW3sJE= X-Received: by 2002:a17:906:684a:b0:a46:a194:bc78 with SMTP id a10-20020a170906684a00b00a46a194bc78mr1867602ejs.49.1710655101805; Sat, 16 Mar 2024 22:58:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Sat, 16 Mar 2024 22:58:10 -0700 Message-ID: To: Justin Richer Cc: HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000ad28c40613d4ed9b" X-W3C-Hub-DKIM-Status: validation passed: (address=dschinazi.ietf@gmail.com domain=gmail.com), signature is good X-W3C-Hub-Spam-Status: No, score=-9.1 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, DMARC_PASS=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1 X-W3C-Scan-Sig: pan.w3.org 1rljXN-00CFr2-30 9f217c75dc723fe7e8004a6bf14d3ad9 X-Original-To: ietf-http-wg@w3.org Subject: Re: Signature Authentication Scheme Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/51886 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --000000000000ad28c40613d4ed9b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, thanks for your comments. Responses inline. David On Sat, Mar 16, 2024 at 4:59=E2=80=AFAM Justin Richer wro= te: > I talked with David Oliver this morning at the hackathon, and I would lik= e > to raise some concerns about the "Signature Authentication Scheme" draft > (draft-ietf-httpbis-unprompted-auth) that mostly revolve around the > positioning of the draft in the larger ecosystem. > > As many of you know, we recently published HTTP Message Signatures as > RFC9421 (huge thanks to the working group and everyone that helped out!). > That draft was over four years of work here in HTTP and many more years > longer than that floating around in various incompatible I-D=E2=80=99s. I= t=E2=80=99s in > this context that I am providing this feedback. > > 1: The title of the draft and use of "HTTP Signature" > > The draft draft-ietf-httpbis-unprompted-auth has no relationship > whatsoever to RFC9421, in spite of a very similar name. The mechanism > in draft-ietf-httpbis-unprompted-auth is not about signing the HTTP messa= ge > itself (apart from the scheme/host/port exported form TLS in section 4.1)= , > but about presenting a signature value to the server in the request. This > signature is intended to be bound to the target URI of the request, > regardless of what the request itself is. Furthermore, the method is > restrained to a single hope as it is based on binding to TLS level key > material (see section 8). Additionally, the draft currently defines a > single algorithm for use, without cryptographic agility. > > This list is not meant a judgement on these choices, but rather to > contrast with the choices made in RFC9421, which targets arbitrary portio= ns > of the message, does not constrain key material to the TLS connection, ca= n > be used through intermediaries, and provides a robust cryptographic agili= ty > and extension mechanism. > > At the very least, this draft needs to clearly differentiate itself from > RFC9421 in both the introduction and relevant portions of the text. Even > better, in my personal opinion, this draft should be called something > different. It :uses: signatures to accomplish a specific goal similar to > HOBA, but it does not provide a signature mechanism for HTTP. > For what it's worth, the draft isn't "HTTP Signature Authentication", it's "The Signature HTTP Authentication Scheme". That said, if you feel there's confusion then this can definitely be approved. I'm not opposed to changing the name if we find something that makes sense. How would you feel about "A Signature-Based HTTP Authentication Scheme" or "HTTP Authentication Using Signatures"? Though this might be moot if we rename the scheme - see below. 2: The use of the "Signature" authentication scheme > > In draft-cavage-http-signatures, which was one of the precursor inputs to > RFC9421, there is a "Signature" authentication scheme defined in Section = 3. > In RFC9421, we deliberately removed this feature, as the goal of RFC9421 > was to specify a mechanism for signing requests and responses and not for > presenting those signatures as authentication or authorization, which wou= ld > be higher-level protocols. > > This would ostensibly mean that the "Signature" authentication scheme is > up for grabs, but the truth of the situation is that the Cavage draft saw > wide adoption of its various versions long before the HTTP WG picked up > work on what became RFC9421. This means that there are existing ecosystem= s > depending on their own definition of a "Signature" authentication scheme. > When this draft is deployed, that collision is going to be a painful one. > Furthermore, a naive developer would see this draft and grab a Cavage > library to try and implement it. > > I believe that this draft should use a different scheme, both to avoid > conflict with Cavage implementations and also in concert with the reasons > for naming choices in (1). > Thanks for flagging this, I was not aware of this prior use at all. Given that the current implementations haven't yet widely deployed, it's not too late to change the scheme. One potential option could be to lean into the prior name of the draft and use the scheme "UnpromptedSignature". Then the title of the document could be "The UnpromptedSignature HTTP Authentication Scheme", which would also be less confusing. Thoughts on that scheme name? Other proposals for different names? 3: The field format and syntax > > This draft defines its own field format and parameter encoding, based on > base64url. As the values in question are binaries with labels, this is ri= pe > for using structured fields. Is there a compelling reason not to? The > syntax is ALMOST there as it stands today, so implementations wouldn=E2= =80=99t need > to change much in practice =E2=80=94 but new implementations could rely o= n > structured fields to provide parsing and serialization in a less error > prone way. > The compelling reason is that HTTP authentication parameters have a restricted set of characters that don't allow the unescaped colons required by sf-binary. A previous version of the draft wrapped this with double-quotes to make it both a structured field and a valid authentication parameter (it looked like ":foobar:"), but the WG decided to not do that and instead remove structured fields. 4: Compatibility with RFC9421 > > And finally, this draft invents its own signature base string generator > and signature calculation method separate from RFC9421. It is neither > necessary nor expected for all new drafts to follow the methods in RFC942= 1, > but I believe it would be worth at least exploring if the corresponding > parts of RFC9421 could be used in here. I have a feeling that the answer = is > "not really", or more likely "we could but it makes this specific use cas= e > way more complicated than it=E2=80=99s worth", and that is a reasonable o= utcome =E2=80=94 > but I=E2=80=99d like to see that this work has at least been considered. > Thanks for the suggestion. I had reviewed the draft that became RFC 9421 back in the day, and I just looked through the relevant parts again. I don't think it makes sense to reuse it here. The focus then was on normalizing semantics that can be encoded multiple ways, and that's not a useful feature here. While there's often value in reusing existing tools, none of the four implementations of draft-ietf-httpbis-unprompted-auth have an implementation of RFC 9421, so we'd be adding complexity instead of leveraging synergy. --000000000000ad28c40613d4ed9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin, thanks for your=C2=A0comments.= Responses inline.
David

On Sat, Mar 16, 2024 at 4:59=E2=80=AFAM J= ustin Richer <jrich= er@mit.edu> wrote:
I talked with David Oliver this morning at the hackathon, and I would like = to raise some concerns about the "Signature Authentication Scheme"= ; draft (draft-ietf-httpbis-unprompted-auth) that mostly revolve around the= positioning of the draft in the larger ecosystem.

As many of you know, we recently published HTTP Message Signatures as = RFC9421 (huge thanks to the working group and everyone that helped out!). T= hat draft was over four years of work here in HTTP and many more years long= er than that floating around in various incompatible I-D=E2=80=99s. It=E2=80=99s in this context that I am= providing this feedback.

1: The title of the draft and use of "HTTP Signature"

The draft draft-ietf-httpbis-unprompted-auth has no relationship whats= oever to RFC9421, in spite of a very similar name. The mechanism in=C2=A0dr= aft-ietf-httpbis-unprompted-auth is not about signing the HTTP message itse= lf (apart from the scheme/host/port exported form TLS in section 4.1), but about presenting a signature value to the se= rver in the request. This signature is intended to be bound to the target U= RI of the request, regardless of what the request itself is. Furthermore, t= he method is restrained to a single hope as it is based on binding to TLS level key material (see section 8).= =C2=A0 Additionally, the draft currently defines a single algorithm for use= , without cryptographic agility.

This list is not meant a judgement on these choices, but rather to con= trast with the choices made in RFC9421, which targets arbitrary portions of= the message, does not constrain key material to the TLS connection, can be= used through intermediaries, and provides a robust cryptographic agility and extension mechanism.

At the very least, this draft needs to clearly differentiate itself fr= om RFC9421 in both the introduction and relevant portions of the text. Even= better, in my personal opinion, this draft should be called something diff= erent. It :uses: signatures to accomplish a specific goal similar to HOBA, but it does not provide a signature mecha= nism for HTTP.

For what it'= s worth, the draft isn't "HTTP Signature Authentication", it&= #39;s "The Signature HTTP Authentication Scheme". That said, if y= ou feel there's confusion then this can definitely be approved. I'm= not opposed to changing the name if we find something that makes sense. Ho= w would you feel about "A Signature-Based HTTP Authentication Scheme&q= uot; or "HTTP Authentication Using Signatures"? Though this might= be moot if we rename the scheme - see below.

2: The use of the "Signature" authentication scheme

In draft-cavage-http-signatures, which was one of the precursor inputs= to RFC9421, there is a "Signature" authentication scheme defined= in Section 3. In RFC9421, we deliberately removed this feature, as the goa= l of RFC9421 was to specify a mechanism for signing requests and responses and not for presenting those signatures as = authentication or authorization, which would be higher-level protocols.

This would ostensibly mean that the "Signature" authenticati= on scheme is up for grabs, but the truth of the situation is that the Cavag= e draft saw wide adoption of its various versions long before the HTTP WG p= icked up work on what became RFC9421. This means that there are existing ecosystems depending on their own definition= of a "Signature" authentication scheme. When this draft is deplo= yed, that collision is going to be a painful one. Furthermore, a naive deve= loper would see this draft and grab a Cavage library to try and implement it.

I believe that this draft should use a different scheme, both to avoid= conflict with Cavage implementations and also in concert with the reasons = for naming choices in (1).

Than= ks for flagging this, I was not aware of this prior use at all. Given that = the current implementations haven't yet widely deployed, it's not t= oo late to change the scheme. One potential option could be to lean into th= e prior name of the draft and use the scheme "UnpromptedSignature"= ;. Then the title of the document could be "The UnpromptedSignature HT= TP Authentication Scheme", which would also be less confusing.

Thoughts on that scheme name? Other proposals for differe= nt names?

3: The field format and syntax

This draft defines its own field format and parameter encoding, based = on base64url. As the values in question are binaries with labels, this is r= ipe for using structured fields. Is there a compelling reason not to? The s= yntax is ALMOST there as it stands today, so implementations wouldn=E2=80=99t need to change much in practice= =E2=80=94 but new implementations could rely on structured fields to provi= de parsing and serialization in a less error prone way.

The compelling reason is that HTTP authentication = parameters have a restricted set of characters that don't allow the une= scaped colons required by sf-binary. A previous version of the draft wrappe= d this with double-quotes to make it both a structured field and a valid au= thentication parameter (it looked like ":foobar:"), but the WG de= cided to not do that and instead remove structured fields.

4: Compatibility with RFC9421

And finally, this draft invents its own signature base string generato= r and signature calculation method separate from RFC9421. It is neither nec= essary nor expected for all new drafts to follow the methods in RFC9421, bu= t I believe it would be worth at least exploring if the corresponding parts of RFC9421 could be used in her= e. I have a feeling that the answer is "not really", or more like= ly "we could but it makes this specific use case way more complicated = than it=E2=80=99s worth", and that is a reasonable outcome =E2=80=94 but I=E2=80=99d like to see that this work has at least been con= sidered.

Thanks for the suggest= ion. I had reviewed the draft that became RFC 9421 back in the day, and I j= ust looked through the relevant parts again. I don't think it makes sen= se to reuse it here. The focus then was on normalizing semantics that can b= e encoded multiple ways, and that's not a useful feature=C2=A0here. Whi= le there's often value in reusing existing tools, none of the four impl= ementations of=C2=A0draft-ietf-httpbis-unprompted-auth have an implementati= on of RFC 9421, so we'd be adding complexity instead of leveraging syne= rgy.
--000000000000ad28c40613d4ed9b--