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

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 21 March 2019 22:29 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 7B1D2124BAA; Thu, 21 Mar 2019 15:29:27 -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 jjVRm5zHLCPL; Thu, 21 Mar 2019 15:29:25 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 0F84C124B16; Thu, 21 Mar 2019 15:29:24 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id k2so506041qtm.1; Thu, 21 Mar 2019 15:29:24 -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=AGPZD6eh8W23qH5JFcBXcsEPFu/xlURzHeTMV8SMZns=; b=oJeEJFHcq/3gkLt/xFKipsyBDscb0eFT7iuhiJwrHlqofnw8SikGp+MD10BM7LOJo0 mPAuDNMlrjUjhrW3GBdFsHcKJPF5/m7hOYvDZJI+KWYKKWlT21xX5Sce9wnAxxUOgQwM hD6jcwpGa2E6tjvn3LCZHOcN/7D65fGm2dTwb8natpRI683UOkoz8AG2oosOJ0cele+4 98Xdv2mdz7O4Qm7gbYA/mUBAR3UoQQozKdicTCzbNTvUCKEHpbUJOFqRS5WAKv7+3qij Sr9Fmy+R6jpla7To8MDE9mS0KapJUKr5Ma6Sfg+36sIpcD2ZIlGwhqPjSJud3GyVYzfk ypjw==
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=AGPZD6eh8W23qH5JFcBXcsEPFu/xlURzHeTMV8SMZns=; b=PzoEzP2BmsQlIKxfye5Ve+5ASP2ZoLCx+9HtlCFZ9ePV7bQ3TlFvf5hixzkj+mjeLk DADdqHnojP/7Y4VY2DsF983p6ZrRn6+/OCVECOnCgZvjty/YSJ/71SH/0KuOZPBemO/j w2nv+/CVUxSwzSjQaTQp2VJnk5EDEVt+FUUFCfZluzqrZKXc2p76xqT2uwPrRLyL0ygm EBgdke0twfxsoj3w0+v0KDJ7aYSQ8x/FCI20hgLFp1DMTfrhqBrDiPNELXNNTLYIR/Bz uqkEtaTZsAKp/0Cdq+bNb6ZDHj/KzPas59x9Hj437/YJRZry0jKl6+kXuDlaBHET0r92 doKg==
X-Gm-Message-State: APjAAAXNJ/x1y+7bFeYnRiz6MRPQCTMZkOhjlRsf8ZHh8lrUr/TtMssT ObF/l6PwkSGu479YS7pu4F5H+zw46eNCtq/7mdg=
X-Google-Smtp-Source: APXvYqxrt6G5OvoJK+uH1cSw0UQnDmcMb+WrJu0HpO1jGxFzx73XnglN93W1Wiqgg/YaFW4rt70OgOiAMKsBgmToEtE=
X-Received: by 2002:ac8:1707:: with SMTP id w7mr5194975qtj.324.1553207364165; Thu, 21 Mar 2019 15:29:24 -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> <5F768C24-4ECF-4369-9D51-B90C4426409B@fl1ger.de> <428d5ff2b5704cdf956a5919e330e4dc@cira.ca>
In-Reply-To: <428d5ff2b5704cdf956a5919e330e4dc@cira.ca>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 21 Mar 2019 15:29:12 -0700
Message-ID: <CAH1iCir4A9Af5FfG4YqiqxjEHDYmqdFZLwa6+Y6HJwLTM0id8w@mail.gmail.com>
To: Jacques Latour <Jacques.Latour@cira.ca>
Cc: Ralf Weber <dns@fl1ger.de>, Ted Hardie <ted.ietf@gmail.com>, dnsop <dnsop@ietf.org>, DoH WG <doh@ietf.org>, Paul Vixie <paul@redbarn.org>
Content-Type: multipart/alternative; boundary="0000000000003425570584a24546"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oy7J0ZxYcyRyaf-JSH-RVsveDB8>
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: Thu, 21 Mar 2019 22:29:28 -0000

On Thu, Mar 21, 2019 at 3:03 PM Jacques Latour <Jacques.Latour@cira.ca>;
wrote:

> Plus!
> Is anyone looking at adding DoH and DoT servers as part of DHCP/SLAAC?  So
> the local resolver and apps and browsers can go the _appropriate_ name
> resolution resource(s) using the protocol of choice. That would be much
> simpler for default configuration in enterprise and ISP.
>
>
I think that is a good starting place for the side meeting discussion.

However, I think a more expressive configuration might be needed, to
actually provide information to clients for them to configure themselves
and/or make decisions.
E.g.: In DHCP, provide one or more of the following kinds of announcements
or assertions:
- ISP does not allow use of DoH to off-net providers (aka DoH:NONE)
- ISP allows use of DoT to off-net providers (aka DoT:ANY)
- ISP provides a DoT server which inspects DNS queries and/or answers, but
does not record or export any information (aka DoT:<IP>,PRIVACY:YES)
- ISP provides a DoH server which inspects DNS queries and/or answers, and
records and exports per user data, keeping data for N days (aka DoH:<IP>,
PRIVACY:NO, RECORD:N)
- ISP provides validating DNSSEC UDP only (aka DNSUDP:<IP>, DNSSEC:VALIDATE)
- ISP provides non-validating DNSSEC UDP, allows TSIG (aka DNSUDP:<IP>,
DNSSEC:NOVALIDATE, TSIG:YES)
- any other relevant stuff (DNS cookies, TCP stateful, all the newest and
shiniest stuff.)

- Then, a client could pick and choose among available options, based on
some kind of pre-configured preferences, like REQUIRE:PRIVACY,
PREFERENCE:DoT,DoH,DNSSEC,DNS, USE:TSIG, BLOCK:RECORD.

I realize, expressiveness adds complexity. However, it does avoid
assumptions and overloading.

The main criteria is agreement on client vs server (i.e. standardize this
stuff), and possibly also add the network as another party involved (for
upstream transit ISP vs local ISP), if they have differing policies for
allowing offsite/third-party DoH or DoT.

Brian



> >From: DNSOP <dnsop-bounces@ietf.org>; On Behalf Of Ralf Weber
>
> >You can not get on a network with at least trusting some of its
> infrastructure, be
> >it SLAAC or DHCP (which BTW both carry information for DNS resolving). The
> >question is where you draw the line and IMHO DNS or name resolution is a
> basic
> >network function and not an application setting.
> >
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>