IETF Logo Mail Archive

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

Mark Nottingham <mnot@mnot.net> Thu, 20 December 2018 05:11 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 10841127B4C; Wed, 19 Dec 2018 21:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Ke5YXsH2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D4o6Pj4i
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 cQbOO_zljVOz; Wed, 19 Dec 2018 21:11:32 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A822F123FFD; Wed, 19 Dec 2018 21:11:31 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 91DD421F40; Thu, 20 Dec 2018 00:11:30 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 20 Dec 2018 00:11:30 -0500
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=fm1; bh=3 +I3IBgts2GqlWt55XJnl7cQAF97GI8QGjT61GXFJt4=; b=Ke5YXsH2MevdU250B 0b+sHkbn9KY/Hg4G/LK4F81Q0pWLP9YeLaBAoex24TWR8gFen1pVLOKEtfybmz0I cCs8YZTijei32sgcY/0v8wp8Z5Ax/HVvEaAWU2Rtf99o8SftQ7Y1kUYDxstahYVx 5P+KUmBn84+5fndciRkMfu2CLvtQNdBNNUAZxk8GkO14njsWb2rhEd9GbNcbjVaD lDQ8Z+eEzzpo+zbz+X5Mk1BdYCUizPs/8TZ+S4CoHanKk63Tx9T2QNrirEZxCpNd JEifg4xC2TJaRv+NPFO8c1H1PrO9yR4ptxIbxJR/8r7eOho+c1sozdbBJkjYLYU1 CYuJQ==
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=fm1; bh=3+I3IBgts2GqlWt55XJnl7cQAF97GI8QGjT61GXFJ t4=; b=D4o6Pj4ijmS0cNodzdxJQQMhjsldO0ZS83EpV9HHmzIaUmG18vat1QeFt M8BqGD+qNJ7/KBLMGh8MGDh0W73Lnk2OQi42m4xRtWykImdMKLG2J8km9AdO7q2c GTTtD+7wTmQH3cCDRR05RpVVs+50QKCf1ouQufOGYLlkyKWulj/3/4RvdhVfsqgq 1jVZoHnE4HO1HAOXqBlN1Y5eNsyWr2PjjZ2v8eOHzATIBlFLJaiNXXkDRYuOqHK8 t6YA2BOV1J0YMsk/fcgFIjigxuec15Hi0Q0zUqN/4d0r+fpnYe/TdcytrHQ/fXKz yeodxgN3nfYIB+pOnl6Mg99ouNA/w==
X-ME-Sender: <xms:gSQbXFp93OyRHHMypsWmY9U4bmcfafa4vFMAkEm84Amkxl2ESYdCpg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejvddgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomh epofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucff ohhmrghinhepmhhnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeehrddvkeenuc frrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushht vghrufhiiigvpedt
X-ME-Proxy: <xmx:gSQbXL4wnS4KhxlHI7jl6JIMI4LkCCe7_ex4yEx-qstKZ8CidRuZHQ> <xmx:gSQbXNNhi4cFMdEBubmTm4EbkFxMGLQpYrhqzaEeQddgM4jPKeE8TA> <xmx:gSQbXFNCvyel8p5SPpw6hAJGKmANdYniIjXm5ueWweylXul7cJOqGg> <xmx:giQbXGzoeoi0_beiM_f8R4J3Tu2kVmIBMsKggnsNWbRTzalcldOapQ>
Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id E6E4BE40A1; Thu, 20 Dec 2018 00:11:27 -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 <mnot@mnot.net>
In-Reply-To: <CAF4+nEGmx6Dt8GzhKz+hFTxy5QWW4Y6dfdvQq7iLf+6oqjU60g@mail.gmail.com>
Date: Thu, 20 Dec 2018 16:11:24 +1100
Cc: "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-httpbis-cdn-loop.all@ietf.org, secdir@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <523B0785-6B4A-4B68-9D04-F32087332CE7@mnot.net>
References: <CAF4+nEH7OoTDFkXKy0M4KQ_DeSCfDPUT4HUgdgG1ksV+HXCnng@mail.gmail.com> <8EC47356-006A-4A47-8C4C-09C9F31010D2@mnot.net> <CAF4+nEGmx6Dt8GzhKz+hFTxy5QWW4Y6dfdvQq7iLf+6oqjU60g@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ACsaRF1bZYSZn9R8stcpnIRTNW8>
Subject: Re: [secdir] SECDIR review of draft-ietf-httpbis-cdn-loop-01
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: Thu, 20 Dec 2018 05:11:35 -0000


> On 20 Dec 2018, at 10:18 am, Donald Eastlake <d3e3e3@gmail.com> wrote:
> 
>>> 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.
> 
> Well, OK I guess. It just seems so easy to add a MAC in the header
> covering the preceding part of that header that I would do it. And it
> would help rule out certain causes when debugging problems. But if the
> WG has decided not to recommend this, so be it.

Just to make sure you saw it, Security Considerations already includes:

"""
It is possible to sign the contents of the header (either by putting the signature directly into
the field's content, or using another header field), but such use is not defined (or required) by
this specification.
"""

Cheers,

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

v2.23.0 | Report a Bug | By Email