Re: [secdir] SECDIR review of draft-ietf-httpbis-cdn-loop-01

Mark Nottingham <> Sun, 16 December 2018 23:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B4C61310CF; Sun, 16 Dec 2018 15:56:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=mdjtYPTq; dkim=pass (2048-bit key) header.b=sUyuXHzS
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IoJJr7JwtgAD; Sun, 16 Dec 2018 15:56:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 576A51310C6; Sun, 16 Dec 2018 15:56:14 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 76ABF11B9; Sun, 16 Dec 2018 18:56:13 -0500 (EST)
Received: from mailfrontend1 ([]) by compute3.internal (MEProxy); Sun, 16 Dec 2018 18:56:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=x mMzL0kZXz9mdsxte/GdctBJjqu03J9Rydr6J7RHV7k=; b=mdjtYPTqE6mJMjPsc lCTCi8NU6ml056OTVw2CmAb02CDZ6Ha8ssaLw5gYc4gQGWFogiaK0mm/EmWdExXF Ojk2Ars+DnP0FlKJLtA20ksLaHeQks6hdsicLVDbkzjLvGKCZoWVXx1OGoTiJojL spXZJI6qqCFvBBCqUC9Iu0oJR5mo6XYLpbJo2i9ysSOCjLaiKzwG/1y7e6GKgVea l6ileVXCwEeZXy8V3BMTY8GDSwt1IeH13E8uhxsFGD7g7BqItk7sGyCUU16JogB4 5xS1y+BDoC3QqXKpJ53Y51jc2KXxAiD8A1ynUjN/W8KTEhnP9jREJ4b00NdvGlFr qayMg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; 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=fm1; bh=xmMzL0kZXz9mdsxte/GdctBJjqu03J9Rydr6J7RHV 7k=; b=sUyuXHzSb33BUubjXxtbXb5IiMYa8UCmzb0p1xQvE6lhRsJmBmHcWpKVt /L7GCAaY6VEK/OafOS+uCwjRg2A1e/PokUiGLg9pXqXoUVGsv2kVewaIwJqy4hXO Q9lbOsN/h3E9Paa9QBwpE6dmBv3FxOWaOSUEh1jzBpI8xCrC9o0Yt3F67v42vI11 fWmkohfb+Od4dbDTfMkQiu343aGKnxRQb8imiNMC/R/0G/DbawmGPqE/Zc5z6iZ5 Q5UcL2LfxQ2Nli7tjIN3XrLMA7UHz8bQTdIF1o43ts81uCRQxefnSZtL2pHC01r+ e6w04LwQscDmchM6WlrDVwhfmUcRw==
X-ME-Sender: <xms:G-YWXPL0fRugOt3o9_HrWmCEjsgZSxmgPiYs4t5Sb8aqv0qMc5hz8Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudehledgudejlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhroh hmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecu ffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedrvdekne curfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd
X-ME-Proxy: <xmx:G-YWXOlo_FMguOEWE7YIw2uODrP7tt0bMvvDn5xLF0WCmJ88U3YmSw> <xmx:G-YWXLSWHh6K0fGGpsUi6PTl8-Zb2aU_Vbk7XRFNEnUNKTcUVDg4tQ> <xmx:G-YWXBYCYyckmn2a360MUvgA3mwfc8RGnqFaVqSedBrfjy9soq5ACQ> <xmx:HeYWXH8mCp4JEntIjFXlSdXqK0BbbjAjGygxSwYr8EbbCuTiEfxazg>
Received: from (unknown []) by (Postfix) with ESMTPA id AB3D2E4892; Sun, 16 Dec 2018 18:56:09 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Mon, 17 Dec 2018 10:56:06 +1100
Cc: "" <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Donald Eastlake <>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <>
Subject: Re: [secdir] SECDIR review of draft-ietf-httpbis-cdn-loop-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 16 Dec 2018 23:56:17 -0000

Hi Donald,

Thanks for the review. Some responses below.

> On 11 Dec 2018, at 10:40 pm, Donald Eastlake <> wrote:
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  Document editors and WG chairs should treat these comments just like any other last call comments.
> The summary of the review is Ready with issues.
> This document specifies a new "CDN-Loop" HTTP header field to detect Content Delivery Network loops. Such loops can be caused by misconfiguration or as part of a denial of service attack.
> Security:
> It is slightly misleading that in Section 1 the draft says how valuable an HTTP header "guaranteed not to be modified" would be but then the draft does not provide such a header. Maybe instead say "should normally be unmodified".

Agreed; we'll adjust this language.

> I believe this document should RECOMMEND that CDN-Loop headers include some sort of MAC (Message Authentication Code) covering the header so a CDN node can reliably recognize CDN-Loop headers that it has added. Since it need only recognize its own headers, the MAC need not be further specified or interoperable. (CDN-Loop information in an HTTP message can grow by the appending of entries or by additional of another CDN-Loop header. Since I have little confidence in the stability of header order, I would suggest MACs added as a parameter to a CDN-Loop header by the last parameter for that entry and sign that entry and all previous entries in that CDN-Loop header.) This could be done by modifying the 3rd paragraph of the Security Considerations section.

The authors have discussed this, and we don't see much utility in this; a MAC would protect against the modification of the key/value pairs, but they're not crucial to the functionality of the header. If an attacker were able to modify header values, something much more than a MAC would be needed. Also, as you note, interoperability isn't necessary here. So, while I think we're fine with mentioning in Security Considerations that parameters can be used to secure the field, I for one would be wary of going any further than that in this specification.

> Nit:
> Section 2: 3rd paragraph, suggest replacing "field to all requests" with "field in all requests".



Mark Nottingham