RFC 8117

Current Hostname Practice Considered Harmful

📅 published March 2017, from ietf

Current Hostname Practice Considered Harmful 🎀

Okay bestie, this is RFC 8117, and the title alone is giving main character energy 💅 "Current Hostname Practice Considered Harmful" 💀

Here's the title block tea ☕:

  • Number and category: RFC 8117, Category: Informational, ISSN: 2070-1721 🦋
  • Date: March 2017 📅
  • Authors: C. Huitema (Private Octopus Inc.), D. Thaler (Microsoft), and R. Winter (University of Applied Sciences Augsburg) 👑
  • Obsoletes or updates: The title block doesn't list any RFC that this one obsoletes or updates 🌸

Abstract ✨

Giving your computer a hostname and then publishing it every time you roam from one network to another is the Internet's version of wearing a name tag on your lapel 🏷️ 🙈 Like, everywhere you go, people can read it. This practice can seriously compromise your privacy, so something needs to change to reduce those privacy threats 🔒

There are a few possible fixes, like repairing a bunch of protocols or not disclosing a hostname at all 🛠️ This document describes some of the protocols that reveal hostnames today and sketches another option: replace static hostnames with frequently changing randomized values 🎲 Iconic solution, ngl 🧚

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes 💅

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard. See Section 2 of RFC 7841 for more on that 🤓

For information about the current status of this document, any errata, and how to give feedback on it, check http://www.rfc-editor.org/info/rfc8117 🔗

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved ©️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication of this document. Please read these documents carefully, because they describe your rights and restrictions with respect to this document 📖 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 💜

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Naming Practices  . . . . . . . . . . . . . . . . . . . . . .   3
3.  Partial Identifiers . . . . . . . . . . . . . . . . . . . . .   4
4.  Protocols That Leak Hostnames . . . . . . . . . . . . . . . .   5
  4.1.  DHCP  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
  4.2.  DNS Address to Name Resolution  . . . . . . . . . . . . .   5
  4.3.  Multicast DNS . . . . . . . . . . . . . . . . . . . . . .   6
  4.4.  Link-Local Multicast Name Resolution  . . . . . . . . . .   6
  4.5.  DNS-Based Service Discovery . . . . . . . . . . . . . . .   7
  4.6.  NetBIOS-over-TCP  . . . . . . . . . . . . . . . . . . . .   7
5.  Randomized Hostnames as a Remedy  . . . . . . . . . . . . . .   8
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
8.  Informative References  . . . . . . . . . . . . . . . . . . .   9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction ✨

Giving names to computers is a long-established practice 🖥️ In Internet protocols, these names are called "hostnames" [RFC7719]. Hostnames are normally used together with a domain name suffix to build the Fully Qualified Domain Name (FQDN) of a host [RFC1983]. But it's common to use the hostname on its own in all sorts of applications, from file sharing to network management 📂 Hostnames are typically published as part of domain names, and they can be obtained through a variety of name lookup and discovery protocols 🔍

Hostnames have to be unique within the domain where they're created and used 🫶 They don't have to be globally unique identifiers, but they will always be at least partial identifiers, as discussed in Section 3.

Oversharing through hostnames is a real problem for mobile devices 📱 Adversaries who monitor a remote network, such as a Wi-Fi hot spot, can grab the hostname through passive monitoring or active probing of various Internet protocols, such as DHCP or Multicast DNS (mDNS) 👀 They can then link the hostname to other information from traffic analysis and other sources, and potentially identify the device, its properties, and its user [TRAC2016] 😭

2. Naming Practices 🌈

There are lots of reasons to name computers, especially when they're on a network 🌐 Operating systems like Microsoft Windows or Unix assume that computers have a "hostname." That's how users and admins can do things like ping a computer, add its name to an access control list, remotely mount its disk, or connect through tools like telnet or remote desktop 💻 Other operating systems keep multiple hostnames for different purposes, for example, for use with certain protocols such as mDNS 🧩

