Re: [secdir] Secdir early review of draft-ietf-httpbis-message-signatures-05
Mark Nottingham <mnot@mnot.net> Sat, 31 July 2021 04:48 UTC
Return-Path: <mnot@mnot.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5023A12E8; Fri, 30 Jul 2021 21:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=x7yOud9I; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rL1pjlot
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8vwr4dMHbDA; Fri, 30 Jul 2021 21:48:21 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1C83A12E1; Fri, 30 Jul 2021 21:48:18 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BEC1E5C00B6; Sat, 31 Jul 2021 00:48:15 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 31 Jul 2021 00:48:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=4 gC3WAjzyUbe19w+vmFaHUZY67vINE7P2MkM3tisSUE=; b=x7yOud9INzpfqf1wv S5tJeVcNwCTYZ5pRU2PxdACjVUK2LLYDrGvbMc7nbSgY4HbRgs0Zrkx3Ubc1V6U2 0UlIdLQXKKgiJnpj9+dCKdH7EdwJ4wZ5gpZjCESOpADDC1n7yp0lLA3DF6alXpnl ds1BpN3WYTiLU1eaXlwr3KgrYD0nmzs1bIxHkCM7C972EpE9DLJShbSxlJx9/K1M 7EBZOh3LYud9lhwCXkcHOnSSOJKBf8WTzk4X2mhgO9IcIR52VL3gsOn2cYCsv1Ou 7yrK4NueuLd8uKC6F+wlX3JoENnuHbsVOqoO6mvAYNI4AHzHZrz2TBxgRYzqfe7z dNx7w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=4gC3WAjzyUbe19w+vmFaHUZY67vINE7P2MkM3tisS UE=; b=rL1pjlotNZg7uiHkDeypZI91oBxMTsoxN1HkckiHnlZ4aPlC+I+fUMpm7 zJLosODzic/syiFhmrOOexb752pKToLmV1L0D5tLYDEZrw3nZxwYy3ufd9FQWj78 ja63EP0Xnaz4DWRFp/7rUoO7y2ULioA9BqLQ8NV/Z+mLvZqW4yGf5Q5C/yhgjicR O2RsTqOwMref2l0RkxTfGop51G3ldCVgPNga36HI4vYfDbkaQpPFnOHPwqc/51KA mvllizn8ucH3tB92qLDwWZDYODHl5hd7JjxiRDVjt4cEpxobbFpV2kfmC+9Ze7OK vS6L7730EvT7Cv7MtOekH0cVjPTEg==
X-ME-Sender: <xms:DdYEYWdHYgvyA9-fJRdP8wcrrXBsuGrnHOrh0eopkZctVkgxoGCEZA> <xme:DdYEYQMN6ZHHHoPyEZhrPupS0hdS-YH4ik0gLcVD7x0Lsk_7qow5UGKmUvSqYWUBH YlfLWthmfBqqjfRhw>
X-ME-Received: <xmr:DdYEYXiUDxI_SBzar-gJwyUxcp6q-gRjjUFxV3QdETxKJ4nLAq9rAz-r5h_eorox1OzqEmE0pqG1bV8PUri9XU9pG02d3gEc1G_gRwZNV6LkwFKg2rp5XnA4>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheeigdekhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:DdYEYT9zieMvUHu4lOJNFY3l9kc47p6dayOXrRKAqUweu8fUZQjlxA> <xmx:DdYEYStwaHuIrGiSbskBpTuynvx1QJS5e7kt6lVEgmcUo-rNiwJ87w> <xmx:DdYEYaEAyZL-WEN9kqAQZkr8Eh5WoXfo5TOA1v3WwkyoZojS1nF70Q> <xmx:D9YEYUWwUTKWWfVlMArxPC7HKqP0AVHJKvpH57gThHbNVtA-F4ZLmQ>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 31 Jul 2021 00:48:12 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <162768539570.14788.6438448354422571640@ietfa.amsl.com>
Date: Sat, 31 Jul 2021 14:48:10 +1000
Cc: secdir@ietf.org, draft-ietf-httpbis-message-signatures.all@ietf.org, ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FBC8C4D2-86FE-49D8-909F-8FD3642614F1@mnot.net>
References: <162768539570.14788.6438448354422571640@ietfa.amsl.com>
To: Daniel Migault <daniel.migault@ericsson.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/YiykyWhRQmjo_zyI-VwUMZVdhtQ>
Subject: Re: [secdir] Secdir early review of draft-ietf-httpbis-message-signatures-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Jul 2021 04:48:27 -0000
Thanks for the review, Daniel - much appreciated. > On 31 Jul 2021, at 8:49 am, Daniel Migault via Datatracker <noreply@ietf.org> wrote: > > Reviewer: Daniel Migault > Review result: Has Issues > > Hi, > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These comments > were written primarily for the benefit of the security area directors. Document > editors and WG chairs should treat these comments just like any other last call > comments. > > The main issue I have is the absence of security considerations ;-), but > otherwise the text appears to me quite clear. I will review the document once > the security consideration is completed. > > I do not see the document mentioning any sort of negotiation which limits the > scope of possible downgrade attacks or the ability from one party to > "orchestrate" in some ways, what the other party. In other words, if I did not > missed anything the signature is a local policy. This typically means that a > client may sign while responses may not be signed. Section 1.5 defines what > needs to be agreed between multiple parties, but does not provides details how > this could be achieved. > > Some very minor editorial comments. > section 1.4 > <mglt> > The qualified term "digital > signature" refers specifically to the output of an asymmetric > cryptographic signing operation. > > May be that would be clearer to define digital signature before mentioning > "signature" is used for both digital signature and Keyed MAC. </mglt> > > section 1.5 > * The set of content identifiers (Section 2) that are expected and > required. > <mglt> > I suppose that the content are security related, but it is unclear at least to > me at this stage if the content have any kind of limitation. Typically, if a > party is able require an specific header that leaks private information, that > may be an issue. I think the text might be able to clarify this. > > Though I expected it to be detailed later and "expected" security related > information is always suspicious of ending in a best effort situation where > security is optional. These are simply what come to my mind when reading these > lines. There is no necessary some actions to be taken if you believe that is > not necessary. </mglt> > > section 2.4 > <mglt> > If covered content references an identifier that cannot be resolved > to a value in the message, the implementation MUST produce an error. > Such situations are included but not limited to: > > * The signer or verifier does not understand the content identifier. > > * The identifier identifies a header field that is not present in > the message or whose value is malformed. > > If the value is malformed, it may indicate that the value is interpreted > previously the integrity has been checked. I am sure this is not what the text > is meaning, but this is how I read it, so I believe that some clarification may > be needed. </mglt> > > > -- Mark Nottingham https://www.mnot.net/
- [secdir] Secdir early review of draft-ietf-httpbi… Daniel Migault via Datatracker
- Re: [secdir] Secdir early review of draft-ietf-ht… Mark Nottingham
- Re: [secdir] Secdir early review of draft-ietf-ht… Justin Richer