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. > > >
- [dns-privacy] Datatracker State Update Notice: <d… IETF Secretariat
- Re: [dns-privacy] Datatracker State Update Notice… Eric Vyncke (evyncke)
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Vittorio Bertola
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Vittorio Bertola
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Brian Dickson
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Stephen Farrell
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Vittorio Bertola
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Brian Dickson
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Brian Dickson
- Re: [dns-privacy] Datatracker State Update Notice… Jim Reid
- Re: [dns-privacy] Datatracker State Update Notice… Brian Dickson
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Tony Finch
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Vittorio Bertola
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Eric Orth
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Eric Orth
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] [EXT] Re: Datatracker State Upd… Vittorio Bertola
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Eric Vyncke (evyncke)
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Eric Rescorla
- Re: [dns-privacy] Datatracker State Update Notice… Sara Dickinson
- Re: [dns-privacy] Datatracker State Update Notice… Christian Huitema
- Re: [dns-privacy] Datatracker State Update Notice… Vittorio Bertola
- Re: [dns-privacy] Datatracker State Update Notice… Stephane Bortzmeyer
- Re: [dns-privacy] Datatracker State Update Notice… Stephane Bortzmeyer
- Re: [dns-privacy] Datatracker State Update Notice… Ben Schwartz
- Re: [dns-privacy] Datatracker State Update Notice… Vittorio Bertola
- Re: [dns-privacy] Datatracker State Update Notice… Vittorio Bertola
- Re: [dns-privacy] Datatracker State Update Notice… S Moonesamy
- Re: [dns-privacy] Datatracker State Update Notice… Andrew Campling
- Re: [dns-privacy] Datatracker State Update Notice… Andrew Campling
- Re: [dns-privacy] Datatracker State Update Notice… Christian Huitema
- Re: [dns-privacy] Datatracker State Update Notice… Brian Dickson
- Re: [dns-privacy] Datatracker State Update Notice… Rob Sayre