Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

"Martin Thomson" <mt@lowentropy.net> Thu, 02 January 2020 01:04 UTC

Return-Path: <mt@lowentropy.net>
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 5CFC11200E5; Wed, 1 Jan 2020 17:04:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=lowentropy.net header.b=LhE/ubj9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Icy/HuXD
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 u5G19gkxvhTC; Wed, 1 Jan 2020 17:03:59 -0800 (PST)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7381200DF; Wed, 1 Jan 2020 17:03:59 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C353638F; Wed, 1 Jan 2020 20:03:58 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 01 Jan 2020 20:03:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=Tj snVsZMVslDL2ZSt4jzgC4HynGgUhzSzDiogge30W0=; b=LhE/ubj9Y4c6nSPt5f 2kJUsujcJi4v4SzvGBbcQMyAs/j/EeMXSsBMRR3dYcvScAb9WroKFBCV2TwXFb1f +Xo8bvKpXHiSr0JAR6KLIWFMEMMLRWPxyrS3HjP5Rn4kvR8lh3M8+lMXGom+gNfy mduoZfVltVteKiyH8yPGx8R7xajtFN3ODOW3Hun7CM6B4Unm02iwSQRfQAhB0R7O xACK93rH4xLmzxJl4SkTofHx2W0845mR/yR96EPwPKj9uvcPQel+2EWh4VvIvUdB XKLjWIoUCefwp5HV5Xe5oQ7dHTrfVh9KE157OOfFX38gO7KL1vbz5EmBOlpGLV8R e1vw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=TjsnVsZMVslDL2ZSt4jzgC4HynGgUhzSzDiogge30 W0=; b=Icy/HuXDzPlSmtVcN7LRy/5Gie2OgE+gSiy87t1q+rg1XxPEp8MEeG8/q FcERvKEoZXNyyCphAKF+IIcdNLcVeoeHMl6PUnkf9kYPNBr8oFF5S3k3gCURuYEk 6k2tjF+Zev7aRMosL2GorMZrFAH+VwMEhoUL2z1YFhE5bhNXMXDnUNTU8akYTtij 6rpwoDFpA77lDoGcavA39EGbAbsUxybtiJGBPiZXzun+4P/KXbAiQeD7rEfqGxTe u8puGFFYFtH5y7o5mXH/eFbQm6vYUEATJ3pzWgmr1AhzPFIPi9OmteF4DeDfrvAo ggA8f6lsKIJL5F8kNrpfdy8zb7D0w==
X-ME-Sender: <xms:fUENXvA7xlKMTkq8UJSnzVA5xxBl4Wn7N_aT1JJBX94ygHf6AhciUA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdegtddgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ffohhmrghinheprggtmhdrohhrghdpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivg eptd
X-ME-Proxy: <xmx:fUENXtfbd71LE8HCL4Qtno6H3UGKmRVErye_HzpBo9rW0wi-y1OMZQ> <xmx:fUENXhzOZY0wkgaqJU8Of8_oOxo-phAZsry0yl5Eb_SuXVf9W-nyQA> <xmx:fUENXoNHOQqkC5SPeKv8a54AJXFZysAA9iXpu0KDSOTbU-DcGePT7w> <xmx:fkENXgz_lSX2ocR5wBGwekXsuWNea-i_Mar1TiT1gD5OwvpdYlsOlA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D6627E00A2; Wed, 1 Jan 2020 20:03:57 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1
Mime-Version: 1.0
Message-Id: <18c8c298-e462-490b-b3a3-5d5904d98c25@www.fastmail.com>
In-Reply-To: <029D8BB9-CE93-486A-BDF2-6D0720E59109@sinodun.com>
References: <4639bd67-6fca-47d1-aaeb-85fcd0394f46@www.fastmail.com> <029D8BB9-CE93-486A-BDF2-6D0720E59109@sinodun.com>
Date: Thu, 02 Jan 2020 12:03:38 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: "Sara Dickinson" <sara@sinodun.com>
Cc: last-call@ietf.org, dns-privacy@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ZkfEZe401rMsio2n3CueTjT9kcs>
Subject: Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03
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: Thu, 02 Jan 2020 01:04:02 -0000

On Thu, Dec 19, 2019, at 02:06, Sara Dickinson wrote:
> To try to separate out the issue with the text in Section 3.5.1.1 I’ll 
> respond to the comments on that in a separate thread and try to address 
> the other issues in this email. 

Ack.  Ekr's answer will suffice for mine there.

> > BTW, what is "HTTPS destination IP address fingerprinting"? Was the intent of this paragraph to say that this document only examines the DNS protocol independent of the greater context in which it is used? That is, it looks at DNS without considering how privacy risks might result from the use of DNS in combination with other protocols?
> 
> It is describing the ability to fingerprint the website a user connects 
> to based just on the IP address of the HTTPS traffic. For example, this 
> paper given at ANRW https://dl.acm.org/authorize?N687437. Please 
> suggest text if you prefer a different description of this issue.

Given that I don't know what the intent of your statement is, I can't really suggest anything.  However, if the intent is to refer to the paper, then do so.  You are using what appears to be a term or proper name with the expectation that it is understood, but that clearly isn't the case.

> Suggest:
> 
> OLD:
> “The use of clear text transport options to decrease latency may also 
> identify a user e.g. using TCP Fast Open [RFC7413]."
> 
> NEW:
> “Note that even when using encrypted transports the use of clear text 
> transport options to decrease latency can provide correlation of a 
> users' connections e.g. using TCP Fast Open [RFC7413].”

