idnits 2.17.1 draft-ietf-rtcweb-mdns-ice-candidates-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC6763]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2018) is 2051 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB Y. Fablet 3 Internet-Draft Apple Inc. 4 Intended status: Informational J. De Borst 5 Expires: March 16, 2019 J. Uberti 6 Q. Wang 7 Google 8 September 12, 2018 10 Using Multicast DNS to protect privacy when exposing ICE candidates 11 draft-ietf-rtcweb-mdns-ice-candidates-00 13 Abstract 15 WebRTC applications rely on ICE candidates to enable peer-to-peer 16 connections between clients in as many network configurations as 17 possible. To maximize the probability to create a direct peer-to- 18 peer connection, client private IP addresses are often exposed 19 without user consent. This is currently used as a way to track 20 users. This document describes a way to share IP addresses with 21 other clients while preserving client privacy. This is achieved by 22 obfuscating IP addresses using dynamically generated names resolvable 23 through Multicast DNS [RFC6763]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 16, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 3 63 3.2. ICE Candidate Processing . . . . . . . . . . . . . . . . 4 64 4. Privacy Guidelines . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. APIs leaking IP addresses . . . . . . . . . . . . . . . . 4 66 4.2. Generated names reuse . . . . . . . . . . . . . . . . . . 5 67 4.3. Specific execution contexts . . . . . . . . . . . . . . . 5 68 5. Specification Requirements . . . . . . . . . . . . . . . . . 5 69 6. Informative References . . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 As detailed in [IPHandling], exposing client private IP addresses 75 allows maximizing the probability to successfully create a connection 76 between two clients. This information is also used by many web sites 77 as a way to fingerprint and identify users without their consent. 79 The first approach exposes client private IP addresses by default, as 80 can be seen from websites such as [IPLeak]. The second approach 81 implemented in the WebKit engine enforces the following policy: 83 1. By default, use mode 3 as defined in [IPHandling]: any host ICE 84 candidate is filtered out. 86 2. Use mode 2 as defined in [IPHandling] if there is an explicit 87 user action to trust the web site: host ICE candidates are 88 exposed to the web site based on the use of 89 navigator.mediaDevices.getUserMedia, which typically prompts the 90 user to grant or deny access to cameras/microphones. 92 The second approach supports most common audio/video conference 93 applications but leads to failing or suboptimal connections for 94 applications relying solely on data channel. This is particularly an 95 issue on unmanaged networks, typically home or small offices where 96 NAT loopback might not be supported. 98 To overcome the shortcomings of the above two approaches, this 99 document proposes to register dynamically generated names using 100 Multicast DNS when gathering ICE candidates. These dynamically 101 generated names are used to replace private IP addresses in host ICE 102 candidates. Only clients that can resolve these dynamically 103 generated names using Multicast DNS will get access to the actual 104 client IP address. 106 2. Privacy Concerns 108 The gathering of ICE candidates without user consent is a well-known 109 fingerprinting technique to track users. This is particularly a 110 concern when users are connected through a NAT which is a usual 111 configuration. In such a case, knowing both the private IP address 112 and the public IP address will usually identify uniquely the user 113 device. Additionally, Internet web sites can more easily attack 114 intranet web sites when knowing the intranet IP address range. 116 A successful WebRTC connection between two peers is also a potential 117 thread to user privacy. When a WebRTC connection latency is close to 118 zero, the probability is high that the two peers are running on the 119 same device. Browsers often isolate contexts one from the other. 120 Private browsing mode contexts usually do not share any information 121 with regular browsing contexts. The WebKit engine isolates third- 122 party iframes in various ways (cookies, ITP) to prevent user 123 tracking. Enabling a web application to determine that two contexts 124 run in the same device would defeat some of the protections provided 125 by modern browsers. 127 3. Principle 129 This section uses the concept of ICE agent as define in [RFC5245]. 130 In the remainder of the document, it is assumed that each browser 131 execution context has its own ICE agent. 133 3.1. ICE Candidate Gathering 135 For any host ICE candidate gathered by a browsing context as part of 136 [RFC5245] section 4.1.1, obfuscation of the candidate is done as 137 follows: 139 1. Check whether the context ICE agent registered a name resolving 140 to the ICE host candidate IP address. 142 2. If the ICE agent registered the name, replace the IP address of 143 the ICE host candidate with the name with ".local" appended to 144 it. Expose the candidate and abort these steps. 146 3. Generate a random unique name, typically a version 4 UUID as 147 defined in [RFC4122]. 149 4. Register the unique name using Multicast DNS. 151 5. If registering of the unique name fails, abort these steps. The 152 candidate is not exposed. 154 6. Store the name and its related IP address in the ICE agent for 155 future reuse. 157 7. Replace the IP address of the ICE host candidate with the name 158 with ".local" appended to it. Expose the candidate. 160 3.2. ICE Candidate Processing 162 For any remote host ICE candidate received by the ICE agent, the 163 following procedure is used: 165 1. If the connection-address field value of the ICE candidate does 166 not finish by ".local", process the candidate as defined in 167 [RFC5245]. 169 2. Otherwise, remove the ".local" suffix to the value and resolve it 170 using Multicast DNS. 172 3. If it resolves to an IP address, replace the value of the ICE 173 host candidate by the resolved IP address and continue processing 174 of the candidate. 176 4. Otherwise, ignore the candidate. 178 Multicast DNS resolution might end up retrieving both an IPv4 and 179 IPv6 address. In that case, the IPv6 address may be used preferably 180 to the IPv4 address. 182 4. Privacy Guidelines 184 4.1. APIs leaking IP addresses 186 When there is no user consent, the following filtering should be done 187 to prevent private IP address leakage: 189 1. host ICE candidates with an IP address are not exposed as ICE 190 candidate events. 192 2. Server reflexive ICE candidate raddr field is set to 0.0.0.0 and 193 rport to 0. 195 3. SDP does not expose any a=candidate line corresponding to a host 196 ICE candidate which contains an IP address. 198 4. RTCIceCandidateStats dictionaries exposed to web pages do not 199 contain any 'ip' member if related to a host ICE candidate. 201 4.2. Generated names reuse 203 Dynamically generated names can be used to track users if used too 204 often. Conversely, registering too many names will also generate 205 useless processing. The proposed rule is to create and register a 206 new generated name for a given IP address on a per execution context. 208 4.3. Specific execution contexts 210 Privacy might also be breached if two execution contexts can identify 211 whether they are run in the same device based on a successful peer- 212 to-peer connection. The proposed rule is to not register any name 213 using Multicast DNS for any ICE agent belonging to: 215 1. A third-party browser execution context, i.e. a context that is 216 not same origin as the top level execution context. 218 2. A private browsing execution context. 220 5. Specification Requirements 222 The proposal relies on identifying and resolving any Multicast DNS 223 based ICE candidates as part of adding/processing a remote candidate. 224 [ICESDP] section 4.1 could be updated to explicitly allow Multicast 225 DNS names in the connection-address field. 227 The proposal relies on adding the ability to register Multicast DNS 228 names at ICE gathering time. This could be described in [ICESDP] 229 and/or [WebRTCSpec]. 231 The proposal allows updating [IPHandling] so that mode 2 is not the 232 mode used by default when user consent is not required. Instead, the 233 default mode could be defined as mode 3 with Multicast DNS based ICE 234 candidates. 236 6. Informative References 238 [ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/ 239 Answer procedures for Interactive Connectivity 240 Establishment (ICE)", April 2018, 241 . 244 [IPHandling] 245 Shieh, G., "WebRTC IP Address Handling Requirements", 246 April 2018, . 249 [IPLeak] "IP/DNS Detect", n.d., . 251 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 252 Unique IDentifier (UUID) URN Namespace", RFC 4122, 253 DOI 10.17487/RFC4122, July 2005, 254 . 256 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 257 (ICE): A Protocol for Network Address Translator (NAT) 258 Traversal for Offer/Answer Protocols", RFC 5245, 259 DOI 10.17487/RFC5245, April 2010, 260 . 262 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 263 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 264 . 266 [WebRTCSpec] 267 Bruaroey, J., "The WebRTC specification", n.d., 268 . 270 Authors' Addresses 272 Youenn Fablet 273 Apple Inc. 275 Email: youenn@apple.com 277 Jeroen De Borst 278 Google 280 Email: jeroendb@google.com 282 Justin Uberti 283 Google 285 Email: juberti@google.com 286 Qingsi Wang 287 Google 289 Email: qingsi@google.com