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

Sara Dickinson <sara@sinodun.com> Tue, 07 April 2020 16:13 UTC

Return-Path: <sara@sinodun.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 0BCA43A0DE6; Tue, 7 Apr 2020 09:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=sinodun.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 7v8FlgHUmVF0; Tue, 7 Apr 2020 09:12:57 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F893A0DEB; Tue, 7 Apr 2020 09:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=yOomCjKiThtfhHNxZvOvaCpKxM+VHmxQaVk1+FUte64=; b=PQiZvMV/W4VgpqFYVMmKXLNTOp x8EDVCGuIuHRdVX9RxkMeZBIxwTfnJf9lG2bSru8V+pIS7+kILXy0H4RHz3dViiBpg5CQGNFeMiSW NfP23/BcWTi2o2TnEXPyxmqznKte9jn76ggSblDfIWqfiPh7WMfKCd3q/uJ+nQ4MqNF/pi499aZsQ oZ3QdpiqrdyNhHgbArw9lMLH4iS5NEs2TvicupI4FFV4gVdHU4BzIRC42vB92ySHM9xjiYR7YchTl rYPfa8z37ppT8etHvvSvs6onzGrgIsvuhShOwNXiJwLI7lf4Ka6r/7Gw8xjqQYD30kzuvzlVHVdI2 4U+BXxLQ==;
Received: from [62.232.251.194] (port=32751 helo=[172.27.240.4]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1jLqqG-0004H1-Et; Tue, 07 Apr 2020 17:12:52 +0100
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <C03AC6C2-9DCB-448A-B906-3062BD616E31@sinodun.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2BA1CD3D-A296-46F3-A6A1-622770196F27"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Tue, 07 Apr 2020 17:12:47 +0100
In-Reply-To: <CABcZeBNi2LKvGFcmTM0uC+rFEVm5tgw6Zo1LS_CoO5=Zo0zqSA@mail.gmail.com>
Cc: Vittorio Bertola <vittorio.bertola@open-xchange.com>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, "draft-ietf-dprive-rfc7626-bis@ietf.org" <draft-ietf-dprive-rfc7626-bis@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "dprive-chairs@ietf.org" <dprive-chairs@ietf.org>
To: Eric Rescorla <ekr@rtfm.com>
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>
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/72wp0c1iI1sgfH6_72qtdd-hws8>
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: Tue, 07 Apr 2020 16:13:00 -0000


> On 7 Apr 2020, at 16:47, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
> On Tue, Apr 7, 2020 at 8:40 AM Vittorio Bertola <vittorio.bertola@open-xchange.com <mailto:vittorio.bertola@open-xchange.com>> wrote:
> 
>> Il 07/04/2020 17:23 Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> ha scritto:
>> 
>> 
>> 
>> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < sara@sinodun.com <mailto:sara@sinodun.com>> wrote: 
>> The goal of this text is to enumerate for the end user the privacy considerations of using such an application so I propose this text: 
>> 
>> "For users to have the ability to manage the application-specific DNS settings in a similar fashion to the OS DNS settings, each application also needs to expose the default settings to the user, provide a configuration interface to change them, and support configuration of user specified resolvers.  
>> 
>> If all of the applications used on a given device also provide a setting to use the system resolver, then the device can be reverted to a single point of control for all DNS queries. If not, then (depending on the application and transport used for DNS queries) users should take note that they may not be able to inspect all their DNS queries or manage them to set device wide controls e.g. domain based query re-direction or filtering. “
>> 
>> I don't think this addresses my concern, because "revert" implies that this is somehow the default situation, which, as I said, is not clearly the case because applications have been doing their own resolution for some time.
>> 
>> In the interest of moving forward, i suggest you change the term "reverted" to "configured" and add at the end "Note that this does not guarantee controlling malware name resolution as it can simply ignore whatever the system resolver and any user configuration settings.."
> I don't understand where in the proposed text there was a reference to malware that prompted further discussion of the effectiveness of using DNS to counter it. In any case, if we think that we need to discuss this topic at that point in the draft, one should also note that there also are ways to prevent malware from reaching a different resolver, though they are less likely to work once connections are encrypted, etc. But I think that this would make reaching consensus even harder, so perhaps we could avoid doing so and just focus on suggestions related to application configuration.
> 
> Well, I would be happy to strike this text entirely. However, the text speaks of "control" and if we're going to say that, we should acknowledge that the system DNS is not going to let you control malicious applications because malware can just do its own resolution. As it is, I think the text gives a false impression 

How about making the last sentence a little more specific instead:

If not, then (depending on the application and transport used for DNS queries) users should take note that they may not be able to inspect the DNS queries generated by such applications, or manage them to set consistent application-level controls across the device for e.g. domain based query re-direction or filtering. “

Sara. 

> 
> -Ekr
> 
> -- 
> 
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bertola@open-xchange.com <mailto:vittorio.bertola@open-xchange.com> 
> Office @ Via Treviso 12, 10144 Torino, Italy