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

Paul Vixie <paul@redbarn.org> Wed, 13 March 2019 06:28 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAB31277DB; Tue, 12 Mar 2019 23:28:25 -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 qYL7TigljdHU; Tue, 12 Mar 2019 23:28:24 -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 C38E512008F; Tue, 12 Mar 2019 23:28:24 -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 B9506892C6; Wed, 13 Mar 2019 06:28:23 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, "doh@ietf.org" <doh@ietf.org>, Christian Huitema <huitema@huitema.net>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Wed, 13 Mar 2019 06:28:23 +0000
Message-ID: <2008045.2dFDXBJIrK@linux-9daj>
Organization: Vixie Freehold
In-Reply-To: <CAH1iCir7QgDsQ3wZ4nOfRpAOLt4Cgzwm3ONpdoseMxmfS8K=nQ@mail.gmail.com>
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7128698.bmqQpDD1M4@linux-9daj> <CAH1iCir7QgDsQ3wZ4nOfRpAOLt4Cgzwm3ONpdoseMxmfS8K=nQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Bij8So-h9NOlmvrgQj_diJ_3HW4>
Subject: Re: [Doh] [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2019 06:28:26 -0000

On Tuesday, 12 March 2019 23:12:37 UTC Brian Dickson wrote:
>...
> I think there is a way to use technical design(s) to split hairs, i.e. I
> think the side meeting
> has the possibility of bearing fruit which is palatable enough for all
> parties.

i hope so. i will only be in prague from saturday evening 'til monday morning.

> 
> The crux of the problem is how to determine if the network operator is
> truly hostile (GFC),
> or merely restrictive (Paul's network, Paul's rules.)

no, that's not the crux. it's only one problem, the one being had by a user or 
application wondering which dns server and what protocol to use.

there's another problem, considered the crux by some, but still only one 
problem, and that's how to prevent truly hostile users or apps from bypassing 
the security policy implemented in the local RDNS control plane.

neither one gets to call itself the crux, i think.

vixie