Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

Eliot Lear <lear@cisco.com> Mon, 25 March 2019 09:13 UTC

Return-Path: <lear@cisco.com>
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 927B212037A; Mon, 25 Mar 2019 02:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 VT3LwfdyDkdb; Mon, 25 Mar 2019 02:13:32 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D92120373; Mon, 25 Mar 2019 02:13:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8296; q=dns/txt; s=iport; t=1553505211; x=1554714811; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=a5qltXFEsDR0GCudOaGKTeQ4R+g8tE94uwwkzqs/vEg=; b=VC/n2gi6VRNKn/zgjKyD2RPtYS5dS+eCzlDN20p6xwgrs8KL9/AcgYZD u6ukqi3YK1ayVoiYMhtETxHhFBGpDCwZogzlfe+aAcQggubM/BvBwhYVK dgd3HNF+PoAHOl6huRC06iCVCL1tmZYfJ0I7owAI/4FPK0tCIuVisWX3F k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAAA+m5hc/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGBDoECRXMhEieEDoh7jE6SQ4dyDQEBhGwChSw?= =?us-ascii?q?3Bg0BAQMBAQkBAwJtKIVKAQEBAwEjVgULCxgqAgJXBhODIoFuCK4AgS+FRoR?= =?us-ascii?q?igS8Bi0iBf4E4H4JMPodOMYImA6UWCZM5GZN+m1SCcgIEBgUCFYFjIiiBLjM?= =?us-ascii?q?aCBsVZQGCQT6BWBeOHz4DMI9TAQE?=
X-IronPort-AV: E=Sophos; i="5.60,256,1549929600"; d="scan'208,217"; a="10947978"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2019 09:13:29 +0000
Received: from dhcp-10-61-105-142.cisco.com (dhcp-10-61-105-142.cisco.com [10.61.105.142]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x2P9DS9S000568 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Mar 2019 09:13:29 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <02322DB8-D2B6-4AF6-B445-C56CBDC93123@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A25614EC-1899-461C-8161-E383A17F86A6"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 25 Mar 2019 10:13:28 +0100
In-Reply-To: <alpine.LRH.2.21.1903241755571.10798@bofh.nohats.ca>
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>, "doh@ietf.org" <doh@ietf.org>
To: Paul Wouters <paul@nohats.ca>
References: <04C556AF-D3B3-41A5-B119-8FE5F81FB9A7@huitema.net> <1878722055.8877.1553241201213@appsuite.open-xchange.com> <CABcZeBPmpN-cEPK92QQW3bkvc41Cx5g7B_YuUXCJK3j1qF995Q@mail.gmail.com> <20190322.101434.307385973.sthaug@nethelp.no> <32A78B0C-52B6-46E5-A46F-D63D21DEC52C@sky.uk> <CAOdDvNqb2+4Az+g608QRjYt+ZdUt1L9GAc=MJM3-xd0ZNmeBEQ@mail.gmail.com> <1C720263-10E4-423B-B152-5673E115A4C1@gmail.com> <alpine.LRH.2.21.1903241755571.10798@bofh.nohats.ca>
X-Mailer: Apple Mail (2.3445.102.3)
X-Outbound-SMTP-Client: 10.61.105.142, dhcp-10-61-105-142.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/g6AmKIV0GK2QA5ic8E05ayhoEbM>
Subject: Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 25 Mar 2019 09:13:33 -0000

Hi,

> On 24 Mar 2019, at 23:25, Paul Wouters <paul@nohats.ca>; wrote:
> 
>> The blocking of DoT to a given provider should be interpreted as an explicit policy. Users should be informed
>> that they may, and very likely will, be violating someone’s policy, if they choose to use DoH in that
>> circumstance, and that they may be violating laws by doing so, and should only do so if they are willing to
>> accept that risk.
> 
> Again, this is the network operator centric view. There are many hostile
> networks that would block DoT just so that they could monetize (legally
> or illegally!) from my harvested DNS data. I can assure you the warning
> you want to write to users would be very different from the warning I
> would want to give those users. Which is why the IETF doesn't do
> banners towards endusers.

Putting aside legal language, but Brian’s basic notion is that the user can make an informed decision and the network can express its policies, with which the user can agree or not agree (and go elsewhere).  Having the protocol elements to permit this sort of agreement is its own tussle.

Eliot