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

Warren Kumari <warren@kumari.net> Sun, 10 March 2019 06:49 UTC

Return-Path: <warren@kumari.net>
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 5C9D5126DFA for <dnsop@ietfa.amsl.com>; Sat, 9 Mar 2019 22:49:36 -0800 (PST)
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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 1wie3A3oum05 for <dnsop@ietfa.amsl.com>; Sat, 9 Mar 2019 22:49:33 -0800 (PST)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 ED6BA126C15 for <dnsop@ietf.org>; Sat, 9 Mar 2019 22:49:32 -0800 (PST)
Received: by mail-qk1-x735.google.com with SMTP id s26so972258qkm.10 for <dnsop@ietf.org>; Sat, 09 Mar 2019 22:49:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EJZXriF7XDqk/0NZqUGa3Wi3ka+QTfXbVGL8JbOsK1Q=; b=ebrnYWx9eU2lpSitzqgItc99nGJiQdgBZPYjMq1BZBanIfxQbqJ00u1KvHSVRR+Fhk BNIn2pmxnKNyyr7wIQ5CsrCh6PQu75lrtMkrQbLscRzebiqPzKAdHT4STVxlSF4I+MXx r3C8087bMCN/y53l3YXPTUbeKP0foCfdjR7RJIXQA97m9tkSwhoaBjHPdY4e500IidZz avTC8QH2IP2F4e1wb/B+leSeyzvpIoDcAoC+uJJPLYNqz+zgUad4cYOsotd3qnkqro7f uTbOZRQKj0JDhX2OjrEwMYKhZTnqDtq8MCWut2DQ0ebgu3NjuhSz1bWmNBJ0UF7lGTO2 fuow==
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=EJZXriF7XDqk/0NZqUGa3Wi3ka+QTfXbVGL8JbOsK1Q=; b=eaf8FWAtrsTDVO6BYKXMrXOeJlI334i606jezpbF+VrSNhcW45jzrg3Uj4DYlZhaxe v/EZ0dPKnk4GqKUcXI4szuhdIxfTE/vaO0RBqfuUL1LMXlEmvnm8v0LUgp50RsCLRvgZ ittNxkm33QBm+ewNOexBihaX5jO6Z7120rNhLsG4JktvGnK+uuZdYfA80Vrd5G7oF2ZE 0+3JWGLxqrgxbcuFHiF0teb7v/h3E6nsdDXEx+KEUPsNydXoN8kCfNZMkGYo1dBH3trY Bu8tkUfotXpcZhB1t0aE+q7pgH8+iGwDxCbiGsz5uYtbYZdgQ/0a88fsPGhk/4169smM wv5w==
X-Gm-Message-State: APjAAAUUP3H0YjJNgAqx8ldQu8yP4cRqSwykTNxDIbHdWvZlJj06LVbL YkMgO1oo1K9cMDidncu6JVla1Slr2ra2U/qmX4dX3w==
X-Google-Smtp-Source: APXvYqzSsZRqcKGn2BWOebZZ9X7+Bo9Tra4afzzYXLU58IDmUzf2sdCBwluHcGuOMKD8XF/aZWMNiHxhHbb516fReqk=
X-Received: by 2002:a37:c50f:: with SMTP id p15mr907375qki.278.1552200571672; Sat, 09 Mar 2019 22:49:31 -0800 (PST)
MIME-Version: 1.0
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <FACB852B-4BC4-4234-A728-9068708EFB10@rfc1035.com>
In-Reply-To: <FACB852B-4BC4-4234-A728-9068708EFB10@rfc1035.com>
From: Warren Kumari <warren@kumari.net>
Date: Sun, 10 Mar 2019 15:48:52 +0900
Message-ID: <CAHw9_iKc5_i+rC-oOe3RJufFe_Jm3GmTN4UbQ6VLpcqodR8d9g@mail.gmail.com>
To: Jim Reid <jim@rfc1035.com>
Cc: DoH WG <doh@ietf.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b1f2c60583b7db8d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GaO9UDiVCeAzCKxbPt5V1D9N450>
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: Sun, 10 Mar 2019 06:49:36 -0000

[ + DNSOP]

On Sun, Mar 10, 2019 at 12:31 PM Jim Reid <jim@rfc1035.com> wrote:

> FYI colleagues. The draft below has just been submitted. I've been given
> 10 minutes of WG agenda time at IETF104.
>

I haven't given this a full review yet, but I'd like to note that almost
all of this is about concerns around applications (including browsers)
deciding to use their own name resolution and bypass the system resolver,
and that very little of this document is actually about DoH itself.

I think it would be very valuable to not conflate DNS-over-HTTPS (the
protocol) with the "applications might choose to use their own resolvers"
concerns.
As an example:
" For most users, DNS resolution is
      currently part of the service provided by their ISP.  With DoH,
      users can be expected to rely on DoH service providers and are
      likely to have no business or contractual relationship with those
      providers."

This about the latter, and I *really* think that this is not helpful to use
the term DoH to refer to it -- applications have always been able to write
code to bypass the system resolver if they had chosen to - for example
apps, including browsers, could have equally done this with "plain DNS",
DNS-over-TLS, DNS over foo, etc. As an example it appears that the NetFlix
apps have been bypassing the system resolvers sinde before the times of
DoH. Yes, the Mozilla / CloudFlare experiment used the DoH protocol, but it
could queally have used DoT, DNS over IPSec, $whatever.

I encourage discussion of the concerns and what the implications of
applications doing their own DNS are, but they are different to the DoH
protocol - please do not conflate / confuse the two.
Someone (it may have been Vittorio Bertola) coined the term DNS-over-Cloud
(DoC) to refer to the deployment concerns - while I don't think it is a
great term, it is much better than  using the the term DoH to refer to all
of:
1: the protocol,
2: the deployment concerns,
3: "resolverless DNS",
4: the loss of visibility from encrypting the DNS

Also, I think that this topic would be better discussed in the DNSOP WG -
the DoH charter (https://datatracker.ietf.org/wg/doh/about/) talks about:
"The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS clients (e.g.,
operating
system stub resolvers) and recursive resolvers."

While it does say:
"The working group will analyze the security and privacy issues that
could arise from accessing DNS over HTTPS. In particular, the working
group will consider the interaction of DNS and HTTP caching."
it goes on to say:
"In particular, DNSOP will be consulted for guidance on the
operational impacts that result from traditional host behaviors (i.e.,
stub-resolver to recursive-resolver interaction) being replaced with the
specified mechanism."

So can the document please be updated to discuss either the DoH protocol
*or* the larger issues - and if the latter, this document / discussion
should happen in DNSOP.

W


> > A new version of I-D, draft-reid-doh-operator-00.txt
> > has been successfully submitted by Jim Reid and posted to the
> > IETF repository.
> >
> > Name:         draft-reid-doh-operator
> > Revision:     00
> > Title:                DNS over HTTPS (DoH) Considerations for Operator
> Networks
> > Document date:        2019-03-10
> > Group:                Individual Submission
> > Pages:                17
> > URL:
> https://www.ietf.org/internet-drafts/draft-reid-doh-operator-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-reid-doh-operator/
> > Htmlized:       https://tools.ietf.org/html/draft-reid-doh-operator-00
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-reid-doh-operator
> >
> >
> > Abstract:
> >   The introduction of DNS over HTTPS (DoH), defined in RFC8484,
> >   presents a number of challenges to network operators.  These are
> >   described in this document.  The objective is to document the problem
> >   space and make suggestions that could help inform network operators
> >   on how to take account of DoH deployment.  This document also
> >   identifies topics that may require further analysis.
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf