Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>

Eric Rescorla <ekr@rtfm.com> Mon, 11 May 2020 12:56 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB553A0A99 for <dns-privacy@ietfa.amsl.com>; Mon, 11 May 2020 05:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 RnJcKL8PCPM7 for <dns-privacy@ietfa.amsl.com>; Mon, 11 May 2020 05:56:43 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 B06733A0A94 for <dns-privacy@ietf.org>; Mon, 11 May 2020 05:56:42 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id u15so9358730ljd.3 for <dns-privacy@ietf.org>; Mon, 11 May 2020 05:56:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U4wa0BFPgF9xlRJ/IlmwpP4+fp64wjuY9nO770JSvTg=; b=Xe98Nn+7c32ihgx9cUga/OI1GTxxDHcdQz9K/tDojablS8MQyApzyCNXBYNrEQQ+oo FhkFyQ1veeePtwAh+qT4CfPhup682vnNJpWkQzAZHqu8A/Rr+OT72Dl+AndrN0YbX+97 9brsWpylnQ6ws4Lc94DzQmzXyZh47TGaeshdGTl+wMkUXv4Q1GM+FaK6n8ENaQ1yt2Wr Xbhz93SKhW5FrYc829y4DkMcJ2iMrXN4BLKATnuPwqX/1313Hp2NqIezD6LHQN7BlbQd MqUGndo2IOsL2AMVra6zgOBi5oPibH8kJfW+kWnJDQqNrAfRQpVf2H5u32EYkKvhC9Wy +KeA==
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=U4wa0BFPgF9xlRJ/IlmwpP4+fp64wjuY9nO770JSvTg=; b=s8S1QEFz5HgBtIoyh2OGiJNRU5nTOBLUdglpbSj4yfHHZeq57vTaRKxT6/bObv0ZXI IsGJ81fgyXmjyExXy3wM3BNGidjBmGv0O87a0R9wKlrIO16UPYBSKGNjL0WtBMA79ANi hHEX6EaHUtC2rx3JVvqITBLWtDtm+Emaeer5DVrUCdnw8RRqu0f8xSC49p0EMzc/xsfQ fUzjSUVkD0TguomL6YEHirCFZhnUAGlWubxwSTYT7MmUvc8e3NC1zBn1TmansKjdP5B/ zGi9M8Bs3IIDbHUynwTZcTN6vFf9n63ZtYycaQ9jMeJJY91pk925kizOmK2VW4zLG6Cs D2Zw==
X-Gm-Message-State: AOAM531x3ZEhTEaun6R3Rgh78LOLLax6OSbMDfb3Yowli3Qw2t1Bxh+X TOeAUTuFUm6SumnW48ev4nAXDqaczCRF+b1y3dyzqg==
X-Google-Smtp-Source: ABdhPJxcp76wrSD6Xon/Ry1nS7J6MJwRbcGF9DDK16U1oxKNu8ged5+nuQU45SXPHAkPaqFWy08aIeAzYx8OFKhfw70=
X-Received: by 2002:a2e:a552:: with SMTP id e18mr276684ljn.162.1589201800907; Mon, 11 May 2020 05:56:40 -0700 (PDT)
MIME-Version: 1.0
References: <157955609351.1744.15099511006231348523.idtracker@ietfa.amsl.com> <417BE033-4DE5-452A-BE93-0657C83051BC@cisco.com> <CABcZeBPK3yAaoai4ccd=hSffk5cAhoSC7gnBNqs36x-xJf=R-Q@mail.gmail.com> <503E2696-AB4A-4020-90CC-802D312D23AF@sinodun.com> <CABcZeBOiEu8qO_VHtHc7Fs47Wh0tGDn3ywM5LDZtWoxuHZ_isw@mail.gmail.com> <721AD54C-0324-4400-8492-4AA19A64699D@sinodun.com> <CABcZeBP4CknS=9Y96CqgykChg4H_jrgkaWmHPN4319+nXe=10w@mail.gmail.com> <CAH1iCiobuYitR26Hh0pbYpA_JZoB1a1iMyHJs1FAgW9GtOk56g@mail.gmail.com> <CABcZeBNa-OTEYjnL=+-F=WK3hZiOWmty1S=FC43Fr3CxuCPE_g@mail.gmail.com> <32D26638-2464-4E7B-8869-C65F773EF5F2@sinodun.com> <CABcZeBNnAZ1ttKHdtZMwWZGvWAYn3jZBps+hXOBMHQXgaKPUEA@mail.gmail.com> <00AF0382-CD8B-46F3-9838-50602379FE9F@sinodun.com> <CABcZeBOELM=d0xXgYN+r4cNsRO6=oyQscdwwdSTqypV5gNra0A@mail.gmail.com> <F6C06842-9D76-45DF-84A0-B0C4D724E66E@sinodun.com> <CABcZeBPVocy593=WJM2k3Ytrwg36qc_1d4VQH3otRM5qyvZwLA@mail.gmail.com> <1388052392.1781.1586274052101@appsuite-gw1.open-xchange.com> <CABcZeBNi2LKvGFcmTM0uC+rFEVm5tgw6Zo1LS_CoO5=Zo0zqSA@mail.gmail.com> <C03AC6C2-9DCB-448A-B906-3062BD616E31@sinodun.com> <CAMOjQcGrWXFpStp=iVbo1jVN3qnen8rC71SyXv6evY2-MgUdxg@mail.gmail.com> <3345FB83-A19A-4542-8A8E-C535884B157F@sinodun.com> <CABcZeBPP6J=a=hW6BLcMnKawupa3RjjpYAzgZ317=ryLy39n+A@mail.gmail.com> <8CEFE3CB-A88C-4BBC-95B8-9850142DB5EE@sinodun.com> <CABcZeBPF41eq-HYXdYScx7bqYyUO7-oH6zWKqj7Ka23u8x_E4A@mail.gmail.com> <ACA9854E-00B7-4776-A850-E5069C672121@cisco.com> <CABcZeBOxN7iNTLFUw7JDc4ZGH_u4awys3g52de29CuOyQv2JUQ@mail.gmail.com> <C8B168D0-F719-405F-892F-14573A7C568D@sinodun.com>
In-Reply-To: <C8B168D0-F719-405F-892F-14573A7C568D@sinodun.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 11 May 2020 05:56:04 -0700
Message-ID: <CABcZeBPGAgqSPKWXKaL6kK5CYzgK+RmwFrMwhc6ED7aGnV_ayA@mail.gmail.com>
To: Sara Dickinson <sara@sinodun.com>
Cc: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "dprive-chairs@ietf.org" <dprive-chairs@ietf.org>, "draft-ietf-dprive-rfc7626-bis@ietf.org" <draft-ietf-dprive-rfc7626-bis@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d1dcdb05a55ee0e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/pK8Ioxh4fjsYwr_tiQwlQqeaVL8>
Subject: Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2020 12:56:46 -0000

