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

Brian Dickson <brian.peter.dickson@gmail.com> Sat, 16 March 2019 01:47 UTC

Return-Path: <brian.peter.dickson@gmail.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 A6C5E13112D; Fri, 15 Mar 2019 18:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 68nZyv2QIcrP; Fri, 15 Mar 2019 18:47:21 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E9F130DE9; Fri, 15 Mar 2019 18:47:21 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id v20so12224588qtv.12; Fri, 15 Mar 2019 18:47:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tp1SWB34fALNqUXtjVlgODoj2ofAaIDSuklHKIfBhps=; b=adiYfZ6ryXxI/sVb/hZK9ovv4FCqj7yrjoxw5gSlQcYWk/O8iv/K3Z3fikDMPQSuBf FPWYi37pjSgPcnS2tPNyvFs8B+ojWt5aN67bwFAB+syBj3hJtakcoVQwfkU9+86VbHpu +rC0VRtwjbcpy42rc+0ldIquVdqHYAc79+Scz0gSs0/kFP1pzszdPY/gAIuocIBPqHbQ il4CMq4FY/MYNLCV22X7gy2WiJbBuQlZLBAE96g+09C0kkUQ3/SIVmTN63LfmJ0cTokC mMaDSg1Bv1fyuuLm4LIMyDWOYFhliSNOJYGYEaO9nfhtTYYujXzPD4KbrisabeiMs9Bd Iypg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tp1SWB34fALNqUXtjVlgODoj2ofAaIDSuklHKIfBhps=; b=dCv1Bf70mimv8KGFP2vbxQBiAEXlgCti58+OX79149/Jn0u2rvK1bduC9WsEt0UdFr bsfibkNZxXAIbSR4CAcs9iTWCQPYoRa7AtvNKMYvkEm0W7nHpn5it1HNu5Iz73dS/2lC Sy/XzC77IwhPoZO2FZhVCgynsnzXQM/5mnDCqayIGcvWfoEZkA4oX1pYBNrIzAfxOz0P /eR59KVvEdSgZ4lCNNUERXGPcrDKv3Izk8eipUu6pFVffKm6H937wxav4q3OOhjQv8nN vlNWbFDL4ikNntNOWL7Q8dqcH12nuYWLMVPO5D0o82J9VKe2gLCZNQzYBQqsodKA9gfe CWaw==
X-Gm-Message-State: APjAAAUy40mM/I+FCTXXCIt5hH20NUfnZxLhcGYN1a7cfBiB+CdQSCd3 ruOKFJxG/Csu/Yt2Q7Wvpb4f7iAQRnXdyYs3IwE=
X-Google-Smtp-Source: APXvYqzVkBIhMkYq+/GEtI/WI5YMp8O1flK4rOD5ZB3H6hlrSJmE8IUcTYAFCf9qeCeZ7QghGOJ+scRX0LX0ZdbRZI0=
X-Received: by 2002:a0c:9b85:: with SMTP id o5mr4877357qve.62.1552700840645; Fri, 15 Mar 2019 18:47:20 -0700 (PDT)
MIME-Version: 1.0
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com> <1900056.F7IrilhNgi@linux-9daj> <CA+9kkMCgmzjbPM+DTUYuS3OsT+wOCmsyaGPg6fPu=w-ibL=NrA@mail.gmail.com>
In-Reply-To: <CA+9kkMCgmzjbPM+DTUYuS3OsT+wOCmsyaGPg6fPu=w-ibL=NrA@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Fri, 15 Mar 2019 18:47:05 -0700
Message-ID: <CAH1iCipawsDrmzVHwYnhfcUWWedjunVVgY1y9sX6MXw7GTbdmw@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>, DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000c985c05842c5681"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QIEKBhfGq0Ho3i79gDfx6n4WVLs>
Subject: Re: [DNSOP] [Doh] 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: Sat, 16 Mar 2019 01:47:24 -0000

This has been an excellent discussion, with lots of insightful analysis,
examples, and great context.

I apologize in advance, but I'd like to pick one particular sentence, to
use for teasing out what I think is a foundational issue:

On Fri, Mar 15, 2019 at 11:37 AM Ted Hardie <ted.ietf@gmail.com> wrote:

>
> This is certainly not the case for all deployments of DoH.
>
>
This is where the distinction between, for example, "normative" vs
"informative" are important terms.

What I think we (the larger "we" in these threads) need to settle, is what
should be the rules (aka "protocol") for what we want or need ALL
deployments of DoH to do; or how they do what they do; or how users control
what the clients do; or how network operators (last mile or otherwise) can
influence/control what DNS protocols and operators can be used.

Some of the issues might be how users are able to know the identities of
DNS operators (e.g. certs for DoT or DoH); how services are offered,
selected, configured, and possibly restricted; and what
jurisdictional/regulatory/legal environments might be applicable to any of
the parties involved.

It's definitely a non-trivial issue, but it needs to be handled in a
comprehensive, cooperative, and inclusive manner.

My preference would be that no DoH operators, or client software, be
deployed in a manner that is deliberately ignorant of or in violation of
policies and laws, even if there may be some particular use cases where no
laws or policies are violated by a particular set of {operator,client}
pairs.

Yes, there may be large swaths of jurisdictions vs users where
non-cooperative operation is necessary. I would (and I believe a
consensus-level of individuals involved in DNS would) prefer that those
modes are only engaged where strictly necessary, and that to the greatest
degree possible,  client and operator implementations are able to recognize
when they are not in those particular places/networks, and block hostile
operation (to prevent exploitation by e.g. malware).

I'm glad we at least have these options now.
Lets work together to ensure the best outcomes are achieved, and that we
avoid situations where "camps" cannot find a middle ground.

Brian