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

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 11 March 2019 21:33 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 AE91813117E; Mon, 11 Mar 2019 14:33:53 -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 fGRHFBtcJWhz; Mon, 11 Mar 2019 14:33:51 -0700 (PDT)
Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 5D80A131161; Mon, 11 Mar 2019 14:33:50 -0700 (PDT)
Received: by mail-qt1-x844.google.com with SMTP id x20so342560qto.1; Mon, 11 Mar 2019 14:33:50 -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=N8PrV1BYWjXpqUfvPxKM/Uu7Nto79uANGe/F64yWMm0=; b=b152w5kotoKV2U9ysZgQ0k5gH9y1Atr82UMJTLDN2q4F2Mc6s2rFaVDdesC1kGx6Si ZpqkkSWBm5V30bqldtZKGNDqJvkWDoRlAuno+0kis1UhQ8SjxRfz0sO61C3ftBxyzy5D HQ5qNPibL0i3eE4Esex9CEXL+M0rXJhrCCnFGDlAGkDZwD6aflIowUoEYk7tR8ztaGX3 TusoX0XIb8wc25WTQ0PPgJS6z3jowLGStIFni28vrFq1xdHRPtbt9ihRvJtzrTyTu7z0 3tUNsO/gziWUX3x6XupcsXBtu1Da5Wx6YmKscc3p3Zyjl84WKQ5Q28XNo2IzITbGTjDx Nahw==
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=N8PrV1BYWjXpqUfvPxKM/Uu7Nto79uANGe/F64yWMm0=; b=N+OyCOWMHD78w5VOry6VQU80hyW8mxjzIA3x+GWpTjvsG/o5uI0R76UOdrC7Wq349d 0H06aX3H3KTPrpobU+KdP9pG1YpilX4zr90bJbFkxE7aUTDeRXTNhSrxFOGzoo8Igeva 2D/3QbkSeeA9pHRUwubiVbikGBOc1chWWOfKGY37qnK/rz1bd4pZKxLj2JynBC3pRVAB o3cVGXiapa486Bi7eXDao0p+IJ01nkD/m11BLKEyIZ0KNCXRxY7Gyh0fFlrciMv0K1yd 8vFDFXNehopYzkS2oZrGfFBxc6P3qBoHBhx16hPczTQ21GGwFfAxfVMwjew3+cviKFac 6Urg==
X-Gm-Message-State: APjAAAUjTeL3JsVGMClBc/sVkLeJzhMdxNG/2dFnP4upggQW2L/U0Sw/ A/ORTC1LDXyen74sa3kmk1H+QhOMdmZpN9WIxH5mFg==
X-Google-Smtp-Source: APXvYqyIRMM+/IdJcb8KND7Vw2NzrovqtQQgN4AlJgJ3PA/czdtsIoTCGp7wyu2bZzoNp7wRQ53h5NijygroQ9sgpCU=
X-Received: by 2002:a0c:d413:: with SMTP id t19mr529147qvh.8.1552340029421; Mon, 11 Mar 2019 14:33:49 -0700 (PDT)
MIME-Version: 1.0
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <eea64b30-aad0-a030-5360-1b1484f1d0e3@huitema.net> <CAPsNn2WhjHSEHJUEL8GB6X0d24fkajgPnY4YgkOQbXjyxb5q8Q@mail.gmail.com> <e62efaf3-4a35-4a52-5ed4-dee2e7fafe72@huitema.net> <69f989ba-0939-b917-b586-9e3af3fb8b74@redbarn.org> <092c081b-50b2-0c37-7a06-a3bd16c9ccdb@huitema.net> <3e91ec1f-f2d5-a3f1-a40c-5039d24f49b9@redbarn.org>
In-Reply-To: <3e91ec1f-f2d5-a3f1-a40c-5039d24f49b9@redbarn.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 11 Mar 2019 14:33:38 -0700
Message-ID: <CAH1iCirE2-eaSNyCn7LeLvXQcd2xbiQkOP4WEFGb6EpHQH50eA@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: Christian Huitema <huitema@huitema.net>, doh@ietf.org, "dnsop@ietf.org WG" <dnsop@ietf.org>, "Ackermann, Michael" <mackermann@bcbsm.com>, nalini elkins <nalini.elkins@e-dco.com>, dns-privacy@ietf.org, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000063da90583d85495"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/lbUrQ_VCuIb2tCj0-wY4UPiAQws>
Subject: Re: [Doh] [dns-privacy] [DNSOP] 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: Mon, 11 Mar 2019 21:33:54 -0000

(Apologies for top-replying)

I think, from squinting at this a bit, that what is missing is some kind of
policy/service discovery, and coming to some kind of agreement (between
DNSOP and DOH, and any/all other interested parties) on what default
behavior should be (and under what conditions/circumstances), e.g. with
respect to opt-in vs opt-out.

E.g. If the local network operator is giving out addresses using DHCP or
the equivalent, then the presence/absence of DNS options in the answers,
should to some degree dictate (permitted) behavior.
And similarly, having some kind of DoH signaling incorporated in the DHCP
options, would be a sensible analogous mechanism.
E.g. "I will allow you to request DoH using providers X, Y, and Z, but
insist on being a MITM for those connections", or "Go ahead and do DoH to
any of these providers X, Y, Z, but no others", or "DoH is prohibited here,
use DNS", or "You can use DoT to these providers, DoH with me as MITM, or
this DNS resolver, but you can't run your own resolver".

Not sure what other mechanisms might be worth considering as alternatives
(dns-sd of some flavor)...

The mechanisms definitely to be a lot cleaner, more transparent, and
configurable, for both clients, network operators, and possibly DoT/DoH
operators.

(Did we learn nothing from the dial-up ISP early days, with mailing out
physical CD ROMs with phone numbers in lists and browsers included?)

Brian

On Sun, Mar 10, 2019 at 11:17 PM Paul Vixie <paul@redbarn.org> wrote:

>
>
> Christian Huitema wrote on 2019-03-10 23:05:
> > On 3/10/2019 10:24 PM, Paul Vixie wrote:
> >
> >> if you are using my network, then it makes no difference which of us
> >> bought you that laptop. you will use the RDNS i allow you to use. RDNS
> >> is part of the control plane, and i use it for both monitoring and
> >> control. sometimes that's so that i can see malware beacon to its C&C.
> >> sometimes that's so that i can institute parental controls.
> >>
> >> if you don't like my rules, you should vote with your feet, and not
> >> visit me. because that is the only choice you will have. (yes, i will
> >> be part of a major new project to identify and block all DoH services,
> >> so that behavioural security policies can still work, because you may
> >> have noticed that the internet has never become MORE secure from new
> >> tech, but it occasionally becomes LESS secure more slowly because of
> >> policy.)
> >
> >
> > "Use a VPN, or use the local defaults".
>
> that is not what i said.
>
> > Well, there are plenty of
> > in-between.
>
> yes, and i gave examples.
>
> see above.
>
> > You claim the right to impose your rules, because it is "your network".
> > Yet you have to define ownership. You are providing network services
> > under some contractual terms. There are cases where an imperial network
> > can dictate those terms, but there are also many cases in which the
> > contractual power of the network is limited  -- thinks like fair access,
> > network neutrality, etc. Just claiming an empire does not automatically
> > make you the emperor.
>
> my network, my rules. your provider's network, their rules. they are
> more likely to have to follow their government's laws of commerce and
> privacy than i am likely to have to follow mine. but if the rules your
> network operator can make allow you to do what you want, use that
> network. that's invariant, for all networks, and for all instances of you.
>
> --
> P Vixie
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>