On most consumer networks, naming is pretty much up to the user 🎨 Some people pick planets or stars, some pick fruits or flowers, and others pick whatever matches their mood when they unbox the device 🍓 As long as users are careful not to pick a name that's already in use on the same network, anything goes ✨ Very often, though, the operating system suggests a hostname during installation. That suggestion can include the user name, the login name, and information pulled from the device itself, like its brand, model, or maker [TRAC2016] 🎀

Large organizations have more collisions and need a more structured approach 🏢 In theory, organizations could use multiple DNS subdomains to ease the pressure on uniqueness, but in practice many don't, and they insist on unique flat names, if only to simplify network management 🙄 To keep names unique, organizations set naming guidelines and enforce some kind of structured naming. For example, on the Microsoft corporate network, computer names are derived from the login name of the main user, which leads to names like "huitema-test2" for a machine one of the authors used to test software 💜

There's less pressure to name small devices, like smartphones, because they usually don't share their disks or allow remote login 📲 As a result, these devices often have manufacturer-assigned names. Those range from generic names like "Windows Phone" to totally unique ones like BrandX-123456-7890-abcdef. These names often include the device owner's name, the device's brand, and often a hint about which language the owner speaks [TRAC2016] 🌸

3. Partial Identifiers 🕵️‍♀️

Imagine an adversary wants to track people connecting to a specific Wi-Fi hot spot, say, at a railroad station 🚉 Suppose they can retrieve the hostname of one specific laptop. On its own, that might not be enough to identify the laptop's owner 🤔 But what if the adversary sees that the laptop is named "dthaler-laptop" and that it has set up a VPN connection to the Microsoft corporate network? Put those two pieces together and they firmly point to Dave Thaler, who works at Microsoft. Identification successful 😭💅

In that example, a login name was inside the hostname, and that definitely helped. But generic names like "jupiter" or "rosebud" also give partial identification, especially if the adversary keeps a database of which hostnames belong to which users 🗄️ Generic names come from vocabularies with thousands of possible choices, so finding the name shrinks the search a lot. Other info, like the sites someone visits, can quickly fill in the gaps and lead to user identification 🔎

The network's own circumstances matter too 🌐 Experiments on operational networks, such as the IETF meeting network, have shown that with help from external data, like the publicly available IETF attendees list or other sources such as Lightweight Directory Access Protocol (LDAP) servers on the network [TRAC2016], identifying a device's owner can become trivial, even with only partial identifiers in a hostname 😱

Unique names assigned by manufacturers don't directly encode a user identifier 🙅‍♀️ But they're stable and unique to the device across a large context. A name like BrandX-123456-7890-abcdef allows efficient tracking across multiple domains 🛰️ In theory, that only tracks the device and not the user. However, an adversary could link the device to the user some other way, for example, by capturing some cleartext traffic just once. Adversaries could then build databases that link a unique hostname to a user identity, which makes tracking both the user and the device efficient 💀

4. Protocols That Leak Hostnames 🫧

Lots of IETF protocols can leak the "hostname" of a computer. This list isn't exhaustive, but it includes DHCP, DNS address to name resolution, Multicast DNS, Link-Local Multicast Name Resolution, and DNS service discovery 🦋

4.1. DHCP 🌷

Shortly after connecting to a new network, a host can use DHCP [RFC2131] to get an IPv4 address and other parameters [RFC2132]. A DHCP query can reveal the "hostname." DHCP traffic is sent to the broadcast address and is easy to monitor, so adversaries can discover the hostname tied to a computer visiting a particular network 👀 DHCPv6 [RFC3315] has similar issues 🙃

The problems with the hostname and FQDN parameters in DHCP are analyzed in [RFC7819] and [RFC7824]. Possible mitigations are described in [RFC7844] 🛡️

4.2. DNS Address to Name Resolution 🔁

The domain name service design [RFC1035] includes the special domain "in-addr.arpa", which is used to resolve the name of a computer from its IPv4 address, using the PTR format defined in [RFC1033] 🧭 A similar domain, "ip6.arpa", is defined in [RFC3596] for finding the name of a computer from its IPv6 address 💫

