Re: [secdir] Secdir last call review of draft-ietf-httpbis-proxy-status-05

Mark Nottingham <mnot@mnot.net> Fri, 23 July 2021 01:59 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 E090E3A1738; Thu, 22 Jul 2021 18:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_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=n/lBEhA7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GG+opeMr
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 QaFoN0DuHanV; Thu, 22 Jul 2021 18:58:55 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941523A1732; Thu, 22 Jul 2021 18:58:54 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 281785C0131; Thu, 22 Jul 2021 21:58:53 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 22 Jul 2021 21:58:53 -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=O Q+bvOfLBl3QjjAUuBnt7V6B5onIQyQT9phQZifNpr4=; b=n/lBEhA7zKSqKjOUD Hy/Wq1uL2A9TqI1GHA4srstYlkt3p9p5L9kjpJTSHXl23Nq222a0SvVrhldnPTMt CXybjpDUVMeGVweP4BrOXIiMjDiv8vwz0fEjgIa6t0QsOQCwG70Z1fUZOABnhRYO /8Iji+0uiTb+d1peblB1xRa5vUADTk9EuLxIeXlugEHbWrlb+sdDA9RjH1hN9Cmz jd9zwx8GqgTiOR/G6F6pzwNBPk7fnz9/+vS7gye4Vqk1/HvqFkD8ViWibeOziQKJ wzYxGSIDtR2T/ghMdwbSGBCLRvWKUhVxL6IQ3/ZjMQmIHkpe0ePe0Km+028Wuo0M CnRTA==
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=OQ+bvOfLBl3QjjAUuBnt7V6B5onIQyQT9phQZifNp r4=; b=GG+opeMr1Xc6mPTpJh23+05qVCL0RCt8aNvCmXpPF7Nec4nLoymCr9EQ8 vwLm3fKMC4QJ3RhuumrxxzfpONKTeL9Q952Udi5wijAxncMrOHTTmLuQmDmcnlZb PfDc8bPPuDnblYTrsvCvWCi+bz4xcUxe1VnzWgZ9qL3lIuS0jwydqiLTqU4tDtwI D0A31znVobkUl6HGihnRPfsKe8pZotopQS2leZWHdXkTYJ9x+9ggCBBLC3TKtG9n dBu0Rqh9N5sCX4SXV2oYAIPE3dXmAdna0diie1sODNzVlIrwJHmWQyNld63DGMli LXvjpFtKBOidvxB+kQv7YKy/ydk2A==
X-ME-Sender: <xms:WiL6YKgU2gIJVXforpiDT9v8DoxyGAJjzIsnC0vzLUGWvTo4SNwD6w> <xme:WiL6YLDXPygbA9FTFXpO2JdWQZDSXSS239Z6tAskZUrULt65Lp6gIslOsm36U9-eC dyKShs4DMMWaRBz_w>
X-ME-Received: <xmr:WiL6YCFOl-w7V8g5C76o6sz7DIBfneD5pRfapOYc2xmYSKlUK0jVsEZvwLKLMtZYQlCkoTwc3qzCN_bW0317L7mddx9w0D3Y3X0XfpNGQXLjTAbXY7Umf2ex>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfeejgdeglecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepleffvdeuveffffekgefgffeugeehleekkeetjeelhfelkeevkeduieeivedvtefg necuffhomhgrihhnpehgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdr nhgvth
X-ME-Proxy: <xmx:WiL6YDRW7ZU75B9_dNVCEA_szMDJv0c28RxeCORO4kBwXCcAjClHsA> <xmx:WiL6YHwwtN0vQhxoVFrOKTz2uUiQk0AET1sWqUdl9neb7NUIX97uYA> <xmx:WiL6YB6pfgS9eQ4NJu8hZqGJr5rouK6UOHnWVreb5WVT-lKfZuV7Pw> <xmx:XSL6YCoxb73efG4-ptynsdNiwmu-d3uX84YtZtbK8TOwMK5-YNgOaQ>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 22 Jul 2021 21:58:49 -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: <162697854353.10606.9218891088339688790@ietfa.amsl.com>
Date: Fri, 23 Jul 2021 11:58:47 +1000
Cc: secdir@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <10B337AE-C4A8-4F94-8F78-C68ECC22E16F@mnot.net>
References: <162697854353.10606.9218891088339688790@ietfa.amsl.com>
To: Rich Salz <rsalz@akamai.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/-wiXhezoo5jBt6iyRQUVg391IU4>
Subject: Re: [secdir] Secdir last call review of draft-ietf-httpbis-proxy-status-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: Fri, 23 Jul 2021 01:59:01 -0000

Thanks for the review, Rich. I've created:
  https://github.com/httpwg/http-extensions/issues/1580


> On 23 Jul 2021, at 4:29 am, Rich Salz via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Rich Salz
> Review result: Has Nits
> 
> This is the SECDIR review of the draft, primarily for the benefit of the
> Security AD's.  All others can treat this as any other last-call comments.
> 
> It's ready, there are some nits/confusions/inconsistencies that should be
> cleared up.
> 
> While the draft says it is both for CDN like things and outgoing reverse
> proxies, it doesn't quite seem that way.  For example, Sec 2 the Proxy-Status
> HTTP field says the order is first closest to the origin, and last closest to
> the user-agent. Shouldn't it always be in the direction of travel?  The
> example, shows "FooProxy, ExampleCDN", but the explanation doesn't fit if there
> is an outbound proxy. Or maybe it's "FooProxy" is a proxy at the origin side? 
> Either way, I think there's an ambiguity there that needs to be cleaned up.
> 
> Implied, but should be stated, as that when the request arrives at the origin,
> any proxy-status headers should be removed before responding.
> 
> Sec 2.1.3 should maybe refer to the ALPN registry directly. All current values
> are US-ASCII, and that seems unlikely to change.  Saying UTF-8 seems
> contradictory since sf-string is ASCII-only.
> 
> Sec 2.1.4 talks about received status, which is "in the opposite direction"
> from 2.1.3  Perhaps split this up into "common" "sender" "receiver" types of
> status fields?
> 
> Sec 2.1.5 uses sf-string which doesn't allow utf8 localization or markers
> thereof.  should it?
> 
> Sec 2.2 says "[a] specification document is appreciated, but not required." 
> Then the Reference bullet item needs editing.  I prefer to make it spec
> required.
> 
> Sec 2.3.3 says "destination not found"  It should have a forward link to 2.3.6 
> Consider shuffling some of those error cases around so that they fall into
> things like "proxy failures" "infrastructure failures" "next hop did something
> bad"  And consider making three subsections for each class.
> 
> I think having both "connection_limit_reached" and "destination_ip_prohibited"
> is too fine a grain, but not worth arguing about. (shades of 451 I guess)
> 
> The TLS errors should have "alert number" as extra info.  (Not the
> alert-message as mentioned in 2.3.15)
> 
> I am confused by 2.3.18 and 2.3.8 or even 2.3.10; maybe some guidance on when
> to use each?
> 
> I think, again, splitting this section up is worthwhile.  Maybe add "http
> errors" "tls errors" -- i.e., what layer in the IETF protocol model broke. 
> That, or the traffic direction suggest above, might really help implementors.
> 
> 2.3.29 has no recommended http stauts code.
> 
> 2.4 says a specification is appreciated, but the registration form doesn't list
> one.  Similar to the comments above about Sec 2.2
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/