Re: ID for Immutable

Amos Jeffries <squid3@treenet.co.nz> Sun, 30 October 2016 03:20 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AEC129612 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 29 Oct 2016 20:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.498
X-Spam-Level:
X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 S-XCGRfRWhHN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 29 Oct 2016 20:20:22 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F761295DD for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 29 Oct 2016 20:20:22 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c0gbU-00041x-SP for ietf-http-wg-dist@listhub.w3.org; Sun, 30 Oct 2016 03:16:12 +0000
Resent-Date: Sun, 30 Oct 2016 03:16:12 +0000
Resent-Message-Id: <E1c0gbU-00041x-SP@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <squid3@treenet.co.nz>) id 1c0gbQ-00041G-B1 for ietf-http-wg@listhub.w3.org; Sun, 30 Oct 2016 03:16:08 +0000
Received: from [121.99.228.82] (helo=treenet.co.nz) by titan.w3.org with esmtp (Exim 4.84_2) (envelope-from <squid3@treenet.co.nz>) id 1c0gbK-0002zu-44 for ietf-http-wg@w3.org; Sun, 30 Oct 2016 03:16:03 +0000
Received: from [192.168.20.251] (unknown [121.98.45.78]) by treenet.co.nz (Postfix) with ESMTP id 48C24E6EAA for <ietf-http-wg@w3.org>; Sun, 30 Oct 2016 16:15:28 +1300 (NZDT)
To: ietf-http-wg@w3.org
References: <CAOdDvNqam930_0eA1p3yHW+xDdOm0AAMKvVKe6xwNwm1itpRpQ@mail.gmail.com> <f9f0e413-1fbb-1faa-833b-5dc7d7ea1fdc@measurement-factory.com> <CAOdDvNqTabR3zpRgjJVkBPdBVcOboCbG=5b6x+mKauwB1-w=Pw@mail.gmail.com>
From: Amos Jeffries <squid3@treenet.co.nz>
Message-ID: <c31c706c-1873-8143-8728-8c4888c37f4b@treenet.co.nz>
Date: Sun, 30 Oct 2016 16:15:20 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAOdDvNqTabR3zpRgjJVkBPdBVcOboCbG=5b6x+mKauwB1-w=Pw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.271, BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1c0gbK-0002zu-44 fec2b7d9611f0307dc58543e25956b27
X-Original-To: ietf-http-wg@w3.org
Subject: Re: ID for Immutable
Archived-At: <http://www.w3.org/mid/c31c706c-1873-8143-8728-8c4888c37f4b@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32729
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 29/10/2016 6:21 a.m., Patrick McManus wrote:
> I do believe the lack of integrity protection in plaintext transfer is an
> important security consideration for immutable that suggests they should
> not be used together. I'm open to other wording on it for sure.. https://
> might be sufficient here.
> 

Since the behaviour which 'immutable' is defining is already optionally
followed by any cache implementation in both insecure and secure
contexts. There is no additional security considerations being added by
this option.

The security considerations around corrupt objects being considered
"fresh" applies to HTTP caching in general, not just immutable objects.

The issues that are being pointed out are real, but apply equally for
secure and for insecure contexts already today without immutable being
involved. I dont see any need to distinguish between contexts in this
draft, nor to prohibit 'insecure' contexts from having immutable objects.


To back this; Squid has for a very long time had a configuration control
which enables admin to mark specific URL as having this same immutable
behaviour. It is one of the more popular ones and used in the 'insecure
context'.

AFAIK, the only issue which has come to light in all that time that can
be attributed to this control is that objects changing faster than what
the admin was aware (or their stated expiry time) had to be manually
refreshed from the client end (if anyone actually cared). Moving the
control point from proxy config to origin server avoids that issue.

Amos