idnits 2.17.1 draft-ietf-rtcweb-mdns-ice-candidates-01.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 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.) ** There are 18 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([RFC6762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '...name. The unique name MUST consist of...' RFC 2119 keyword, line 142: '...d IPv6 addresses MUST expose a differe...' RFC 2119 keyword, line 167: '... mDNS candidates MUST support the situ...' RFC 2119 keyword, line 169: '...e, the ICE agent MUST take exactly one...' RFC 2119 keyword, line 170: '.... The ICE agent SHOULD, if available,...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IPLeak' is defined on line 424, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 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: April 25, 2019 J. Uberti 6 Q. Wang 7 Google 8 October 22, 2018 10 Using Multicast DNS to protect privacy when exposing ICE candidates 11 draft-ietf-rtcweb-mdns-ice-candidates-01 13 Abstract 15 WebRTC applications collect ICE candidates as part of the process of 16 creating peer-to-peer connections. To maximize the probability of a 17 direct peer-to-peer connection, client private IP addresses are 18 included in this candidate collection. However, disclosure of these 19 addresses has privacy implications. This document describes a way to 20 share local IP addresses with other clients while preserving client 21 privacy. This is achieved by obfuscating IP addresses with 22 dynamically generated Multicast DNS (mDNS) [RFC6762] names. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 25, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 3 61 2.2. ICE Candidate Processing . . . . . . . . . . . . . . . . 4 62 2.2.1. Handling of Peer-Reflexive Remote Candidate . . . . . 4 63 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Privacy Guidelines . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. APIs Leaking IP Addresses . . . . . . . . . . . . . . . . 6 66 4.2. Interactions With TURN Servers . . . . . . . . . . . . . 6 67 4.3. Generated Names Reuse . . . . . . . . . . . . . . . . . . 7 68 4.4. Specific Browsing Contexts . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 5.1. mDNS Message Flooding . . . . . . . . . . . . . . . . . . 7 71 5.2. Malicious Responses to Deny Name Registration . . . . . . 8 72 5.3. Monitoring of Sessions . . . . . . . . . . . . . . . . . 9 73 6. Specification Requirements . . . . . . . . . . . . . . . . . 9 74 7. Informative References . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 As detailed in [IPHandling], exposing client private IP addresses by 80 default maximizes the probability of successfully creating direct 81 peer-to-peer connection between two clients, but creates a 82 significant surface for user fingerprinting. [IPHandling] recognizes 83 this issue, but also admits that there is no current solution to this 84 problem; implementations that choose to use Mode 3 to address the 85 privacy concerns often suffer from failing or suboptimal connections 86 in WebRTC applications. This is particularly an issue on unmanaged 87 networks, typically homes or small offices, where NAT loopback may 88 not be supported. 90 This document proposes an overall solution to this problem by 91 registering ephemeral mDNS names for each local private IP address, 92 and then providing those names, rather than the IP addresses, to the 93 web application when it gathers ICE candidates. WebRTC 94 implementations resolve these names to IP addresses and perform ICE 95 processing as usual, but the actual IP addresses are not exposed to 96 the web application. 98 2. Principle 100 This section uses the concept of ICE agent as defined in [RFC8445]. 101 In the remainder of the document, it is assumed that each browsing 102 context (as defined in Section 7.1 of [HTMLSpec]) has its own ICE 103 agent. 105 2.1. ICE Candidate Gathering 107 For any host candidate gathered by an ICE agent as part of [RFC8445] 108 section 5.1.1, the candidate is processed as follows: 110 1. Check whether the ICE agent has a usable registered mDNS hostname 111 resolving to the ICE candidate's IP address. If one exists, skip 112 ahead to Step 6. 114 2. Generate a unique mDNS hostname. The unique name MUST consist of 115 a version 4 UUID as defined in [RFC4122], followed by ".local". 117 3. Register the candidate's mDNS hostname as defined in [RFC6762]. 119 4. If registering of the mDNS hostname fails, abort these steps. 120 The candidate is not exposed. 122 5. Store the mDNS hostname and its related IP address in the ICE 123 agent for future reuse. 125 6. Replace the IP address of the ICE candidate with its mDNS 126 hostname, and expose the candidate as usual. 128 An ICE agent can implement this procedure in any way so long as it 129 produces equivalent results to this procedure. 131 An implementation may for instance pre-register mDNS hostnames by 132 executing steps 3 to 5 and prepopulate an ICE agent accordingly. By 133 doing so, only step 6 of the above procedure will be executed at the 134 time of gathering candidates. 136 An implementation may also detect that mDNS is not supported by the 137 available network interfaces. The ICE agent may skip steps 2 and 3 138 and directly decide to not expose the host candidate. 140 This procedure ensures that a mDNS name is used to replace only one 141 IP address. Specifically, an ICE agent using an interface with both 142 IPv4 and IPv6 addresses MUST expose a different mDNS name for each 143 address. 145 2.2. ICE Candidate Processing 147 For any remote ICE candidate received by the ICE agent, the following 148 procedure is used: 150 1. If the connection-address field value of the ICE candidate does 151 not end with ".local" or if the value contains more than one ".", 152 then process the candidate as defined in [RFC8445]. 154 2. Otherwise, resolve the candidate using mDNS. 156 3. If it resolves to an IP address, replace the mDNS hostname of the 157 ICE candidate with the resolved IP address and continue 158 processing of the candidate. 160 4. Otherwise, ignore the candidate. 162 An ICE agent may use a hostname resolver that transparently supports 163 both Multicast and Unicast DNS. In this case the resolution of a 164 ".local" name may happen through Unicast DNS, see [RFC6762] section 165 3. 167 An ICE agent that supports mDNS candidates MUST support the situation 168 where the hostname resolution results in more than one IP address. 169 In this case, the ICE agent MUST take exactly one of the resolved IP 170 addresses and ignore the others. The ICE agent SHOULD, if available, 171 use the first IPv6 address resolved, otherwise the first IPv4 172 address. 174 2.2.1. Handling of Peer-Reflexive Remote Candidate 176 A peer-reflexive remote candidate could be learned and constructed 177 from the source transport address of the STUN Binding request as an 178 ICE connectivity check. The peer-reflexive candidate could share the 179 same address as a remote mDNS candidate that is in the process of 180 being signaled or name resolution. 182 In addition to the elimination procedure of redundant candidates 183 defined in Section 5.1.3 of [RFC8445], which could remove constructed 184 peer-reflexive remote candidates, the address of any existing peer- 185 reflexive remote candidate should not be exposed to Web applications 186 by ICE agents that implement this proposal, as detailed in Section 4. 188 3. Examples 190 In this example, mDNS candidates are exchanged between peers and 191 resolved to obtain the corresponding IP addresses. 193 ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2) 194 | | 197 |----------- mDNS Candidate N1 ---------->| 198 | | 201 |<---------- mDNS Candidate N2 -----------| 202 | | mDNS name N1> 204 |<======== STUN check to 1.1.1.1 =========| 205 |========= STUN check to 2.2.2.2 ========>| 206 | | 208 The following two examples indicate how peer-reflexive candidates for 209 host IP addresses can be created due to timing differences. 211 In this example, a peer-reflexive candidate is generated because the 212 mDNS candidate is signaled after the STUN checks begin. 214 ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2) 215 | | 218 |----------- mDNS Candidate N1 ---------->| 219 | | 221 |<======== STUN check to 1.1.1.1 =========| 222 prflx candidate | | 225 |<---------- mDNS Candidate N2 -----------| 226 | | 228 In this example, a peer-reflexive candidate is generated because the 229 mDNS resolution for name N2 does not complete until after the STUN 230 checks are received. 232 ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2) 233 | | for 2.2.2.2> 236 |----------- mDNS Candidate N1 ---------->| 237 |<---------- mDNS Candidate N2 -----------| 238 240 mDNS |<======== STUN check to 1.1.1.1 =========| 241 ... prflx candidate | | 242 name 2.2.2.2 created | | 243 ... | | 244 N2> | | 246 4. Privacy Guidelines 248 4.1. APIs Leaking IP Addresses 250 When there is no user consent, the following filtering should be done 251 to prevent private IP address leakage: 253 1. ICE candidates with an IP address are not exposed as ICE 254 candidate events. 256 2. Server reflexive ICE candidate raddr field is set to 0.0.0.0 and 257 rport to 0. 259 3. SDP does not expose any a=candidate line corresponding to an ICE 260 candidate which contains an IP address. 262 4. Statistics related to ICE candidates MUST NOT contain the 263 resolved IP address of a remote mDNS candidate or the IP address 264 of a peer-reflexive candidate, unless that IP address has already 265 been learned through other means, e.g., receiving it in a 266 separate server-reflexive remote candidate. 268 4.2. Interactions With TURN Servers 270 When sending data to a TURN [RFC5766] server, the sending client 271 tells the server the destination IP and port for the data. This 272 means that if the client uses TURN to send to an IP that was obtained 273 by mDNS resolution, the TURN server will learn the underlying host IP 274 and port, and this information can then be relayed to the web 275 application, defeating the value of the mDNS wrapping. 277 To prevent disclosure of the host IP address to a TURN server, the 278 ICE agent MUST NOT form candidate pairs between its own relay 279 candidates and remote mDNS candidates. Note that the converse is not 280 an issue; the ICE agent MAY form candidate pairs between its own mDNS 281 candidates and remote relay candidates, as in this situation host IPs 282 will not be sent directly to the TURN server. 284 This restriction has no effect on connectivity; in the cases where 285 host IP addresses are private and need to be wrapped with mDNS names, 286 they will be unreachable from the TURN server, and as noted above, 287 the reverse path will continue to work normally. 289 4.3. Generated Names Reuse 291 It is important that use of registered mDNS hostnames is limited in 292 time and/or scope. Indefinitely reusing the same mDNS hostname 293 candidate would provide applications an even more reliable tracking 294 mechanism than the private IP addresses that this specification is 295 designed to hide. The use of registered mDNS hostnames SHOULD be 296 scoped by origin, and SHOULD have the lifetime of the page. 298 4.4. Specific Browsing Contexts 300 As noted in [IPHandling], privacy may be breached if a web 301 application running in two browsing contexts can determine whether it 302 is running on the same device. While the approach in this document 303 prevents the application from directly comparing local private IP 304 addresses, a successful local WebRTC connection can also present a 305 threat to user privacy. Specifically, when the latency of a WebRTC 306 connection latency is close to zero, the probability is high that the 307 two peers are running on the same device. 309 To avoid this issue, browsers SHOULD NOT register mDNS names for 310 WebRTC applications running in a third-party browsing context (i.e., 311 a context that has a different origin than the top-level browsing 312 context), or a private browsing context. 314 5. Security Considerations 316 5.1. mDNS Message Flooding 318 The implementation of this proposal requires the mDNS querying 319 capability of the browser for registering mDNS names or adding remote 320 ICE host candidates with such names. It also requires the mDNS 321 responding capability of either the browser or the operating platform 322 of the browser for registering, removing or resolving mDNS names. In 323 particular, 325 o the registration of name requires optional probing queries and 326 mandatory announcing responses ([RFC6762], Section 8), and this is 327 performed at the beginning of ICE gathering; 329 o the addition of remote ICE host candidates with mDNS names 330 generates mDNS queries for names of each candidate; 332 o the removal of names could happen when the browsing context of the 333 ICE agent is destroyed in an implementation, and goodbye responses 334 should be sent to invalidate records generated by the ICE agent in 335 the local network ([RFC6762], Section 10.1). 337 A malicious Web application could flood the local network with mDNS 338 messages by: 340 o creating browsing contexts that create ICE agents and start 341 gathering of local ICE host candidates; 343 o destroying these local candidates soon after the name registration 344 is done; 346 o adding fictitious remote ICE host candidates with mDNS names. 348 [RFC6762] defines a per-record multicast rate limiting rule, in which 349 a given record on a given interface cannot be sent less than one 350 second since its last transmission. This rate limiting rule however 351 does not mitigate the above attacks, in which new names, hence new 352 records, are constantly created and sent. A browser-wide mDNS 353 message rate limit MUST be provided for all messages that can be 354 indirectly dispatched by a web application, namely the probing 355 queries, announcement responses, resolution queries, and goodbye 356 responses associated with mDNS. 358 5.2. Malicious Responses to Deny Name Registration 360 If the optional probing queries are implemented for the name 361 registration, a malicious endpoint in the local network, which is 362 capable of responding mDNS queries, could send responses to block the 363 use of the generated names. This would lead to the discarding of 364 this ICE host candidate as in Step 5 in Section 2.1. 366 The above attack can be mitigated by skipping the probing when 367 registering a name, which also conforms to Section 8 in [RFC6762], 368 given that the name is randomly generated for the probabilistic 369 uniqueness (e.g. a version 4 UUID) in Step 3 in Section 2.1. 370 However, a similar attack can be performed by exploiting the negative 371 responses (defined in [RFC6762], Section 8.1), in which NSEC resource 372 records are sent to claim the nonexistence of records related to the 373 gathered ICE host candidates. 375 The existence of malicious endpoints in the local network poses a 376 generic threat, and requires dedicated protocol suites to mitigate, 377 which is beyond the scope of this proposal. 379 5.3. Monitoring of Sessions 381 A malicious endpoint in the local network may also record other 382 endpoints who are registering, unregistering, and resolving mDNS 383 names. By doing so, they can create a session log that shows which 384 endpoints are communicating, and for how long. If both endpoints in 385 the session are on the same network, the fact they are communicating 386 can be discovered. 388 As above, mitigation of this threat is beyond the scope of this 389 proposal. 391 6. Specification Requirements 393 The proposal relies on identifying and resolving any mDNS-based ICE 394 candidates as part of adding/processing a remote candidate. [ICESDP] 395 section 4.1 could be updated to explicitly allow mDNS names in the 396 connection-address field. 398 The proposal relies on adding the ability to register mDNS names at 399 ICE gathering time. This could be described in [ICESDP] and/or 400 [WebRTCSpec]. 402 The proposal allows updating [IPHandling] so that mode 2 is not the 403 mode used by default when user consent is not required. Instead, the 404 default mode could be defined as mode 3 with mDNS-based ICE 405 candidates. 407 7. Informative References 409 [HTMLSpec] 410 "HTML Living Standard", n.d., 411 . 413 [ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/ 414 Answer procedures for Interactive Connectivity 415 Establishment (ICE)", April 2018, 416 . 419 [IPHandling] 420 Shieh, G., "WebRTC IP Address Handling Requirements", 421 April 2018, . 424 [IPLeak] "IP/DNS Detect", n.d., . 426 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 427 Unique IDentifier (UUID) URN Namespace", RFC 4122, 428 DOI 10.17487/RFC4122, July 2005, 429 . 431 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 432 Relays around NAT (TURN): Relay Extensions to Session 433 Traversal Utilities for NAT (STUN)", RFC 5766, 434 DOI 10.17487/RFC5766, April 2010, 435 . 437 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 438 DOI 10.17487/RFC6762, February 2013, 439 . 441 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 442 Connectivity Establishment (ICE): A Protocol for Network 443 Address Translator (NAT) Traversal", RFC 8445, 444 DOI 10.17487/RFC8445, July 2018, 445 . 447 [WebRTCSpec] 448 Bruaroey, J., "The WebRTC specification", n.d., 449 . 451 Authors' Addresses 453 Youenn Fablet 454 Apple Inc. 456 Email: youenn@apple.com 458 Jeroen de Borst 459 Google 461 Email: jeroendb@google.com 463 Justin Uberti 464 Google 466 Email: juberti@google.com 467 Qingsi Wang 468 Google 470 Email: qingsi@google.com