Adversaries who see a particular address in use on a specific network can try to retrieve the PTR record for that address. That gets them the computer's hostname, or even its FQDN 😬 This may not be useful on many IPv4 networks because of how common NAT is, but it could work on IPv6 networks 🌐 Other name lookup mechanisms, such as [RFC4620], have similar issues 💜

🎀 to be continued in part 2, bestie 🎀

4.3. Multicast DNS 🎀

Multicast DNS (mDNS) is defined in [RFC6762]. It lets hosts send DNS queries over multicast and get answers back from hosts that are part of the service 🦋

okay so here's the sus part 👀 If an adversary suspects a particular host is on a network, they can send mDNS requests to look up the A or AAAA records tied to that hostname in the .local domain. If anyone replies, boom, the host is confirmed 💀

When a new responder starts up, it must send a set of multicast queries. It does this to check that the name it's advertising is unique on the network, and to fill up the caches of other mDNS hosts 🧚 The problem is that adversaries can watch this traffic and learn the hostname of computers as they join the network they're monitoring. Not me getting my whole name exposed just by plugging in 😭

mDNS also lets queries go out as unicast to port 5353. An adversary might pick unicast over multicast to stay hidden from, e.g., intrusion detection systems 🙈 sneaky, but still a privacy leak, bestie.

Link-Local Multicast Name Resolution (LLMNR) is defined in [RFC4795]. Real talk, it never reached consensus as an IETF standard, but it's widely deployed anyway 💅 Like mDNS, it lets hosts send DNS queries over multicast and get responses from computers running the LLMNR service.

Just like mDNS, LLMNR can be abused by adversaries to confirm a specific host is on a network. They send a multicast request to find the A or AAAA records for the hostname in the .local domain. Same vibe, different protocol 🍓

When an LLMNR responder starts, it sends a set of multicast queries to check that its advertised name is unique on the network. And yep, adversaries can monitor that traffic and find out the hostname of computers as they join the network. It's giving déjà vu 🙃

4.5. DNS-Based Service Discovery 🧚

DNS-based Service Discovery (DNS-SD) is described in [RFC6763]. It lets participating hosts find the location of services that other hosts are offering. It can be used with DNS servers, or together with mDNS in a serverless environment 🌈

Participating hosts publish a service described by an "instance name", which is usually picked by the user doing the publishing. Obviously this is an active disclosure of info, but the privacy stuff can be managed through user control 🫶 Services should only get published when someone actually decides to publish them, and the info shown in the service name should stay firmly under the device owner's control. Their device, their rules!

Now here's the twist 🔥 In theory there shouldn't be any privacy issue. In practice, publishing a service also forces the hostname to get published, because of a chain of dependencies. The service name is used to publish a PTR record announcing the service, and that PTR record typically points to the service name in the local domain. The service names are then used to publish TXT records describing service parameters, and SRV records describing the service location. So the chain drags the hostname along for the ride 😭

SRV records are described in [RFC2782]. Each record contains four parameters: priority, weight, port number, and hostname. The service name in the PTR record is chosen by the user, but the "hostname" in the SRV record is actually the hostname of the device. Plot twist, the device's name is right there in the record 💀

Adversaries can monitor the mDNS traffic linked to DNS-SD and pull out the hostname of any computer advertising any service with DNS-SD. So even if you only share one little service, your hostname is out there too 🦋

4.6. NetBIOS-over-TCP 🍓

Among other things, NetBIOS-over-TCP [RFC1002] implements a name registration and resolution mechanism called the NetBIOS Name Service. In practice, NetBIOS resource names are often based on hostnames, so the name leak is baked right in 💅

