Re: [Gen-art] Genart last call review of draft-ietf-httpbis-cdn-loop-01

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 18 December 2018 02:16 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD0E130F79; Mon, 17 Dec 2018 18:16:37 -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 (1024-bit key) header.d=joelhalpern.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 gQGHG5zYhXgV; Mon, 17 Dec 2018 18:16:36 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6212130F78; Mon, 17 Dec 2018 18:16:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 43JhTv4GLFzX5K2; Mon, 17 Dec 2018 18:16:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1545099395; bh=9d6UDbsqzwxNPP1liueWuiSMuBNMIXWDeCnX5lHNgSo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=QcGcjt3s9VJkF1W9L2ZRlBFuQTesrEdqgSccqdXFVJOEIOA/blxKFKmQlOeSTzQSp aziK1v9Lf/MEjPRDMILm+6QSNA+G7izfE0ALdt7fKYXoiNG/iY4xtST5XJQM9xcqUt hLM5iu2xrIWg+UlPbYCs5OocUF69zug6CiHdzkS0=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43JhTt5S6kzX5K1; Mon, 17 Dec 2018 18:16:34 -0800 (PST)
To: Mark Nottingham <mnot@mnot.net>
Cc: gen-art@ietf.org, draft-ietf-httpbis-cdn-loop.all@ietf.org, ietf@ietf.org, ietf-http-wg@w3.org
References: <154386274295.5033.8259810220470907158@ietfa.amsl.com> <BEF06AF3-42E3-4795-B3DE-3FDC3AD947A2@mnot.net>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <f6d36cdf-9447-0285-f51d-c78de9da8ffc@joelhalpern.com>
Date: Mon, 17 Dec 2018 21:16:33 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <BEF06AF3-42E3-4795-B3DE-3FDC3AD947A2@mnot.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/ik220Ztiug47QkGq6frcVs3uZSo>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-httpbis-cdn-loop-01
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Dec 2018 02:16:38 -0000

Thank you Mark.
On the first item, please look carefully at the use of pronouns.  It 
took me several readings to realize which CDNS "they" referred to.

On the second item, it was not TLS protection I was referring to. 
Rather, I was imagining one bad cache stripping the loop prevention.  I 
think the real answer to that is that it is no worse than such a cache 
originating bad requests.

Yours,
Joel

On 12/17/18 6:53 PM, Mark Nottingham wrote:
> Hi Joel,
> 
> Thanks for the review.
> 
>> On 4 Dec 2018, at 5:45 am, Joel Halpern <jmh@joelhalpern.com>; wrote:
> ...
>>     This depends upon CDNs which have not been upgraded not stripping this
>>     header.  While I can believe that is a reasonable assumption, it seems that
>>     a paragraph explaining that it is the case, and if possible what experience
>>     leads us to think it is the case, would be helpful.
> 
> I've added:
> 
> """
> Note that if a CDN that does not implement this specification allows customers to remove or modify the CDN-Loop header field, that CDN could become an attack vector against other CDNs, even if they do implement it.
> """
> 
>>     This document says that it is to protect against attackers causing loops.
>>     If the attacker is an external customer, the advice in the security
>>     considerations section makes sense.  The other apparent attack would be an
>>     attacker in the network who strips the information each time it comes past.
>>      I believe the reason this is only an apparent attack is that such an
>>     attacker could almost as easily simply generate additional messages instead
>>     of producing a loop.  If I have inferred this correctly, it seems useful to
>>     state it.
> 
> CDN back-end connections are increasingly protected by HTTPS. Also, most back-end connections are over transit that's unlikely to meddle in these ways (unless a state actor is involved).
> 
> Even so, the spec already says:
> 
> """
> The threat model that the CDN-Loop header field addresses is a customer who is attempting to attack
> a service provider by configuring a forwarding loop by accident or malice.
> """
> 
> .... which seems to address your concern. I'm wary of enumerating the attacks which this header doesn't prevent, since it's a necessarily open list. Inserting requirements like "back-end connections SHOULD be over HTTPS" are more appropriate for a general spec defining what a CDN is (and we're not there yet; this spec is a baby step towards that :).
> 
> Cheers,
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
>