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

Donald Eastlake <d3e3e3@gmail.com> Wed, 19 December 2018 23:18 UTC

Return-Path: <d3e3e3@gmail.com>
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 B7064129BBF; Wed, 19 Dec 2018 15:18:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3dcCEvUX4vQa; Wed, 19 Dec 2018 15:18:26 -0800 (PST)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F5E126F72; Wed, 19 Dec 2018 15:18:26 -0800 (PST)
Received: by mail-io1-xd36.google.com with SMTP id o13so12317ioh.2; Wed, 19 Dec 2018 15:18:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MaUkJsJ92+s0BfHOlExbQV8MxUKJWTmyXsVNt0QFGNU=; b=HzuoB6+Q4/i68WPsndB/HIjWdVqEhwsksCq2Ls6Jdv4vWU/KBN3fX3pfTp1tzjOCM0 2HFJzbP5x0EVuVXaMEJP5gBXjSmQe+h5KITYZNzOr0RNBOJhmuABnn4t42seBNUPMS4J FaxaRinu0FAAECiRSHj7SPiwFj6SZj7npgWbo7UGIslHdPp+TN6hVUv9r3ymDAOc5I+4 AtMayNCwLSRy8YJrHFgjnMGdBr4ToXnSbs8RmilopQJ8qM+tN11I8aM+Pdo4MoNU88n5 pSgvt1YBHucvpw9KsUfhScxhzSubV7ItY/ECteeGewOjC/SWPXKmbzufTX6sxRVeqYNu qHyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MaUkJsJ92+s0BfHOlExbQV8MxUKJWTmyXsVNt0QFGNU=; b=ce7+XZPRC4wy+rQzLvpTTA//5RVOLvRFh7894XK0Di1f0WK+oRN1EYgB8qMe/5ORh+ N5u3OVZ1ylqq5QaE8sHuHJahlSA021zGoCO7puSxQLqF7iu/OdlGvn+nEWY9CqFwaUZz Oj+q1tK+CwavutiQruhwVMUkb5fztSq4/7BDhSkxt7+Lh+7K1e/p6//+fl77LjfjvjaF drJ7xHY513rGpr7waHQJLhDb2oJ/RuyyrJIvyMtHlMdwHI48/e41/CF4qX0rUGQaI4B9 8/hues7MW2V45QM5qhvSl2xo3eCAVEHrKkl1SsiLtjvdQRDRscEHuCm2olDPSzysIRZT yTPQ==
X-Gm-Message-State: AA+aEWZzCUSqFFJzl3XB0N8sfOo+e9yPNGX7j3ilaI5ul3ftEaz40ewC WR7pReW8zORows7XJUC2ZZqeVDz+1b2cF8B6u1o=
X-Google-Smtp-Source: AFSGD/Xwjoic4HdC/rsGcQZCi1GcMwi6874whImwpP157VsBJj9E0vxkMmFxWrDkkVYifjDIBr7Wb/5+K8PzjW8IZO8=
X-Received: by 2002:a6b:e919:: with SMTP id u25mr19991060iof.132.1545261505769; Wed, 19 Dec 2018 15:18:25 -0800 (PST)
MIME-Version: 1.0
References: <CAF4+nEH7OoTDFkXKy0M4KQ_DeSCfDPUT4HUgdgG1ksV+HXCnng@mail.gmail.com> <8EC47356-006A-4A47-8C4C-09C9F31010D2@mnot.net>
In-Reply-To: <8EC47356-006A-4A47-8C4C-09C9F31010D2@mnot.net>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 19 Dec 2018 18:18:14 -0500
Message-ID: <CAF4+nEGmx6Dt8GzhKz+hFTxy5QWW4Y6dfdvQq7iLf+6oqjU60g@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-httpbis-cdn-loop.all@ietf.org, secdir@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/rf0JBCEGOcs87oMD-C6Kg60wyms>
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: Wed, 19 Dec 2018 23:18:29 -0000

On Sun, Dec 16, 2018 at 6:56 PM Mark Nottingham <mnot@mnot.net>; wrote:
>
> Hi Donald,
>
> Thanks for the review. Some responses below.
>
> > On 11 Dec 2018, at 10:40 pm, Donald Eastlake <d3e3e3@gmail.com>; 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.

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.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e3e3@gmail.com

> > Nit:
> >
> > Section 2: 3rd paragraph, suggest replacing "field to all requests" with "field in all requests".
>
> Thanks.
>
> Cheers,
>
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>