On Mon, May 11, 2020 at 5:34 AM Sara Dickinson <sara@sinodun.com> wrote:

>
>
> > On 7 May 2020, at 17:41, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > Extensively trimming:
> >
> > To be honest, this thread has gotten so long that I've lost
> > track of the various changes being proposed, so here's
> > my comments on the text as a whole.
> >
>
> To be honest, I really thought we had pretty much converged on some text
> that had consensus for this section...
>

As I said at the beginning, i think it's generally problematic, for the
reasons below, but as you insist on keeping it, I'm giving it a close read,
and in that context, this framing is problematic.


> > > "An increasing number of applications are offering
> > > application-specific encrypted DNS resolution settings, rather than
> > > defaulting to using only the system resolver.  A variety of heuristics
> > > and resolvers are available in different applications including
> > > hard-coded lists of recognized DoH/DoT servers.
> >
> > As I said earlier, I think this text is highly misleading.
> > There are at least two major loci of filtering via DNS:
> >
> > 1. In the operating system itself via the system resolver
> >    or hooks into that resolver.
> >
> > 2. In the network via (a) the selected resolver or (b) on-path
> >    filtering of the traffic to/from that resolver.
> >
> > There are least three major application resolution technologies that
> > render one or more of these techniques ineffective:
> >
> > 1. Using an application-level resolver which uses the system settings
> >    [what Chrome currently does] bypasses (1)
> >
> > 2. Using an application-level resolver which uses DoH/DoT to the
> >    system configured resolver [what Edge and Chrome are experimenting
> >    with] bypasses (1) and maybe 2(b) if the network config gets out of
> >    sync (i.e., you don't want your system configured resolver to do
> >    DoH/DoT if you use network-level filtering, but it's easy to see
> >    how this can happen if (for instance) you just offer the the user
> >    the ISP resolver and they start supporting DoH/DoT
> >
> > 3. Using an application-level resolver which uses DoH/DoT to
> >    an application-selected resolver [as in the Firefox TRR
> >    system] bypasses all of these.
> >
> > The key point is that a lot of filtering is broken by reasons
> > that have nothing to do with encrypted transport, and so
> > this text is misleading.
>
> Somewhat confused here.. the text you quote above does not mention
> filtering at all, was added in version -04 published in January and wasn’t
> referenced at all in your first review of -04. Are you now saying you want
> this specific text reworked?
>

The problem isn't this text specifically, it's that it's used in context
for a section talking about how DoH and DoT interfere with filtering, but,
as detailed above, that's only part of the story.



> > > For users to have the ability to manage the DNS resolver settings for
> > > each individual application in a similar fashion to the OS DNS
> > > settings, each application would need to expose the default settings
> > > to the user, provide a configuration interface to change them, and
> > > support configuration of user specified resolvers.
> >
> > This seems sort of true, though of course in some systems (I don't
> > know how common this is in the world of mostly single-user computers)
> > users actually can't change the system resolver settings.
>
> We previously agreed text in section 6.1.1 that says both:
>
> “ All major OS's expose the system DNS settings and allow users to
>    manually override them if desired."
>

Yes, this is true as well.

>
> “The vast majority of users do not change their default system DNS
>    settings and so implicitly accept the network settings for DNS."
>

Yes, I think this is true.


Getting into user specific authorisations around this isn’t something that
> has been proposed in any comment before and I’m not sure how useful it is
> at this point?
>

Well, the issue is that this text is being used to contrast
application-specific settings to OS ones, so I'm not sure how not to get
into it.



> > > The system resolver resolution path is sometimes used to configure
> > > additional DNS controls e.g. query logging, domain based query
> > > re-direction or filtering.
> >
> > This conflates the network and in-OS filtering discussed above,
> > which I really think needs expansion.
>
> Suggest:
>
> “The system resolver resolution path is sometimes used to configure
> additional device based DNS controls (distinct from any controls
> implemented at the network level) e.g. local query logging, domain based
> query re-direction or filtering."
>

Well, I agree with this parenthetical, but then it just reinforces my point
that this not being about *encrypted* DNS but rather about
application-specific DNS, because this text then becomes about method (1)
and therefore implicates any application-level resolver, encrypted or not.


> >
> >
> > > If all of the applications used on a given device can be configured to
> > > use the system resolver, such controls need only be configured on the
> > > system resolver resolution path. However if applications offer neither
> > > the option to use the system resolver nor equivalent
> > > application-specific DNS controls then users should take note that for
> > > queries generated by such an application they may not be able to
> > >
> > > * directly inspect the DNS queries (e.g. if they are encrypted), or
> > >
> > > * manage them to set DNS controls across the device which are
> > >   consistent with the system resolver controls.
> >
> > OK.
> >
> >
> > > Note that if a client device is compromised by a malicious
> > > application, the attacker can use application-specific DNS resolvers,
> > > transport and controls of its own choosing. »
> >
> > This seems opaque. Why not say "then any DNS-based controls may be
> > ineffective.”
>
> Will add that at the end of the sentence - this text was trying to be
> consistent with the similar text you earlier proposed for the similar case
> in section 6.2.1. “ In addition, if the client is compromised, the attacker
> can replace the DNS configuration with one of its own choosing."
>

Sure, I'm fine with my  phrasing as well, but trying to expand it out as
you have (especially by adding 'controls') is confusing.

-Ekr


> Sara.
>
>
>