Re: Last Call: <draft-sahib-451-new-protocol-elements-01.txt> (New protocol elements for HTTP Status Code 451) to Informational RFC
valdis.kletnieks@vt.edu Wed, 04 July 2018 00:47 UTC
Return-Path: <valdis@vt.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30E6130F1F for <ietf@ietfa.amsl.com>; Tue, 3 Jul 2018 17:47:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6mjuR2w5FkO6 for <ietf@ietfa.amsl.com>; Tue, 3 Jul 2018 17:47:27 -0700 (PDT)
Received: from omr1.cc.vt.edu (omr1.cc.ipv6.vt.edu [IPv6:2607:b400:92:8300:0:c6:2117:b0e]) (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 D6545130EE1 for <ietf@ietf.org>; Tue, 3 Jul 2018 17:47:26 -0700 (PDT)
Received: from mr6.cc.vt.edu (mr6.cc.vt.edu [IPv6:2607:b400:92:8500:0:af:2d00:4488]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id w640lQSl009100 for <ietf@ietf.org>; Tue, 3 Jul 2018 20:47:26 -0400
Received: from mail-qt0-f200.google.com (mail-qt0-f200.google.com [209.85.216.200]) by mr6.cc.vt.edu (8.14.7/8.14.7) with ESMTP id w640lKGg004280 for <ietf@ietf.org>; Tue, 3 Jul 2018 20:47:25 -0400
Received: by mail-qt0-f200.google.com with SMTP id f8-v6so4009937qth.9 for <ietf@ietf.org>; Tue, 03 Jul 2018 17:47:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=g/4i7aeSMvyJpzdCIOUZP5CqXJr9yGSh6t05w7UrRMk=; b=s6GhMRIr3IZ0TJuHEjl40Pipfuxkx6XIINL1tD6ml9WE3w4kEf9ciXqbQAfZlnTLMd WjH6Obw3vjDBCTbYLyK/lh0J1zVyznkDE7DZBytihkbsPHwoePN3dPqgVw/FHAGR2dxq ecrJSPSJpmfNHXdkOUdvrHaqQ8Elm2ZyaVjGxzKXKVwG+Zz4FchsAIdNJvyUAmV88PwU tozhFlWByUdKV4fiSz2j1TD1MlOyrarO7eHuAH/TPPrS9gbF844jw3EtCsoPGwcd+IMZ vD6W2IWqTP2stivvHnvcglfqFERnboXVfOfW37ZiyDXKxvEnhm8xF2vBoYdSPTYMcnCf eg0Q==
X-Gm-Message-State: APt69E2mTc7Ig96zZ4uJTSB1cEgoGNIiBnX61dtdUhPB7FdAqZ0dizYv gSHBAY64UutUnCfd04lhbAjCdhlq1MsDe+hhex1dpfwNl7PcPofG+GDS1ZPqqzc0UefSLi33A2S Mbq/dFT78A512EbM=
X-Received: by 2002:ae9:e118:: with SMTP id g24-v6mr19289156qkm.306.1530665240714; Tue, 03 Jul 2018 17:47:20 -0700 (PDT)
X-Google-Smtp-Source: AAOMgpf1eSeTBPXh2HE/8XBW9TrOCvyQbTN16u+qNTaRGe+HfN0CbOvYbWhUqDq4ij8aDj7w7hHKbA==
X-Received: by 2002:ae9:e118:: with SMTP id g24-v6mr19289145qkm.306.1530665240453; Tue, 03 Jul 2018 17:47:20 -0700 (PDT)
Received: from turing-police.cc.vt.edu (turing-police.cc.ipv6.vt.edu. [2001:468:c80:2103:f21f:afff:fe0c:8ada]) by smtp.gmail.com with ESMTPSA id b62-v6sm1907011qkj.48.2018.07.03.17.47.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 03 Jul 2018 17:47:19 -0700 (PDT)
Sender: Valdis Kletnieks <valdis@vt.edu>
From: valdis.kletnieks@vt.edu
X-Google-Original-From: Valdis.Kletnieks@vt.edu
X-Mailer: exmh version 2.8.0 04/21/2017 with nmh-1.7+dev
To: Tim Bray <tbray@textuality.com>
Cc: IETF-Discussion Discussion <ietf@ietf.org>, draft-sahib-451-new-protocol-elements@ietf.org, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: Last Call: <draft-sahib-451-new-protocol-elements-01.txt> (New protocol elements for HTTP Status Code 451) to Informational RFC
In-Reply-To: <CAHBU6iunrrZ6W1hQTWqx7ziEPdDMspt+mf6u0t6DVJn_rS04aQ@mail.gmail.com>
References: <153054106529.16082.5456844530797164969.idtracker@ietfa.amsl.com> <CAHBU6iunrrZ6W1hQTWqx7ziEPdDMspt+mf6u0t6DVJn_rS04aQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1530665238_16925P"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 03 Jul 2018 20:47:18 -0400
Message-ID: <130562.1530665238@turing-police.cc.vt.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/1Ri4HcBrMHEjtvqon5fBLSFDhMU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2018 00:47:44 -0000
On Mon, 02 Jul 2018 22:17:01 -0700, Tim Bray said: > 4. Section 4, 1st bullet point: âHTTP 451 SHOULD NOT be used by an > operator to deny access to a resource on the basis of a legal demand that > is not specific to the requested resource.â Why is this a good idea? If I > decide to respect a legal demand that I not give access to any resources > that mention the existence of a certain person, or which are sourced from a > subdomain of example.com, or from a server whose geographic location > within the Vatican City, why should I not be able to use 451? Amen to that. If anything, it's *vastly* more likely that the legal demand won't be specific to just that one object, but will cover a large number of objects (possibly into the thousands or millions). There's no sense in allocating a return code for the presumably rare "a request was made to block exactly one object" case, and not allocate one for "a request was made to block every object of type FOO". For example, I've never seen Google reply with "exactly one response was filtered" - if there's *any* hits, there's usually *multiple* hits. Perhaps "on the basis of a legal demand that is not directly applicable to the specific requested resource" would be better? Or other wording that makes it clearer that 451 can be used for any case where you have an object that you can't serve up? On Tue, 03 Jul 2018 10:23:23 -0700, Shivan Kaul Sahib said: > HTTP 451 is being used to block users who reside in the European Union by > websites that are not GDPR-compliant. There is no real "legal demand to > deny access" to the resource. If they can't provide access to a EU resident because they aren't GDPR compliant (and thus have an actual legal exposure to penalties if they provide access anyhow), they have two choices: 1) Deny access 2) Face the legal exposure. You're going to have a really hard time explaining how a "Deny access to this copyrighted information or face legal consequences" takedown notice is a legal demand, and "Don't allow access that involves non-GDPR compliant data or face legal consequences" isn't a legal demand. Maybe a lawyer understands the difference, but it's a strong bet that the person who has to actually maintain the list of 451-blocked objects won't. > them to use it. If we think that the status code should be used for > compliance with *any law whatsoever*, even if the law doesn't actually > demand that the resource be taken down, then perhaps making that clear > would be helpful for people seeking to use the status code. I'll note that "demand that the resource be taken down" is subtly different from "demand that the resource not be available" (in particular, if it's being made *conditionally* unavailable to some users, but potentially still accessible to other users). This part of the draft is problematic as well: demand. Note that while the introduction of [RFC7725] mentions that the legal demand for denial of access should be related to the resource being requested, the RFC's description does not make it clear that the resource being denied access to must be directly mentioned in the legal demand. That's because in most countries, when the legal document arrives, it quite likely *won't* itemize 48,374 separate URLs to fulfill a "directly mentioned" requirement. It will have terms like "any and all documents concerning <specific definition of documents involved>". And that's because if the legal document says: "Block access to https://www.example.com/this_data_is_banned.txt" all they have to do is rename it to 'this-data-is-banned.txt", fix links to it, and we're playing whack-a-mole. And it's guaranteed they can rename the file and fix the links faster than you can go back to the judge and get a new order signed. Especially the 7th or 8th time in a 48 hour time span. So the legal order will often *not* "directly mention" the resource, but will instead give a *description* of the object sufficiently specific to allow identification of same. Overall, I'm having a *really* hard time seeing how redefining 451 to only apply to resources that have been directly identified in the legal demand improves the situation over RFC7725.
- Re: Last Call: <draft-sahib-451-new-protocol-elem… S Moonesamy
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Mark Nottingham
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Tim Bray
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Patrick McManus
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Paul Hoffman
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Alexey Melnikov
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Shivan Kaul Sahib
- Re: Last Call: <draft-sahib-451-new-protocol-elem… S Moonesamy
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Shivan Kaul Sahib
- Re: Last Call: <draft-sahib-451-new-protocol-elem… valdis.kletnieks
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Barry Leiba
- Re: Last Call: <draft-sahib-451-new-protocol-elem… S Mooensamy
- Re: Last Call: <draft-sahib-451-new-protocol-elem… valdis.kletnieks
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Matthew Kerwin