NetBIOS lets an application register resource names and resolve those names to IP addresses. In environments without a NetBIOS Name Server, the protocol leans heavily on broadcasts, and resource names can be easily pulled out of those broadcasts 👀 NetBIOS also lets you ask a node directly for the names it has registered (that's node status). Bold of it to just... tell you its own name, ngl 🙈

5. Randomized Hostnames as a Remedy ✨

Okay, so how do we fix this mess? There are a few ways to approach the hostname practices 💖 We could tell people to just turn off any protocol that leaks hostnames, at least when they visit some "insecure" place. We could also go through each standard that publishes hostnames and try to fix the corresponding protocols. Or, we could try to revise the way devices manage the hostname parameter 🧚

Turning off unneeded protocols when visiting insecure places has a lot going for it. It amounts to attack-surface reduction and is clearly beneficial. This is one of the perks of the stealth mode defined in [RFC7288] 🌸 But there are two issues with this advice. First, it relies on recognizing which networks are secure or insecure. That's hard to automate, and relying on end-user judgment may not always give good results 😬 Second, some protocols, like DHCP, can't be turned off without losing connectivity, which limits the value of this option. Also, services that rely on hostname-leaking protocols such as mDNS won't be available when those protocols are switched off. And to make matters worse, hostname-leaking protocols aren't always well-known, since they might be proprietary and come bundled with an installed application instead of being provided by the operating system 💀

It may be possible in many cases to examine a protocol and stop it from leaking hostnames. This is, for example, what's being attempted for DHCP in [RFC7844] 🫶 However, it's unclear whether we can identify, revisit, and fix all the protocols that publish hostnames. In particular, this is impossible for proprietary protocols 😭

We may be able to mitigate most of the effects of hostname leakage by revisiting the way platforms handle hostnames. In a way, this is similar to the approach of Media Access Control (MAC) address randomization described in [RFC7844]. Let's assume that the operating system, when it connects to a new network, picks a random hostname and starts publicizing that random name in protocols such as DHCP or mDNS, instead of the static value. This makes it way harder for adversaries to monitor and identify users, without stopping protocols such as DNS-SD from working as expected ✨ Of course, this has implications for applications that use these protocols, e.g., when the hostname is displayed to users of the application. They won't as easily be able to identify network shares or services based on the hostname carried in the underlying protocols 🙈 Also, generating new hostnames should be synchronized with changes to other tokens used in network protocols, such as the MAC or IP address, to prevent correlation of this information. For example, if the IP address changes but the hostname stays the same, the new IP address can be correlated to belong to the same device based on a leaked hostname. Caught in 4K 📸

Some operating systems, including Windows, support "per network" hostnames, but some other operating systems only support "global" hostnames. In that case, changing the hostname may be difficult if the host is multihomed, since the same name will be used on several networks 😬 Other operating systems already use potentially different hostnames for different purposes. That could be a good model for combining static hostnames and randomized hostnames, based on their potential use and their threat to a user's privacy 🌈

Obviously, further studies are required before the idea of randomized hostnames can be implemented 🔬

6. Security Considerations 🔥

This document does not introduce any new protocol. It does point to potential privacy issues in a set of existing protocols 👀

There are obvious privacy gains from switching to randomized hostnames, and also from changing those names frequently. However, wide deployment might affect security functions or current practices. For example, incident response that uses hostnames to track the source of traffic might be affected. It's common practice to include hostnames and reverse lookup information at various points during an investigation, so this one is a real concern, bestie 😭

7. IANA Considerations 🎀

This document does not require any IANA actions 💅

8. Informative References ✨

Okay bestie, this is the reading list 📚 Every doc here is informative, which means it's background that helps you understand the protocols. Nothing here is a hard requirement, but these are the sources the whole RFC is built on, so they're worth a look 💅

Acknowledgments 🫶

Huge thanks to the members of the INTAREA Working Group 💜 They gave us loads of discussions and reviews, and the doc is so much better for it ✨

Authors' Addresses 🎀

Christian Huitema
Private Octopus Inc.
Friday Harbor, WA  98250
United States of America

Email: huitema@huitema.net


Dave Thaler
Microsoft
Redmond, WA  98052
United States of America

Email: dthaler@microsoft.com


Rolf Winter
University of Applied Sciences Augsburg
Augsburg
DE

Email: rolf.winter@hs-augsburg.de
📦 where this page comes from