Re: [Doh] Privacy Considerations Text (#2)

Sara Dickinson <sara@sinodun.com> Mon, 25 June 2018 15:30 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243EA130ECD for <doh@ietfa.amsl.com>; Mon, 25 Jun 2018 08:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level:
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=no autolearn_force=no
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 Yv7RvgCjp9-d for <doh@ietfa.amsl.com>; Mon, 25 Jun 2018 08:30:17 -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 94C70130EC9 for <doh@ietf.org>; Mon, 25 Jun 2018 08:30:17 -0700 (PDT)
Received: from [2001:b98:204:102:fffa::409] (port=49642) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sara@sinodun.com>) id 1fXTRT-0004z0-S7; Mon, 25 Jun 2018 16:30:15 +0100
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <DAE6BABB-668E-4AAA-9BAC-4CFEADB2358D@sinodun.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_91BEF753-ABCA-4EDD-96C0-2F41EE68CC7A"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Mon, 25 Jun 2018 16:30:03 +0100
In-Reply-To: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net>
Cc: doh@ietf.org
To: nusenu <nusenu-lists@riseup.net>, Patrick McManus <pmcmanus@mozilla.com>
References: <CAOdDvNpGSw6SP6COgJuJR_y2i1BjPWy3_i14vCYUP3jq6=zGuQ@mail.gmail.com> <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net>
X-Mailer: Apple Mail (2.3445.8.2)
X-BlackCat-Spam-Score: 14
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/xRm_ZYWT0qOORPSfzL2YHCpIjRE>
Subject: Re: [Doh] Privacy Considerations Text (#2)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jun 2018 15:30:27 -0000

> On 21 Jun 2018, at 21:57, Patrick McManus <pmcmanus@mozilla.com> wrote:
> 
> On Thu, Jun 21, 2018 at 4:07 PM, nusenu <nusenu-lists@riseup.net <mailto:nusenu-lists@riseup.net>> wrote:
> 
> Is this iteration supposed to address or include previous comments from [1]?
> I don't see [1] addressed.
> 
> 
> I believe it addresses where we are converging related to those comments and others. The text includes, among other things, the notion that HTTPS is an incremental consideration to TLS and that the HTTPS considerations deal with a large number of features because DoH design allows leveraging of the full HTTP ecosystem.

Hi Patrick, 

Thanks for the updates, I think the discussion on cookies is particularly helpful. I’m not sure it yet addresses everything that has been raised on the list, I believe the PR proposed below does.


> On 21 Jun 2018, at 21:07, nusenu <nusenu-lists@riseup.net> wrote:
>> The privacy considerations of using the HTTPS layer in DoH are
>> incremental to those of DNS over TLS. DoH is not known to introduce
>> new concerns beyond those associated with HTTPS.
> 
> Actually I think it does because it combines two protocols (DNS + HTTPS) that haven't been
> combined before and DNS+HTTPS has more privacy implications than just the sum of IP, TCP, TLS and HTTP
> when DoH server are not used exclusively for DoH.

Actually, I think this is a very salient point. DoH is the combination of DNS wireformat messages and the HTTP layer. That combination alone introduces new privacy concerns beyond that of either standalone protocol so I think this does need to be framed differently. 

I’ve done a PR
https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/205 <https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/205>
which removes the above text and more clearly breaks down the issue along the lines of the layer model already used. Specifically it add this text:

---
Session resumption creates trivial mechanisms for a server to correlate TLS 
connections together.

+ ### DNS Specific considerations
+
+ Whilst DNS transports will generally carry the same privacy properties of the
+ layers used to implement them the standard DNS wireformat itself notably
+ contains no client identifiers. Using HTTPS as a transport therefore introduces
+ new privacy concerns over DNS over UDP, TCP or TLS (RFC7858) with regard to
+ additional data that may be visible to a DoH server compared to a DNS resolver.

+ ### HTTP Specific considerations (#HTTPconsiderations)

+ This section provides guidance but places only minor restrictions on HTTP
+ features (specifically HTTP cookies) that may be used in DoH. The design
+ rationale for this decision is that retaining the ability to leverage the full
+ functionality of the HTTP ecosystem is more important than placing any
+ constraints on this new protocol based on privacy considerations.

HTTP's feature set can also be used for identification and tracking in
—


Sara.