Re: Roman Danyliw's No Objection on draft-ietf-httpbis-digest-headers-12: (with COMMENT)
Roberto Polli <robipolli@gmail.com> Wed, 24 May 2023 08: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 56B09C151B15 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 May 2023 01:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.748
X-Spam-Level:
X-Spam-Status: No, score=-7.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 C6Fji3Y856YQ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 May 2023 01:45:17 -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 824DCC151B0A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 May 2023 01:45:17 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1q1k7F-002RHZ-Q1 for ietf-http-wg-dist@listhub.w3.org; Wed, 24 May 2023 08:45:05 +0000
Resent-Date: Wed, 24 May 2023 08:45:05 +0000
Resent-Message-Id: <E1q1k7F-002RHZ-Q1@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 <robipolli@gmail.com>) id 1q1k7D-002RGF-OL for ietf-http-wg@listhub.w3.org; Wed, 24 May 2023 08:45:03 +0000
Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <robipolli@gmail.com>) id 1q1k7C-008DHp-3u for ietf-http-wg@w3.org; Wed, 24 May 2023 08:45:03 +0000
Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-4ec8eca56cfso618315e87.0 for <ietf-http-wg@w3.org>; Wed, 24 May 2023 01:45:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684917897; x=1687509897; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LZqsCOltO3FLBOKoUbv922yHGOUUf3OE+v8ZLDY2Xaw=; b=slg4SRDOf8rbOfAdWhInt8mL4McqVi3Pw7ZOl526eeKuVqSA29wNRIHXBj/S6N0joi 8OC7+/qSD+QMqBIHkAaD7TkjJouoKOvi0HnWTAYMEZy0VINYzoJ5Yv1RNWQAIL2jN1Z/ /ErrcLmHNwzHSvOoGncqxHuBOaXyx/zGJ8bWTh3G2OSYaPxfSFjfF2dqAn2aeDs/zdto 9f+o5v3uLdvqxIgv8Sql8ruC94NylOBf7SQJocYazWsjUaEwJlDN62kJaYvtl16albvx 12MdctoOhC+IXj7QQU9mX9exssQbDtX1JLMXrxEFdH2bN/l61Gy6m6kq3ZsF6qEIixNG Z2+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684917897; x=1687509897; h=content-transfer-encoding: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=LZqsCOltO3FLBOKoUbv922yHGOUUf3OE+v8ZLDY2Xaw=; b=b2icHOCPvBDO/aiLan0fVGhOvFJB/m2YXPsp0Iikx0UfX0p2v7i7c7YdVTxKJ0WAMI e+0fAe1z5m2Lw1nqHyGovaoF4HWqI84IvjlMW/hQasrdSREwHuEmyzVny+DEAOwef3oC 75NmaKAPTPhmN3l/aCmUth3J+Q3dHBFf1Rh1G9HbFcdGOPsno3ysBmzyRR3DQgT2icm+ gXAofDrEc+/vgf26Dkpkao1u0FD6rPDFJjx9ozQX49die+QOEWH+NqCwhdPLU4QY/55i nfTxTneoxcWOup9K4ki2y9KYhsViPoL1oX4jyKzUT+Xz89SuUy/vPAsNvrvqWznWd4+h 8XPA==
X-Gm-Message-State: AC+VfDzHfvBBHdFAX0jUDPgXSg5fXmbi11BDumiWh+HZr3RgC5PxUW9F Lkb3N3WPjm5yzQFfcyPkOlI3NZBiZWJkvr1BbTc=
X-Google-Smtp-Source: ACHHUZ5Iii9O9W7sIlZUnE3JlGGPF8kz/3CAcw7xOqYlRc2WkMM/Zi73Q9LKByWcwpXgHmS9sT5m68zYjtY2WdBzXIk=
X-Received: by 2002:a2e:9c0e:0:b0:2af:3f7:53fe with SMTP id s14-20020a2e9c0e000000b002af03f753femr5270028lji.50.1684917897132; Wed, 24 May 2023 01:44:57 -0700 (PDT)
MIME-Version: 1.0
References: <168486410440.60374.9215584822726745937@ietfa.amsl.com> <CALGR9oYrS_H9Qtn6ZvvBCUkK+CVsYMT1AUWM+LOiMbCNibA52g@mail.gmail.com>
In-Reply-To: <CALGR9oYrS_H9Qtn6ZvvBCUkK+CVsYMT1AUWM+LOiMbCNibA52g@mail.gmail.com>
From: Roberto Polli <robipolli@gmail.com>
Date: Wed, 24 May 2023 10:44:45 +0200
Message-ID: <CAP9qbHWvTL1oT+TXfhBfRaAHf3f+Nm9-3zdWs2XEaDobZiCmYQ@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>, draft-ietf-httpbis-digest-headers@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=robipolli@gmail.com; helo=mail-lf1-x131.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=robipolli@gmail.com domain=gmail.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-6.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1q1k7C-008DHp-3u 1134aa9eb96fedaa298c6c8f2d0828e7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Roman Danyliw's No Objection on draft-ietf-httpbis-digest-headers-12: (with COMMENT)
Archived-At: <https://www.w3.org/mid/CAP9qbHWvTL1oT+TXfhBfRaAHf3f+Nm9-3zdWs2XEaDobZiCmYQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51072
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>
Dear all, Thanks for the review. Responses in line: On Tue, 23 May 2023 at 21:50, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > On Tue, May 23, 2023 at 6:48 PM Roman Danyliw via Datatracker <noreply@ietf.org> wrote: >> >> Roman Danyliw has entered the following ballot position for >> draft-ietf-httpbis-digest-headers-12: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thank you to Peter Yee for the SECDIR review. >> >> ** Section 2. Using multiple digests in a single Content-Digest is supported. >> There is also guidance that “a recipient MAY ignore any or all of the digests”. >> I read that text as “if presented multiple digests, a recipient can choose to >> look at only one or some subset of the digests.” Is that accurate? Is there >> standardized behavior for when a recipient validates/checks both digests and >> only one is valid? > > > Background caveats: we are building on top of the way that RFC3230 did things, which was quite relaxed about stating what the receiver requirements are. In this draft, validation failures are primarily an implementation concern. In other words, the decision about what to do with a validation failure are the concern of the application using this HTTP capability. There's an interplay with general-purpose HTTP feature discovery too, which is not really great and we can't solve. > > In the case you highlight, I interpret that as a receiver that does want to check digest, and it receives more than one value that it supports the algoithm of. Since we don't really standardise what to do when even a single digest validation fails, I'm not sure what we can really say, from a standards perspective, if one succeeds or one fails. > > Spamming the receiver with digest values is a possible attack that we give some consideration in Section 6.7. So I'm cautious about making anything appear as if a receiver has to cross verify the integrity digests. Agree with Lucas. >> ** Section 4. >> * key conveys the hashing algorithm (see Section 5); >> >> Shouldn’t this read as “hashing algorithm(s)” as it is possible to send more >> than one in the field? > > > The full text is > > > Want-Content-Digest and Want-Repr-Digest are of type Dictionary where each: > > > > * key conveys the hashing algorithm (see Section 5); > > > Just to establish we're on the same page. A Structured Fields Dictionary is a set of individual items that have a key. A key indicates a single algorithm. If the sender wants to indicate multiple algorithms, it sends multiple keys. > > If we didn't have the "each" qualifier on the preceding line, I'd agree that "keys" could be used. But I find the current presentation clearer from an editorial perspective. Agree with Lucas. >> ** Section 4. >> * value is an Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) that >> conveys an ascending, relative, weighted preference. It must be >> in the range 0 to 10 inclusive. 1 is the least preferred, 10 is >> the most preferred, and a value of 0 means "not acceptable". >> >> -- Can multiple algorithms share the same preference value? For example, could >> multiple algorithms be labeled “not acceptable”? >> >> -- If yes, would their ordering determine preference? > > > Yes they can have the same value. > > We had a issue for this and concluded to not say anything specific about preference, which aligns with existing HTTP semantics. See https://github.com/httpwg/http-extensions/issues/2389. Agree with Lucas. >> ** Section 6.1. Recommend adding cautionary language about the capabilities of >> an adversary like those stated in Peter’s SECDIR review. Perhaps: >> >> OLD >> Integrity fields are not intended to be a general protection against >> malicious tampering with HTTP messages. This can be achieved by >> combining it with other approaches such as transport-layer security >> or digital signatures (for example, HTTP Message Signatures >> [SIGNATURES]). >> >> NEW >> Integrity fields are not intended to be a general protection against malicious >> tampering with HTTP messages. In the absence of additional security mechanisms, >> an on-path, malicious actor can remove or recalculate and substitute a digest >> value. This attack can be mitigated by combining mechanisms described in this >> document with other approaches such as transport-layer security or digital >> signatures (for example, HTTP Message Signatures [SIGNATURES]). Thanks for this suggestion! I filed a PR which includes it: - https://github.com/httpwg/http-extensions/pull/2554/files#diff-de34152d297a9eb29b85b24962949ba2e309478a5c32e1d94fd4c3ee27b4584dR522 Thanks again and have a nice day, R.
- Roman Danyliw's No Objection on draft-ietf-httpbi… Roman Danyliw via Datatracker
- Re: Roman Danyliw's No Objection on draft-ietf-ht… Lucas Pardue
- Re: Roman Danyliw's No Objection on draft-ietf-ht… Roberto Polli
- Re: Roman Danyliw's No Objection on draft-ietf-ht… Lucas Pardue