I don't think that really addresses the central point, namely that these options trade linkability for performance and need to do so based on the client's policies with respect to linkability.  TFO is something of a bad example because it offers no prospects for confidentiality protection and it seems like it is not likely to be widely deployed (for that privacy reason and several others related to deployment challenges).

> NEW:
> “Implementations that support encrypted transports are also highly 
> likely to re-use sessions for multiple DNS queries to optimize 
> performance (e.g. via DNS pipelining or HTTPS multiplexing). Default 
> configuration options for encrypted transports could in principle 
> fingerprint a specific client application. For example:…
> 
> If libraries or applications offer user configuration of such options 
> (e.g. [stubby]) then they could in principle help to identify a 
> specific user.”

If you want the most superficial treatment of the issue, sure.  A proper treatment of the issue would require a more dramatic change.  For instance:

   These are cases where user identification, fingerprinting or
   correlations may be possible due to the use of certain transport
   layers or clear text/observable features.  These issues are not
   specific to DNS, but DNS traffic is susceptible to these attacks when
   using specific transports.

Could become:

   The manner in which endpoints implement different protocols might offer the ability for a network-based observer to correlate activity from the same implementation.  This is not regarded as a serious problem, as the resulting anonymity set is increases with the number of deployments of the same stack.  Furthermore, DNS usages might then share an anonymity set with other protocols.

   However, individualized customization of stack operation could enable fingerprinting.  Implementations that offer the ability to alter default options for the operation of the unprotected parts of a stack risk creating smaller anonymity sets.

I'll point out that all the discussion of altering HTTP behaviour for DoH, such as cookies, makes it less likely that DoH will look like something else.  If endpoints simply had a framework for understanding when linkability is and isn't tolerable, then this would be far less problematic.  I'll note that browsers already have this framework. That's why you don't see browser people in the group of concerned citizens.  We all know that the framework is terrible in certain ways, but we understand its limitations and they are an area of active work.

> > Section 3.5.1.2
> RFC7626 included Section 2.5.3 
> https://tools.ietf.org/html/rfc7626#section-2.5.3 ‘Rogue Servers’. This 
> section is just an update of that text to improve context and remove 
> the phrase ’rogue server’. Since the majority of OS implementations 
> still use these mechanisms today it seems to still be relevant. 

Oh, I see that now.  Yeah, 7626s2.5.3 makes one very important point: it acknowledges the possibility for a server to abuse its privileged position.    I failed to link this to that text because this section only contains the other bits.

Those other bits are just a re-iteration of the failings of various discovery methods.  I think you will find that these limitations are acknowledged in the specifications for those protocols.  They aren't in the threat model for those protocols.

The point is that we're trusting the network to provide this service when we have no strong basis for trusting that the network is able to do so.

So maybe the answer here is to say:

  Stub resolvers that discover a resolver identity using the network are trusting the network to both operate a recursive resolver and to secure the discovery process.  That is, in addition to exposing queries to the network operator, vulnerabilities in the discovery process might allow an attacker to interpose their own resolver.  Note that DHCP assumes that the network provides certain safeguards; see Section 22 of [RFC8415].  [[include examples here]]

  Failing to authenticate and authorize a recursive resolver also exposes stub resolvers to the possibility of attack; see Section 3.5.1.4. Automatic discovery without any prior expectations about the identity of allowed resolver makes authorization impossible.

(inline text on authorization as you suggested.)

I would point out that the citation for dnschanger violates the standard assumptions in RFC 3514, so I wouldn't rely on that so much.  The ARP/NDP examples are in direct contradiction to the additional assumptions that DHCP makes.

> > Section 3.5.1.3
> NEW:
> “ Many network operators argue that they block access to remote 
> resolvers for security reasons, for example to cripple malware and bots 
> or to prevent data exfiltration methods that use encrypted DNS 
> communications as transport. Further discussion of Internet service 
> blocking and filtering can be found in [RFC7754]."

How about avoiding "argue that" and the associated rationale (your choice of words here has the unfortunate effect of promulgating an argument about efficacy that is almost certainly true today, but still steps into the debate) and instead stick to facts:

   As a matter of policy, some recursive resolvers use their position in the query path to selectively block access to certain records.  This is a form of Rendezvous-Based Blocking as described in Section 4.3 of [RFC7754].  In order to prevent circumvention of their blocking policies, some networks also block access to resolvers with incompatible policies.

FWIW, the title of this section might be problematic.  This isn't "user-selected", especially in the malware case.

> > Section 3.5.1.5.1
> > 
> > The arguments here repeat those from Section 3.4.2 (nit: not 3.4 as stated). A section reference would be enough.
> 
> I’ll update the section reference and remove the last sentence and the 
> two bullet points. 
> 
> > 
> > Section 3.5.1.5.2
> NEW:
> “Users should be aware that the particular choice of HTTPS 
> functionality vs data minimisation (for example, whether to include the 
> user-agent header) is an implementation specific choice in DoH, not one 
> defined in RFC8484.”

Who is the audience for this document again?

That doesn't really address my more general concerns.  For instance, I might take offense at:

>  the wide practice in HTTP to use various headers to optimize HTTP connections, functionality and behaviour (which can facilitate user identification and tracking)

on the basis that it assumes that these optimizations are deployed without regard to privacy.