Re: [secdir] [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03

Sara Dickinson <sara@sinodun.com> Tue, 07 January 2020 18:35 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88531200F5; Tue, 7 Jan 2020 10:35:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Me8YrLV5C7fZ; Tue, 7 Jan 2020 10:35:17 -0800 (PST)
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 72F4F120131; Tue, 7 Jan 2020 10:35:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=hfUvIUE1/4ouVOvgS0Z8V5cgCp0/JmD276ROKjgQ5DM=; b=X0LoROsEpigOcLCzM1Sx/ywkPY JLXPBdbm1anfNEHBC6zX+QL/j6ARorXhlV3sAJXYgdJtxcHiFcV+nYTJAggCtxQlrXL+rqIcfRWCM OYpgDW4CklI1t95G653023POX+R6cQducgmWJnvf13OEZWv2XFIriG3Au6K+he+gRBx1/JegTBmkC ouBMHrzG/t6RTHxiy4HZz7M3GmbpWhyqoEBzN/QUM2DIaQ9+rMwQg5t6XxCxR34tMnzuvRJlFiQc7 Kc6vAirdAOqJFWA3bqyjNedbdcPodc4KZLegg3m+G8cjlZmBPl5m0HCemJHLfCM3Xqp1nHPyJ55oG MSuLc4jQ==;
Received: from [2a02:8010:6126:0:1d21:ef98:8b8e:dcec] (port=64235) 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 1ioth9-0000pN-38; Tue, 07 Jan 2020 18:35:15 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <20191223220509.GK35479@kduck.mit.edu>
Date: Tue, 07 Jan 2020 18:34:58 +0000
Cc: last-call@ietf.org, DNS Privacy Working Group <dns-privacy@ietf.org>, draft-ietf-dprive-rfc7626-bis.all@ietf.org, secdir@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6C1F0BD-5BAA-40D5-A0E9-B7149DEAA34B@sinodun.com>
References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> <a02720cf-01b3-d61a-94d2-b3d0a399f107@cs.tcd.ie> <20191223220509.GK35479@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_LaZjg4j2KRPKcBYDEqUDFfqO9w>
Subject: Re: [secdir] [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 18:35:21 -0000


> On 23 Dec 2019, at 22:05, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> On Wed, Dec 18, 2019 at 02:00:45PM +0000, Stephen Farrell wrote:
>> 
>> Hiya,
>> 
>> On 18/12/2019 13:45, Sara Dickinson wrote:
>>> 
>>> 
>>>> On 29 Nov 2019, at 15:39, Stephen Farrell via Datatracker <noreply@ietf.org> wrote:
>>>> 
>>>> Reviewer: Stephen Farrell
>>>> Review result: Ready
>>> 
>>> Hi Stephen, 
>>> 
>>> Thanks for reviewing (again)!
>>> 
>>>> 
>>>> I might not be the best reviewer for this one as I've read it a few times
>>>> before. But anyway, I scanned the diff [1] with RFC7626 and figure it
>>>> seems fine. 
>>>> 
>>>> The only thing that occurred to me that seemed missing was to note
>>>> that while the new privacy analysis in 3.5.1.1 is already complex, many
>>>> systems are mobile and hence an analysis that ignores that won't be 
>>>> sufficient. For a mobile device one really needs to analyse all of the 
>>>> possible setups, and hence it's even harder to get to a good answer. 
>>>> (It could be that that's elsewhere in the document but since I only 
>>>> read the diff, I didn't see it:-)
>>> 
>>> There was a bit of discussion about this and the following text in 3.4.1 was added:
>>> 
>>> “ It is also noted that typically a device connected _only_ to a modern
>>>   cellular network is
>>> 
>>>   o  directly configured with only the recursive resolvers of the IAP
>>>      and
>>> 
>>>   o  all traffic (including DNS) between the device and the cellular
>>>      network is encrypted following an encryption profile edited by the
>>>      Third Generation Partnership Project (3GPP [2]).
>>> 
>>>   The attack surface for this specific scenario is not considered here."
>>> 
>>> Which hopefully covers this?
>> 
>> Not really, no. My point is that the analysis in 3.5.1.1
>> doesn't encompass the fact that hosts are often (or even
>> mostly) mobile and hence connect to many networks, and that
>> the results of a privacy analysis related to DoT/DoH will
>> likely differ for each of those networks, from the POV
>> of the user or device owner, and even those two may not
>> agree in some cases.
>> 
>> I don't believe that point is made in the document. But
>> I'm ok that you and the ADs figure out if its needed or
>> not.
> 
> I think some kind of treatment is needed, even if the extent of the
> treatment might still be up for debate.
> 
> Sara: note that "mobile" here is used in the generic sense of "moving
> around", not specific to a mobile or "cellular" pocket computer (aka
> "phone”).

Thanks - I did misread Stephens response - I see the issue now.

As a starting point I would suggest some text at the very beginning of Section 3 along these lines. 

“This section outlines the privacy considerations associated with different aspects of the DNS for the end user. When reading this section it needs to be kept in mind that many of the considerations (for example, recursive resolver and transport protocol) can be specific to the network context that a device is using at a given point in time. A user may have many devices and each device might utilise many different networks (e.g. home, work, public or cellular) over a period of time or even concurrently. An exhaustive analysis of the privacy considerations for an individual user would need to take into account the set of devices used and the multiple dynamic contexts of each device. This document does not attempt such a complex analysis, instead it presents an overview of the various considerations that could form the basis of such an analysis. "

> 
> (I also agree with Ekr that the considerations around 3GPP encryption
> remain not great and would prefer to not rely on them.)

I think the idea of the above text was to show there is an orthogonal but out of scope issue with 3GPP encryption, not to make any judgement on it as a technology. Are you saying that the document should make an explicit statement something like ’This form of encryption should not generally be considered secure but an analysis is out of scope for this document. The attack surface for this specific scenario is not considered here.’?

If I have misunderstood, please suggest some text to be used here.

Sara.