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

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 13 March 2019 20:29 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 D16731311BF; Wed, 13 Mar 2019 13:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 2xLZbcxYxqZ7; Wed, 13 Mar 2019 13:29:52 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 E7AD11311AC; Wed, 13 Mar 2019 13:29:51 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id n6so1976181qkf.1; Wed, 13 Mar 2019 13:29:51 -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=OHiuMaBnn3sxOM0p53JNZ2hsd3awsaCKexj+OAxXACo=; b=ZrW26DrdlFY4tuYJkQwUzhjD1dc1enqDZDE1r7gyMb7gHWrSN2VRQ5swhqLMBZQKwF nIvIABeJW8Aj2Z8zKBMqNDC8jzqNgf1da1Of31qRUuTbFsPcSP8ahyUmVxFistxwUikR Ds9KWPyC0n7m1Npg6ym4Kd8Qm1rl4bQmNuhJPl7o+H5uwCFc5cJg+gGRt1fU+48pXvA+ ygmV1BJp806LvymY82363RWvjedS8QO1f8Gt03wCzb4opmnEI50ekwAyhJUZEV6SKcDo i2AS+EdWU86UA1rTTAEpCZArhU1cckiD4HyGtgwTYioZ9oQgs/lPUARCy9d/+FqoEHFg /kFQ==
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=OHiuMaBnn3sxOM0p53JNZ2hsd3awsaCKexj+OAxXACo=; b=bHdF/ph4CKVbb9uFNaILPUso4NRO27HMjPvdBqLtJx2QZWpVQEtxV/ccWPP1s/0pue O+oRCZOb5mRUdyVmMV2O0+63wMsqmy3rHsqw4enIc52NBp2DpOYqG2LG9HyctL4eBybx 2nBFDU2krbg2h66vAs5LVuANAsWxR4y16DcEDZUUxugF0ObXn+NbyoRaVR8f2qNEOx1N 5Sg1iE9RCsJ7VyXkLtWbkh/Jf+I4CEQVruyLcq4zqPhusGmclqyoow1+pwFrCuKg/Qgv KSkYEDc7CWuXW7WmKFaLVhcMwFmMdRQgKrb7AaVuPb6S3zdJQqVB2fBGQM2WNHAAm261 fxsA==
X-Gm-Message-State: APjAAAW3DI8yoB1PU5F48DomZL2FCCkYf0HHHpqXe9VGu4EadK9fTe1B NW4rUMDvwLsuwj90hk1eJYkwrvhYq+PqTCfqmIk=
X-Google-Smtp-Source: APXvYqwZYbC7j63Oov63pzYU802EDWtk5y9B5y/1iGfaw8cp6DFPgw86Vz+H07UOy8dqDjQ4s5QIlKwRAypPFkOtLKo=
X-Received: by 2002:a37:d6ce:: with SMTP id p75mr15063034qkl.286.1552508990888; Wed, 13 Mar 2019 13:29:50 -0700 (PDT)
MIME-Version: 1.0
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <76386691-c1aa-c48a-9b0d-67eb36a08a4f@redbarn.org> <CABcZeBOWM0Ps-j3V-CK6VPy0LAqeo7-t7odUZy+dk9d-oCSDsg@mail.gmail.com> <4935758.NkxX2Kjbm0@linux-9daj> <c2c2be47-0855-a9d1-dd53-2404edf4d02b@huitema.net> <807193999.19916.1552445819087@appsuite.open-xchange.com> <9e40ac38-fa10-bbdc-1bfc-302e0ca170df@huitema.net> <C72A7196-98CF-40DC-84C7-DA95BADD24B8@cable.comcast.com> <b52e7891-da9f-6972-fc42-bf3aeea0a10f@huitema.net>
In-Reply-To: <b52e7891-da9f-6972-fc42-bf3aeea0a10f@huitema.net>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 13 Mar 2019 13:29:28 -0700
Message-ID: <CAH1iCioc7xbMRnfzukFNK+RE7ScFru8xEk32F=XbR0Mo+E371w@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: "Livingood, Jason" <Jason_Livingood@comcast.com>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "doh@ietf.org" <doh@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e99f350583ffaae8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/iMS_uayn2JqJ7EXg198wn-q5uyM>
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 20:30:01 -0000

On Wed, Mar 13, 2019 at 12:18 PM Christian Huitema <huitema@huitema.net>
wrote:

>  But then, if the user has not opted in such system, it would be nice if
> the ISP refrained from interfering with name resolution for that user. How
> do we achieve those two goals in practice?
>
> -- Christian Huitema
>
Even that starting point is not accurate or correct, IMHO, at least for
scope, or whether/how any given DoH implementation interacts with the
user(s).

Jason was suggesting that there are (or at least may be) multiple levels of
ISP and/or Enterprise and/or controlled (parental) stuff; those might nest
with no "naked" root (unfiltered) depending on the particular ISP, or
mandated legal thing, or "public" offering doing anything questionable.

Notwithstanding any desire to have users use DoH to arbitrary endpoints, in
some environments (enterprises) or regulatory environments (western
countries which have different restrictions on legal contracts and user
acceptance stuff.

This means that it is NOT the case that EVERY potential deployment
environment is going to be compatible with a DoH client that bypasses any
controls that might be present, without violating laws, contracts, or other
controlling limitations.

The starting place for the conversation needs to acknowledge this, and
accommodate it. It is entirely possible that a DoH client that doesn't do a
minimum level of getting user acknowledgement before violating policies,
laws, or contracts, might itself be illegal in some jurisdictions
(jurisdictions that could include some US states, some western countries,
some larger entities like EU, etc.).

This is not to say it isn't going to be the case that users can't "force"
some kind of DoH-like thing, only that it needs to be under some kind of
affirmative control, where a user makes an informed decision with some kind
of explicit understanding/acknowledgement.

It probably would be advisable for DoH implementations to NOT make that
explicit acknowledgement externally visible to e.g. authoritarian regimes,
but that is stuff to discuss/explore, i.e. it's an open question.

It would be very helpful for moving the conversation forward if the DoH
proponents could start with acknowledging this set of legal/contractual
issues, and that any kind of DoH client that just automatically does stuff
that bypasses any mechanisms to restrict DNS, likely isn't known to be
compliant with all laws in all jurisdiction (and probably would be
problematic, at a minimum).

Brian