Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

Paul Vixie <paul@redbarn.org> Tue, 12 March 2019 20:51 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5851311CB; Tue, 12 Mar 2019 13:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 oZmBe1o_0Sca; Tue, 12 Mar 2019 13:51:14 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2749B1312B6; Tue, 12 Mar 2019 13:51:14 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id EC039892C6; Tue, 12 Mar 2019 20:51:13 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Christian Huitema <huitema@huitema.net>
Cc: dnsop@ietf.org, "doh@ietf.org" <doh@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Date: Tue, 12 Mar 2019 20:51:12 +0000
Message-ID: <5342244.Q90AZAhhXk@linux-9daj>
Organization: Vixie Freehold
In-Reply-To: <b7bbc027-1195-8c50-9921-77baa87f9160@huitema.net>
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <1709670.IeiIJmgblr@linux-9daj> <b7bbc027-1195-8c50-9921-77baa87f9160@huitema.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/FxEAudt5LPiU4_MIIhR7R72eXjg>
Subject: Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 20:51:16 -0000

On Tuesday, 12 March 2019 20:31:54 UTC Christian Huitema wrote:
> On 3/12/2019 12:56 PM, Paul Vixie wrote:
...
> > i don't like the chinese government's rules for the great firewall. so, i
> > keep my visits to that otherwise-great country short. this hurts me, and
> > maybe hurts them also. but, it's their country, and i will obey their
> > laws when i am using their network. and then i'll vote with my feet, to
> > get to a better network with better rules. i once traveled to HK for a
> > weekend between two week-long conferences behind the GFW, just so i could
> > get work done.

> There is a lot of difference between what can be imposed in a police
> state and what looks legitimate in a user agreement in a free country.
> And I sure hope that we maintain that difference.

i expect you to be disappointed in that hope, if you work on this long enough.

> A good result of that
> discussion would be to clarify these differences. For example, there are
> legal differences between what can be done in a private home, and what
> can be done in a place like a hotel that provides public accommodation.

there are also legal differences from nation to nation, from state to state, 
from county to county, and from city to city. the internet is below all of 
that.

> Just like hotels cannot discriminate against some categories of
> customers, I don't think that places providing public connectivity
> should be able to discriminate against content accessed by their guests.

just as i've cautioned the RFC 8484 authors against imposing their anti-
censorship views on my parental controls or corporate network policies, let me 
here caution you against imposing your (clearly) western liberal-democratic 
views on the development of protocols whose ideal state is "interoperability" 
and never more or less.

vixie