Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Paul Vixie <paul@redbarn.org> Wed, 16 August 2017 23:50 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70210132143 for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 16:50:36 -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, 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 kwEgqmZCKtGc for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 16:50:34 -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 7A1BB132256 for <dnsop@ietf.org>; Wed, 16 Aug 2017 16:50:34 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:48ee:a207:919c:69c4] (unknown [IPv6:2001:559:8000:c9:48ee:a207:919c:69c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2AB6E61FF3; Wed, 16 Aug 2017 23:50:33 +0000 (UTC)
Message-ID: <5994DA47.7000409@redbarn.org>
Date: Wed, 16 Aug 2017 16:50:31 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.16 (Windows/20170718)
MIME-Version: 1.0
To: Vernon Schryver <vjs@rhyolite.com>
CC: dnsop@ietf.org
References: <201708162250.v7GMoxDU058527@calcite.rhyolite.com>
In-Reply-To: <201708162250.v7GMoxDU058527@calcite.rhyolite.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5mNmXDSYoDqF62dctB2sm7-pWno>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Aug 2017 23:50:36 -0000


Vernon Schryver wrote:
> A network that routes requests to 8.8.8.8 to inject DNS lies will also
> arrange to ignore or pervert any DNS-in-band tell-the-truth signaling.
> Without access to a trustworthy resolver, tell-the-truth signaling is
> useless because you can't trust it.

i would like to be able to know that i can't trust it, rather than 
merely assuming that i can't trust it, as happens today. if neither the 
truth nor the lie is signed, i can make a red light blink, or even go 
offline, refusing the local edition of the social compact ("if you want 
to use the internet you have to accept dns answers w/o provenance.")

> No jurisdiction will allow foreign visitors to bypass local filters
> forever, because foreign visitors blab both the banned data and the
> banned tools.

as a frequent visitor to china, my verizon wireless roaming service is 
tunnelled back to the USA. i can read facebook, search google, and so 
on. verizon isn't a pirate -- they have a license to operate in china 
and they honor the terms of that license. but they don't sell this 
service inside china.

i expect more, not less, arrangements of this kind going forward, now 
that other nation-states are making decisions about internet content 
filtering for their citizens. note that i blogged on this specific 
point, and mentioned rpz, recently:

http://www.circleid.com/posts/20170718_nation_scale_internet_filtering_dos_and_donts/

> ... Isn't there
> talk about China blocking all tunnels including those of foreigners?

not that i've heard. china has a delicate balancing act, and they do not 
seem to want to completely discourage tourism, even if that means there 
are leaks in the great firewall as a result. on wifi or wired, they 
don't know who isn't a citizen. on LTE or GSM, they do. but the tunnel i 
use is slow, and expensive for both verizon and i. i'd like to offer 
china the opportunity to carry both dns truth and dns lies, in the same 
packet, with one of them a little harder to get at using older software, 
and with newer software having a switch, "do you trust policy having 
this key?" i expect that for android and iOS devices sold in china, this 
switch would be hardwired "on".

this reflects my broader belief that neither the open source community, 
or the internet technology community, will ever be taken seriously by 
the chinese gov't if we tell them how they should run their country's 
internet or its connections to the rest of the world. if they want to be 
able to express policy data more reliably using DNS than will be 
possible in a ubiquitous-DNSSEC scenario, then we ought to provide that, 
and encourage engineers from within china to help define, model, test, 
develop, and deploy it. this would ease the complexity burden for 
companies selling internet devices and services inside china. it will 
not make anybody in the world less autonomous than they already aren't.

> Even with the acquiescence of regimes, there are insurmountable practical
> technical and non-technical issues in providing both RPZ filtered and
> raw DNS answers, configuring applications, and ensuring that citizens
> don't get foreign, uncensored versions of applications.  It's one thing
> for a regime to allow foreigners to use foreign services (which I claim
> never lasts), and quite another thing for in-country operators to
> expect government censors to understand and believe that citizens can't
> use the truthful results in DNS responses.  If you were a DNS operator
> in China, would you ever allow your resolver to give truthful answers
> about some domains in any form or in response to any signaling?--of course
> not!

as a provider i would, whether in china or elsewhere, follow the law.

-- 
P Vixie