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.