Re: [Doh] Privacy Considerations Text (#2)
"Hewitt, Rory" <rhewitt@akamai.com> Thu, 21 June 2018 18:50 UTC
Return-Path: <rhewitt@akamai.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 3B9771310D3 for <doh@ietfa.amsl.com>; Thu, 21 Jun 2018 11:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.72
X-Spam-Level:
X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 U9EkjHP2o0v0 for <doh@ietfa.amsl.com>; Thu, 21 Jun 2018 11:50:13 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 7E4E413112E for <doh@ietf.org>; Thu, 21 Jun 2018 11:50:13 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5LIkYuI001986 for <doh@ietf.org>; Thu, 21 Jun 2018 19:50:13 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=+wYhFFOQ3NySSojlz3/2iug6lOGwkAdaei9hLOLCOCM=; b=dpgz9zrhxmLOc109yPqGWF1oyrWyx7Sof0PVbp31CmUh/TecweyLE8GVhAz6RJh3Ol4/ TTp+fDddrWSgzYFE61+xwrqaI8p15X03agyR/MooGyIE/TKXa+rh7mk7mBIaQuIaLyvm 1COG99eABe1g8lb/uFNSApa+Sv1mOQHFvKHhGXXfB0XoPhzbZxSoRYFWJERoBl5zZvV2 Mko4ecRuqWD6yt6jfb66y7JB4kHoD0GXEqEaDG7CTgk5feRssJpMJ3ySdDQo/Spsy9ja JHm9Sx5dyKAWF/Yj48CYkgqmpUvHctn5EA7IClnsT/2F3GD8MvV1/nztBKD+9u7xfKy7 8Q==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2jqnpxv6kj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <doh@ietf.org>; Thu, 21 Jun 2018 19:50:12 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5LIkJqt000717 for <doh@ietf.org>; Thu, 21 Jun 2018 14:50:11 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2jmwvv0ajr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <doh@ietf.org>; Thu, 21 Jun 2018 14:50:10 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 21 Jun 2018 14:50:10 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 21 Jun 2018 14:50:10 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1365.000; Thu, 21 Jun 2018 14:50:10 -0400
From: "Hewitt, Rory" <rhewitt@akamai.com>
To: DoH WG <doh@ietf.org>
Thread-Topic: [Doh] Privacy Considerations Text (#2)
Thread-Index: AQHUCY+7ftjL2jjgkUClRQGMeG/U9KRrDhFg
Date: Thu, 21 Jun 2018 18:50:09 +0000
Message-ID: <feb96c9b6fdb40a2a132c3d299890fbd@usma1ex-dag1mb3.msg.corp.akamai.com>
References: <CAOdDvNpGSw6SP6COgJuJR_y2i1BjPWy3_i14vCYUP3jq6=zGuQ@mail.gmail.com>
In-Reply-To: <CAOdDvNpGSw6SP6COgJuJR_y2i1BjPWy3_i14vCYUP3jq6=zGuQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.113.109]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_001E_01D40956.004FBC50"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-21_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806210202
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-21_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806210202
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/0oA1loODB2EETS5FOLpr9LSFDmM>
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: Thu, 21 Jun 2018 18:50:25 -0000
+1 - new text looks good AND is readable. From: Patrick McManus [mailto:pmcmanus@mozilla.com] Sent: Thursday, June 21, 2018 11:43 AM To: DoH WG <doh@ietf.org> Subject: [Doh] Privacy Considerations Text (#2) Hi All, We may be getting close to bridging the important points here - so we've made an update to the PR. (its still not merged into the working copy, but it has changed). and we can iterate from there. Thank you for the comments, and especially text proposals - they really help. The live copy is at https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/200 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dohwg_draft-2Dietf-2Ddoh-2Ddns-2Dover-2Dhttps_pull_200&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=rHk_4z4OwUA_g3kaoRhg_WqOtJkx91PA4rISmv5Wk3I&s=qMyTSeJFZ_PRxu5ZamUK2J9r1BjdanWU0u2rS-03i8I&e=> and I'll snapshot it again at the end of this email The deltas make more explicit comparisons between DoH and Do(TLS), calls out some rationale about the full ecosystem in the same text that asks you to consider the cost/benefits of http features, and includes the new text about a minimal data set. -Patrick # Privacy Considerations {#PrivacyConsiderations} {{RFC7626}} discusses DNS Privacy Considerations in both "On the wire" (Section 2.4), and "In the server" (Section 2.5) contexts. This is also a useful framing for DoH's privacy considerations. ## On The Wire {#OnTheWire} DoH encrypts DNS traffic and requires authentication of the server. This mitigates both passive surveillance {{RFC7258}} and active attacks attempting to divert DNS traffic to rogue servers ({{RFC7626}} Section 2.5.1). DNS over TLS {{RFC7858}} provides similar protections, while direct UDP and TCP based transports are vulnerable to this class of information leak. Additionally, the use of the HTTPS default port 443 and the ability to mix DoH traffic with other HTTPS traffic on the same connection can deter on-path devices from interfering with DNS operations and make DNS traffic analysis more difficult. ## In The Server {#InTheServer} A DoH application is built on IP, TCP, TLS, and HTTP. Each layer contains one or more common features that can be used to correlate different queries to the same identity. DNS transports will generally carry the same privacy properties of the layers used to implement them. For example, the properties of IP, TCP, and TLS apply to DNS over TLS implementations. 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. At the IP level, the client address provides obvious correlation information. This can be mitigated by use of a NAT, proxy, VPN, or simple address rotation over time. It may be aggravated by use of a DNS server that can correlate real-time addressing information with other personal identifiers, such as when a DNS server and DHCP server are operated by the same entity. TCP-based solutions may seek performance through the use of TCP Fast Open {{RFC7413}}.. The cookies used in TCP Fast Open allow servers to correlate different TCP sessions together. TLS based implementations often achieve better handshake performance through the use of some form of session resumption mechanism such as session tickets {{RFC5077}}. Session resumption creates trivial mechanisms for a server to correlate different TLS connections together. HTTP's feature set can also be used for identification and tracking in a number of different ways. For example, authentication request header fields explicitly identify profiles in use, and HTTP Cookies are designed as an explicit state tracking mechanism between the client and serving site and often are used as an authentication mechanism. Additionally, the User-Agent and Accept-Language request header fields often convey specific information about the client version or locale. This facilitates content negotiation and operational work-arounds for implementation bugs. Request header fields that control caching can expose state information about a subset of the client's history. Mixing DoH requests with other HTTP requests on the same connection also provides an opportunity for richer data correlation. The DoH protocol design allows applications to fully leverage all the features of the HTTP ecosystem, including features not enumerated here. Implementations of DoH clients and servers need to consider the benefit and privacy impact of these features, and their deployment context, when deciding whether or not to enable them. Implementations should expose the minimal set of data needed to achieve the desired feature set.
- Re: [Doh] [Ext] Privacy Considerations Text (#2) Mateusz Jończyk
- Re: [Doh] [Ext] Privacy Considerations Text (#2) Paul Hoffman
- [Doh] Privacy Considerations Text (#2) Mateusz Jończyk
- Re: [Doh] Privacy Considerations Text (#2) Patrick McManus
- Re: [Doh] Privacy Considerations Text (#2) nusenu
- Re: [Doh] [Ext] Privacy Considerations Text (#2) Eric Rescorla
- Re: [Doh] [Ext] Privacy Considerations Text (#2) Patrick McManus
- Re: [Doh] [Ext] Privacy Considerations Text (#2) Paul Hoffman
- Re: [Doh] Privacy Considerations Text (#2) Eric Rescorla
- Re: [Doh] Privacy Considerations Text (#2) Hewitt, Rory
- [Doh] Privacy Considerations Text (#2) Patrick McManus
- Re: [Doh] Privacy Considerations Text (#2) Howard Chu
- Re: [Doh] Privacy Considerations Text (#2) Patrick McManus
- Re: [Doh] Privacy Considerations Text (#2) nusenu
- Re: [Doh] Privacy Considerations Text (#2) nusenu
- Re: [Doh] Privacy Considerations Text (#2) Sara Dickinson
- Re: [Doh] Privacy Considerations Text (#2) Joseph Lorenzo Hall
- Re: [Doh] Privacy Considerations Text (#2) Patrick McManus
- Re: [Doh] Privacy Considerations Text (#2) Joseph Lorenzo Hall
- Re: [Doh] Privacy Considerations Text (#2) Andrew Sullivan
- Re: [Doh] Privacy Considerations Text (#2) Patrick McManus
- Re: [Doh] [Ext] Privacy Considerations Text (#2) Hewitt, Rory
- Re: [Doh] Privacy Considerations Text (#2) Sara Dickinson
- Re: [Doh] [Ext] Privacy Considerations Text (#2) Patrick McManus
- Re: [Doh] [Ext] Privacy Considerations Text (#2) Mateusz Jończyk
- Re: [Doh] [Ext] Privacy Considerations Text (#2) Ray Bellis
- Re: [Doh] [Ext] Privacy Considerations Text (#2) Paul Hoffman
- Re: [Doh] [Ext] Privacy Considerations Text (#2) Patrick McManus