idnits 2.17.1 draft-ietf-intarea-hostname-practice-03.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 (July 8, 2016) is 2842 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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: January 9, 2017 R. Winter 6 University of Applied Sciences Augsburg 7 July 8, 2016 9 Current Hostname Practice Considered Harmful 10 draft-ietf-intarea-hostname-practice-03.txt 12 Abstract 14 Giving a hostname to your computer and publishing it as you roam from 15 one network to another is the Internet equivalent of walking around 16 with a name tag affixed to your lapel. This current practice can 17 significantly compromise your privacy, and something should change in 18 order to mitigate these privacy threads. 20 There are several possible remedies, such as fixing a variety of 21 protocols or avoiding disclosing a hostname at all. This document 22 describes some of the protocols that reveal hostnames today and 23 sketches another possible remedy, which is to replace static 24 hostnames by frequently changing randomized values. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 9, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Naming Practices . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Partial Identifiers . . . . . . . . . . . . . . . . . . . . . 4 63 4. Protocols that leak Hostnames . . . . . . . . . . . . . . . . 4 64 4.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. DNS Address to Name Resolution . . . . . . . . . . . . . 5 66 4.3. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 5 67 4.4. Link-local Multicast Name Resolution . . . . . . . . . . 6 68 4.5. DNS-Based Service Discovery . . . . . . . . . . . . . . . 6 69 4.6. NetBIOS-over-TCP . . . . . . . . . . . . . . . . . . . . 7 70 5. Randomized Hostnames as Remedy . . . . . . . . . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 74 9. Informative References . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 There is a long established practice of giving names to computers. 80 In the Internet protocols, these names are referred to as "hostnames" 81 [RFC7719] . Hostnames are normally used in conjunction with a domain 82 name suffix to build the "Fully Qualified Domain Name" (FQDN) of a 83 host. However, it is common practice to use the hostname without 84 further qualification in a variety of applications from file sharing 85 to network management. Hostnames are typically published as part of 86 domain names, and can be obtained through a variety of name lookup 87 and discovery protocols. 89 Hostnames have to be unique within the domain in which they are 90 created and used. They do not have to be globally unique 91 identifiers, but they will always be at least partial identifiers, as 92 discussed in Section 3. 94 The disclosure of information through hostnames creates a problem for 95 mobile devices. Adversaries that monitor a remote network such as a 96 Wi-Fi hot spot can obtain the hostname through passive monitoring or 97 active probing of a variety of Internet protocols, such as for 98 example DHCP, or multicast DNS (mDNS). They can correlate the 99 hostname with various other information extracted from traffic 100 analysis and other information sources, and can potentially identify 101 the device, device properties and its user [TRAC2016]. 103 2. Naming Practices 105 There are many reasons to give names to computers. This is 106 particularly true when computers operate on a network. Operating 107 systems like Microsoft Windows or Unix assume that computers have a 108 "hostname." This enables users and administrators to do things such 109 as ping a computer, add its name to an access control list, remotely 110 mount a computer disk, or connect to the computer through tools such 111 as telnet or remote desktop. Other operating systems maintain 112 multiple hostnames for different purposes, e.g. for use with certain 113 protocols such as mDNS. 115 In most consumer networks, naming is pretty much left to the fancy of 116 the user. Some will pick names of planets or stars, other names of 117 fruits or flowers, and other will pick whatever suits their mood when 118 they unwrap the device. As long as users are careful to not pick a 119 name already in use on the same network, anything goes. Very often 120 however, the operating system is suggesting a hostname at install 121 time, which can contain the user name, the login name and information 122 learned from the device itself such as the brand, model or maker of 123 the device [TRAC2016]. 125 In large organizations, collisions are more likely and a more 126 structured approach is necessary. In theory, organizations could use 127 multiple DNS subdomains to ease the pressure on uniqueness, but in 128 practice many don't and insist on unique flat names, if only to 129 simplify network management. To ensure unique names, organizations 130 will set naming guidelines and enforce some kind of structured 131 naming. For example, within the Microsoft corporate network, 132 computer names are derived from the login name of the main user, 133 leading to names like "huitema-test2" for a machine that one of the 134 authors uses to test software. 136 There is less pressure to assign names to small devices, including 137 for example smart phones, as these devices typically do not enable 138 sharing of their disks or remote login. As a consequence, these 139 devices often have manufacturer assigned names, which vary from very 140 generic like "Windows Phone" to completely unique like "BrandX- 141 123456-7890-abcdef" and often contain the name of the device owner 142 the device's brand name and often also a hint as to which language 143 the device owner speaks [TRAC2016]. 145 3. Partial Identifiers 147 Suppose an adversary wants to track the people connecting to a 148 specific Wi-Fi hot spot, for example in a railroad station. Assume 149 that the adversary is able to retrieve the hostname used by a 150 specific laptop. That, in itself, might not be enough to identify 151 the laptop's owner. Suppose however that the adversary observes that 152 the laptop name is "huitema-laptop" and that the laptop has 153 established a VPN connection to the Microsoft corporate network. The 154 two pieces of information, put together, firmly point to Christian 155 Huitema, employed by Microsoft. The identification is successful. 157 In the example, we saw a login name inside the hostname, and that 158 certainly helped identification. But generic names like "jupiter" or 159 "rosebud" also provide partial identification, especially if the 160 adversary is capable of maintaining a database recording, among other 161 information, the hostnames of devices used by specific users. 162 Generic names are picked from vocabularies that include thousands of 163 potential choices. Finding the name reduces the scope of the search 164 significantly. Other information such as the visited sites will 165 quickly complement that data and can lead to user identification. 167 Also the special circumstances of the network can play a role. 168 Experiments on operational networks such as the IETF meeting network 169 have shown that with the help of external data such as the publicly 170 available IETF attendees list or other data sources such as LDAP 171 servers on the network [TRAC2016], the identification of the device 172 owner can become trivial given only partial identifiers in a 173 hostname. 175 Unique names assigned by manufacturers do not directly encode a user 176 identifier, but they have the property of being stable and unique to 177 the device in a large context. A unique name like "BrandX- 178 123456-7890-abcdef" allows efficient tracking across multiple 179 domains. In theory, this only allows tracking of the device but not 180 of the user. However, an adversary could correlate the device to the 181 user through other means, for example the one-time capture of some 182 clear text traffic. Adversaries could then maintain databases 183 linking unique host name to user identity. This will allow efficient 184 tracking of both the user and the device. 186 4. Protocols that leak Hostnames 188 Many IETF protocols can leak the "hostname" of a computer. A non 189 exhaustive list includes DHCP, DNS address to name resolution, 190 Multicast DNS, Link-local Multicast Name Resolution, and DNS service 191 discovery. 193 4.1. DHCP 195 Shortly after connecting to a new network, a host can use DHCP 196 [RFC2131] to acquire an IPv4 address and other parameters [RFC2132]. 197 A DHCP query can disclose the "hostname." DHCP traffic is sent to 198 the broadcast address and can be easily monitored, enabling 199 adversaries to discover the hostname associated with a computer 200 visiting a particular network. DHCPv6 [RFC3315] shares similar 201 issues. 203 The problems with the hostname and FQDN parameters in DHCP are 204 analyzed in [I-D.ietf-dhc-dhcp-privacy] and 205 [I-D.ietf-dhc-dhcpv6-privacy]. Possible mitigations are described in 206 [I-D.ietf-dhc-anonymity-profile]. 208 4.2. DNS Address to Name Resolution 210 The domain name service design [RFC1035] includes the specification 211 of the special domain "in-addr.arpa" for resolving the name of the 212 computer using a particular IPv4 address, using the PTR format 213 defined in [RFC1033]. A similar domain, "ip6.arpa", is defined in 214 [RFC3596] for finding the name of a computer using a specific IPv6 215 address. 217 Adversaries who observe a particular address in use on a specific 218 network can try to retrieve the PTR record associated with that 219 address, and thus the hostname of the computer, or even the fully 220 qualified domain name of that computer. The retrieval may not be 221 useful in many IPv4 networks due to the prevalence of NAT, but it 222 could work in IPv6 networks. Other name lookup mechanisms, such as 223 [RFC4620], share similar issues. 225 4.3. Multicast DNS 227 Multicast DNS (mDNS) is defined in [RFC6762]. It enables hosts to 228 send DNS queries over multicast, and to elicit responses from hosts 229 participating in the service. 231 If an adversary suspects that a particular host is present on a 232 network, the adversary can send mDNS requests to find, for example, 233 the A or AAAA records associated with the hostname in the ".local" 234 domain. A positive reply will confirm the presence of the host. 236 When a new responder starts, it must send a set of multicast queries 237 to verify that the name that it advertises is unique on the network, 238 and also to populate the caches of other mDNS hosts. Adversaries can 239 monitor this traffic and discover the hostname of computers as they 240 join the monitored network. 242 mDNS further allows to send queries via unicast to port 5353. An 243 adversary might decide to use unicast instead of multicast in order 244 to hide from e.g. intrusion detection systems. 246 4.4. Link-local Multicast Name Resolution 248 Link-local Multicast Name Resolution (LLMNR) is defined in [RFC4795]. 249 The specification did not achieve consensus as an IETF standard, but 250 it is widely deployed. Like mDNS, it enables hosts to send DNS 251 queries over multicast, and to elicit responses from computers 252 implementing the LLMNR service. 254 Like mDNS, LLMNR can be used by adversaries to confirm the presence 255 of a specific host on a network, by issuing a multicast request to 256 find the A or AAAA records associated with the hostname in the 257 ".local" domain. 259 When an LLMNR responder starts, it sends a set of multicast queries 260 to verify that the name that it advertises is unique on the network. 261 Adversaries can monitor this traffic and discover the hostname of 262 computers as they join the monitored network. 264 4.5. DNS-Based Service Discovery 266 DNS-Based Service Discovery (DNS-SD) is described in [RFC6763]. It 267 enables participating hosts to retrieve the location of services 268 proposed by other hosts. It can be used with DNS servers, or in 269 conjunction with mDNS in a server-less environment. 271 Participating hosts publish a service described by an "instance 272 name," typically chosen by the user responsible for the publication. 273 While this is obviously an active disclosure of information, privacy 274 aspects can be mitigated by user control. Services should only be 275 published when deciding to do so, and the information disclosed in 276 the service name should be well under the control of the device's 277 owner. 279 In theory there should not be any privacy issue, but in practice the 280 publication of a service also forces the publication of the hostname, 281 due to a chain of dependencies. The service name is used to publish 282 a PTR record announcing the service. The PTR record typically points 283 to the service name in the local domain. The service names, in turn, 284 are used to publish TXT records describing service parameters, and 285 SRV records describing the service location. 287 SRV records are described in [RFC2782]. Each record contains 4 288 parameters: priority, weight, port number and hostname. While the 289 service name published in the PTR record is chosen by the user, the 290 "hostname" in the SRV record is indeed the hostname of the device. 292 Adversaries can monitor the mDNS traffic associated with DNS-SD and 293 retrieve the hostname of computers advertising any service with DNS- 294 SD. 296 4.6. NetBIOS-over-TCP 298 Amongst other things, NetBIOS-over-TCP ([RFC1002]) implements a name 299 registration and resolution mechanism called the NetBIOS Name 300 Service. In practice, NetBIOS resource names are often based on 301 hostnames. 303 NetBIOS allows an application to register resource names and to 304 resolve such names to IP addresses. In environments without an 305 NetBIOS Name Server, the protocol makes extensive use of broadcasts 306 from which resource names can be easily extracted. NetBIOS also 307 allows querying for the names registered by a node directly (node 308 status). 310 5. Randomized Hostnames as Remedy 312 There are several ways to remedy the hostname practices. We could 313 instruct people to just turn off any protocol that leaks hostnames, 314 at least when they visit some "insecure" place. We could also 315 examine each particular standard that publishes hostnames, and 316 somehow fix the corresponding protocols. Or, we could attempt to 317 revise the way devices manage the hostname parameter. 319 There is a lot of merit in "turning off unneeded protocols when 320 visiting insecure places." This amounts to attack surface reduction, 321 and is clearly beneficial -- this is an advantage of the stealth mode 322 defined in [RFC7288]. However, there are two issues with this 323 advice. First, it relies on recognizing which networks are secure or 324 insecure. This is hard to automate, but relying on end-user judgment 325 may not always provide good results. Second, some protocols such as 326 DHCP cannot be turned off without losing connectivity, which limits 327 the value of this option. Also, the services that rely on protocols 328 that leak hostnames such as mDNS will not be available when switched 329 off. In addition, not always are hostname-leaking protocols well- 330 known as they might be proprietary and come with an installed 331 application instead of being provided by the operating system. 333 It may be possible in many cases to examine a protocol and prevent it 334 from leaking hostnames. This is for example what is attempted for 335 DHCP in [I-D.ietf-dhc-anonymity-profile]. However, it is unclear 336 that we can identify, revisit and fix all the protocols that publish 337 hostnames. In particular, this is impossible for proprietary 338 protocols. 340 We may be able to mitigate most of the effects of hostname leakage by 341 revisiting the way platforms handle hostnames. This is in a way 342 similar to the approach of MAC address randomization described in 343 [I-D.ietf-dhc-anonymity-profile]. Let's assume that the operating 344 system, at the time of connecting to a new network, picks a random 345 hostname and starts publicizing that random name in protocols such as 346 DHCP or mDNS, instead of the static value. This will render 347 monitoring and identification of users by adversaries much more 348 difficult, without preventing protocols such as DNS-SD from operating 349 as expected. This has of course implications on the applications 350 making use of such protocols e.g. when the hostname is being 351 displayed to users of the application. They will not as easily be 352 able to identify e.g. network shares or services based on the 353 hostname carried in the underlying protocols. Also, the generation 354 of new hostnames should be synchronized with the change of other 355 tokens used in network protocols such as the MAC or IP address to 356 prevent correlation of this information. E.g. if the IP address 357 changes but the hostname stays the same, the new IP address can be 358 correlated to belong to the same device based on a leaked hostname. 360 Some operating systems, including Windows, support "per network" 361 hostnames, but some other operating systems only support "global" 362 hostnames. In that case, changing the hostname may be difficult if 363 the host is multi-homed, as the same name will be used on several 364 networks. Other operating systems already use potentially different 365 hostnames for different purposes, which might be a good model to 366 combine both static hostnames and randomized hostnames based on their 367 potential use and threat to a user's privacy. Obviously, further 368 studies are required before the idea of randomized hostnames can be 369 implemented. 371 6. Security Considerations 373 This draft does not introduce any new protocol. It does point to 374 potential privacy issues in a set of existing protocols. 376 7. IANA Considerations 378 This draft does not require any IANA action. 380 8. Acknowledgments 382 Thanks to the members of the INTAREA Working Group for discussions 383 and reviews. 385 9. Informative References 387 [I-D.ietf-dhc-anonymity-profile] 388 Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 389 profile for DHCP clients", draft-ietf-dhc-anonymity- 390 profile-08 (work in progress), February 2016. 392 [I-D.ietf-dhc-dhcp-privacy] 393 Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 394 considerations for DHCP", draft-ietf-dhc-dhcp-privacy-05 395 (work in progress), February 2016. 397 [I-D.ietf-dhc-dhcpv6-privacy] 398 Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 399 considerations for DHCPv6", draft-ietf-dhc- 400 dhcpv6-privacy-05 (work in progress), February 2016. 402 [RFC1002] NetBIOS Working Group in the Defense Advanced Research 403 Projects Agency, Internet Activities Board, and End-to-End 404 Services Task Force, "Protocol standard for a NetBIOS 405 service on a TCP/UDP transport: Detailed specifications", 406 STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, 407 . 409 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC 410 1033, DOI 10.17487/RFC1033, November 1987, 411 . 413 [RFC1035] Mockapetris, P., "Domain names - implementation and 414 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 415 November 1987, . 417 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 418 2131, DOI 10.17487/RFC2131, March 1997, 419 . 421 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 422 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 423 . 425 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 426 specifying the location of services (DNS SRV)", RFC 2782, 427 DOI 10.17487/RFC2782, February 2000, 428 . 430 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 431 C., and M. Carney, "Dynamic Host Configuration Protocol 432 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 433 2003, . 435 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 436 "DNS Extensions to Support IP Version 6", RFC 3596, DOI 437 10.17487/RFC3596, October 2003, 438 . 440 [RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information 441 Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006, 442 . 444 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 445 Multicast Name Resolution (LLMNR)", RFC 4795, DOI 446 10.17487/RFC4795, January 2007, 447 . 449 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 450 DOI 10.17487/RFC6762, February 2013, 451 . 453 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 454 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 455 . 457 [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, DOI 458 10.17487/RFC7288, June 2014, 459 . 461 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 462 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 463 2015, . 465 [TRAC2016] 466 Faath, M., Weisshaar, F., and R. Winter, "How Broadcast 467 Data Reveals Your Identity and Social Graph", 7th 468 International Workshop on TRaffic Analysis and 469 Characterization IEEE TRAC 2016, September 2016. 471 Authors' Addresses 472 Christian Huitema 473 Microsoft 474 Redmond, WA 98052 475 U.S.A. 477 Email: huitema@microsoft.com 479 Dave Thaler 480 Microsoft 481 Redmond, WA 98052 482 U.S.A. 484 Email: dthaler@microsoft.com 486 Rolf Winter 487 University of Applied Sciences Augsburg 488 Augsburg 489 DE 491 Email: rolf.winter@hs-augsburg.de