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/