idnits 2.17.1 draft-ietf-intarea-hostname-practice-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2015) is 3117 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-dhc-anonymity-profile-04 == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcp-privacy-01 == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-privacy-01 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft D. Thaler 4 Intended status: Informational Microsoft 5 Expires: April 15, 2016 October 13, 2015 7 Current Hostname Practice Considered Harmful 8 draft-ietf-intarea-hostname-practice-00.txt 10 Abstract 12 Giving a hostname to your computer and publishing it as you roam from 13 network to hot spot is the Internet equivalent of walking around with 14 a name tag affixed to your lapel. The practice can significantly 15 compromise your privacy, and should stop. 17 There are several possible remedies, such as fixing a variety of 18 protocols or avoiding disclosing a hostname at all. This document 19 studies another possible remedy, which is to replace the static 20 hostnames by frequently changing randomized values. This idea 21 obviously needs more work. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 15, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Naming practices . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Partial identifiers . . . . . . . . . . . . . . . . . . . . . 3 60 4. Protocols that leak hostnames . . . . . . . . . . . . . . . . 4 61 4.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. DNS address to name resolution . . . . . . . . . . . . . 4 63 4.3. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 5 64 4.4. Link-local Multicast Name Resolution . . . . . . . . . . 5 65 4.5. DNS service discovery . . . . . . . . . . . . . . . . . . 5 66 5. Randomized Host Names as Remedy . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 70 9. Informative References . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 There is a long established practice of giving names to computers. 76 In the Internet protocols, these names are referred to as 77 "hostnames." hostnames are normally used in conjunction with a domain 78 name prefix to build the "Fully Qualified Domain Name" (FQDN) of a 79 host. However, it is common practice to use the hostname without 80 further qualification in a variety of applications from file sharing 81 to network management. Hostnames are typically published as part of 82 domain names, and can be obtained through a variety of name lookups 83 and discovery protocols. 85 Hostnames have to be unique within the domain in which they are 86 created and used. They do not have to be globally unique 87 identifiers, but they will always be at least partial identifiers, as 88 discussed in Section 3. 90 The disclosure of information through hostnames creates a problem for 91 mobile devices. Adversaries that monitor a remote network such as a 92 Wi-Fi hot spot can obtain the hostname through passive or active 93 monitoring of a variety of Internet protocols, such as for example 94 DHCP, or multicast DNS. They can correlate the hostname with various 95 other information extracted from traffic analysis, and identify the 96 device and its user. 98 2. Naming practices 100 There are many reasons to give names to computers. This is 101 particularly true when computers operate on a network. Operating 102 systems like Microsoft Windows or Unix assume that computers have a 103 "hostname." This enable users and administrators to do things such 104 as ping a computer, add its name to an access control list, remotely 105 mount a computer disk, or connect to the computer through tools such 106 as telnet or remote desktop. 108 In most consumer networks, naming is pretty much left to the fancy of 109 the user. Some will pick names of planets or stars, other names of 110 fruits or flowers, and other will pick whatever suits their mood when 111 they unwrap the device. As long as users are careful to not pick a 112 name already in use on the same network, anything goes. 114 In large organizations, collisions are more likely and a more 115 structured approach is necessary. In theory, organizations could use 116 multiple DNS subdomains to ease the pressure on uniqueness, but in 117 practice many don't and insist on unique flat names, if only to 118 simplify network management. To ensure unique names, organizations 119 will set naming guidelines and enforce some kind of structured 120 naming. For example, within the Microsoft corporate network, 121 computer names are derived from the login name of the main user, 122 leading to names like "huitema-test2" for a machine that one of the 123 authors uses to test software. 125 There is less pressure to assign names to small devices, including 126 for example smart phones, as these devices typically do not enable 127 sharing of their disks or remote login. As a consequence, these 128 devices often have manufacturer assigned names, which vary from very 129 generic like "Windows Phone" to completely unique like "BrandX- 130 123456-7890-abcdef." 132 3. Partial identifiers 134 Suppose an adversary wants to track the people connecting to a 135 specific Wi-Fi hot spot, for example in a railroad station. Assume 136 that the adversary is able to retrieve the hostname used by a 137 specific laptop. That, in itself, is not enough to identify the 138 laptop's owner. Suppose however that the adversary observes that the 139 laptop name is "huitema-laptop" and that the laptop has established a 140 VPN connection to the Microsoft corporate network. The two pieces of 141 information, put together, firmly point to Christian Huitema, 142 employed by Microsoft. The identification is successful. 144 In the example, we saw a login name inside the hostname, and that 145 certainly helped identification. But generic names like "jupiter" or 146 "rosebud" also provide partial identification, especially if the 147 adversary is capable of maintaining a database recording, among other 148 information, the hostnames of devices used by specific users. 149 Generic names are picked from vocabularies that include thousands of 150 potential choices. Finding the name reduces the scope of the search 151 by maybe a factor of a thousand. Other information such as the 152 visited sites will quickly complement that data and lead to user 153 identification. 155 Of course, unique names assigned by manufacturers are even more 156 interesting for such adversaries capable of maintaining a database 157 recording the hostnames of devices used by specific user. With a 158 unique name like "BrandX-123456-7890-abcdef" identification can be 159 pretty much immediate. 161 4. Protocols that leak hostnames 163 Many IETF protocols can leak the "hostname" of a computer. A non 164 exhaustive list includes DHCP, DNS address to name resolution, 165 Multicast DNS, Link-local Multicast Name Resolution, and DNS service 166 discovery. 168 4.1. DHCP 170 Shortly after connecting to a new network, a host can use DHCP 171 [RFC2131] to acquire an IPv4 address and other parameters [RFC2132]. 172 A DHCP query can disclose the "hostname." DHCP traffic is sent to 173 multicast addresses and can be easily monitored, enabling adversaries 174 to discover the hostname associated with a computer visiting a 175 particular network. DHCPv6 [RFC3315] shares similar issues. 177 The problems with the hostnames and FQDN parameters in DHCP are 178 analyzed in [I-D.ietf-dhc-dhcp-privacy] and 179 [I-D.ietf-dhc-dhcpv6-privacy]. Possible mitigations are described in 180 [I-D.ietf-dhc-anonymity-profile]. 182 4.2. DNS address to name resolution 184 The domain name service design [RFC1035] includes the specification 185 of the special domain "in-addr.arpa" for resolving the name of the 186 computer using a particular IPv4 address, using the PTR format 187 defined in [RFC1033]. A similar domain, "ip6.arpa", is defined in 188 [RFC3596] for finding the name of a computer using a specific IPv6 189 address. 191 Adversaries who observe a particular address in use on a specific 192 network can try to retrieve the PTR record associated with that 193 address, and thus the hostname of the computer, or even the fully 194 qualified domain name of that computer. The retrieval may not be 195 useful in many IPv4 networks due to the prevalence of NAT, but it 196 could work in IPv6 networks. 198 4.3. Multicast DNS 200 Multicast DNS (MDNS) is defined in [RFC6762]. It enables hosts to 201 send DNS queries over a multicast port, and to elicit responses from 202 hosts participating in the service. 204 If an adversary suspects that a particular host is present on a 205 network, the adversary can send MDNS requests to find, for example, 206 the A or AAAA records associated with the hostname in the ".local" 207 domain. A positive reply will confirm the presence of the host. 209 When a new responder starts, it must send a set of multicast queries 210 to verify that the name that it advertises is unique on the network, 211 and also to populate the caches of other MDNS hosts. Adversaries can 212 monitor this traffic and discover the hostname of computers as they 213 join the monitored network. 215 4.4. Link-local Multicast Name Resolution 217 The Link-local Multicast Name Resolution (LLMNR) is defined in 218 [RFC4795]. The specification did not achieve consensus as an IETF 219 standard, but is widely deployed. Like MDNS, it enables hosts to 220 send DNS queries over a multicast port, and to elicit responses from 221 computers implementing the LLMNR service. 223 Like MDNS, LLMNR can be used by adversaries to confirm the presence 224 on a network of a specific host, by issuing a multicast requests to 225 find the A or AAAA records associated with the hostname in the 226 ".local" domain. 228 When an LLMNR responder starts it sends a set of multicast queries to 229 verify that the name that it advertises is unique on the network. 230 Adversaries can monitor this traffic and discover the hostname of 231 computers as they join the monitored network. 233 4.5. DNS service discovery 235 DNS-Based Service discovery (DNS-SD) is described in [RFC6763]. It 236 enables participating host to retrieve the location of services 237 proposed by other hosts. It can be used with DNS servers, or in 238 conjunction with MDNS in a server-less environment. 240 Participating hosts publish a service described by an "instance 241 name," typically chosen by the user responsible for the publication. 243 While this is obviously an active disclosure of information, privacy 244 aspects can be mitigated by user control. Services should only be 245 published when deciding to do so, and the information disclosed in 246 the service name should be well under the control of the device's 247 owner. 249 In theory there should not be any privacy issue, but in practice the 250 publication of a service also forces the publication of the hostname, 251 due to a chain of dependencies. The service name is used to publish 252 a PTR record announcing the service. The PTR record typically points 253 to the service name in the local domain. The service names, in turn, 254 are used to publish TXT records describing service parameters, and 255 SRV records describing the service location. 257 SRV records are described in [RFC2782]. Each record contains 4 258 parameters: priority, weight, port number and hostname. While the 259 service name published in the PTR record is chosen by the user, the 260 "hostname" in the SRV record is indeed the hostname of the device. 262 Adversaries can monitor the MDNS traffic associated with DNS-SD and 263 retrieve the host name of computers advertising any service with DNS- 264 SD. 266 5. Randomized Host Names as Remedy 268 There are several ways to remedy the hostname practices. We could 269 instruct people to just turn off any protocol that leaks hostnames, 270 at least when they visit some "insecure" place. We could also 271 examine each particular standard that publishes hostnames, and 272 somehow fix the corresponding protocols. Or, we could attempt to 273 revise the way our devices manage the hostname parameter. 275 There is a lot of merit in "turning off unneeded protocols when 276 visiting insecure places." This amounts to attack surface reduction, 277 and is clearly beneficial -- this is an advantage of the stealth mode 278 defined in [RFC7288]. However, there are two issues with this 279 advice. First, it relies on recognizing which networks are secure or 280 insecure. This is hard to automate, but relying on end-user judgment 281 may not always provide good results. Second, some protocols such as 282 DHCP cannot be turned off without losing connectivity, which limits 283 the value of this option. 285 It may be possible in many cases to examine a protocol and prevent it 286 from leaking hostnames. This is for example what is attempted for 287 DHCP in [I-D.ietf-dhc-anonymity-profile]. However, it is unclear 288 that we can identify, revisit an fix all the protocols that publish 289 hostnames. 291 We may be able to mitigate most of the effects of hostname leakage by 292 revisiting the way platforms handle hostnames. This is in a way 293 similar to the approach of MAC address randomization described in 294 [I-D.ietf-dhc-anonymity-profile]. Let's assume that the operating 295 system, at the time of connecting to a new network, picks a random 296 hostname and start publicizing that random name in protocols such as 297 DHCP or MDNS, instead of the static value. This will frustrate 298 monitoring by adversaries, without preventing protocols such as DNS 299 SD from operating as expected. 301 Some operating systems, including Windows, support "per network" 302 hostnames, but some other operating systems only support "global" 303 hostnames. In that case, changing the hostname may be difficult if 304 the host is multi-homed, as the same name will be used on several 305 networks. Obviously, further studies are required before the idea of 306 randomized hostnames can be implemented. 308 6. Security Considerations 310 This draft does not introduce any new protocol. It does point to 311 potential privacy issues in a set of existing protocols. 313 7. IANA Considerations 315 This draft does not require any IANA action. 317 8. Acknowledgments 319 Contributions will be gladly acknowledged. 321 9. Informative References 323 [I-D.ietf-dhc-anonymity-profile] 324 Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 325 profile for DHCP clients", draft-ietf-dhc-anonymity- 326 profile-04 (work in progress), October 2015. 328 [I-D.ietf-dhc-dhcp-privacy] 329 Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy 330 considerations for DHCPv4", draft-ietf-dhc-dhcp-privacy-01 331 (work in progress), August 2015. 333 [I-D.ietf-dhc-dhcpv6-privacy] 334 Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 335 considerations for DHCPv6", draft-ietf-dhc- 336 dhcpv6-privacy-01 (work in progress), August 2015. 338 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 339 RFC 1033, DOI 10.17487/RFC1033, November 1987, 340 . 342 [RFC1035] Mockapetris, P., "Domain names - implementation and 343 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 344 November 1987, . 346 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 347 RFC 2131, DOI 10.17487/RFC2131, March 1997, 348 . 350 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 351 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 352 . 354 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 355 specifying the location of services (DNS SRV)", RFC 2782, 356 DOI 10.17487/RFC2782, February 2000, 357 . 359 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 360 C., and M. Carney, "Dynamic Host Configuration Protocol 361 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 362 2003, . 364 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 365 "DNS Extensions to Support IP Version 6", RFC 3596, 366 DOI 10.17487/RFC3596, October 2003, 367 . 369 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 370 Multicast Name Resolution (LLMNR)", RFC 4795, 371 DOI 10.17487/RFC4795, January 2007, 372 . 374 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 375 DOI 10.17487/RFC6762, February 2013, 376 . 378 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 379 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 380 . 382 [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, 383 DOI 10.17487/RFC7288, June 2014, 384 . 386 Authors' Addresses 388 Christian Huitema 389 Microsoft 390 Redmond, WA 98052 391 U.S.A. 393 Email: huitema@microsoft.com 395 Dave Thaler 396 Microsoft 397 Redmond, WA 98052 398 U.S.A. 400 Email: dthaler@microsoft.com