draft-ietf-intarea-hostname-practice-05.txt   rfc8117.txt 
Network Working Group C. Huitema Internet Engineering Task Force (IETF) C. Huitema
Internet-Draft Private Octopus Inc. Request for Comments: 8117 Private Octopus Inc.
Intended status: Informational D. Thaler Category: Informational D. Thaler
Expires: August 7, 2017 Microsoft ISSN: 2070-1721 Microsoft
R. Winter R. Winter
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
February 3, 2017 March 2017
Current Hostname Practice Considered Harmful Current Hostname Practice Considered Harmful
draft-ietf-intarea-hostname-practice-05.txt
Abstract Abstract
Giving a hostname to your computer and publishing it as you roam from Giving a hostname to your computer and publishing it as you roam from
one network to another is the Internet equivalent of walking around one network to another is the Internet's equivalent of walking around
with a name tag affixed to your lapel. This current practice can with a name tag affixed to your lapel. This current practice can
significantly compromise your privacy, and something should change in significantly compromise your privacy, and something should change in
order to mitigate these privacy threats. order to mitigate these privacy threats.
There are several possible remedies, such as fixing a variety of There are several possible remedies, such as fixing a variety of
protocols or avoiding disclosing a hostname at all. This document protocols or avoiding disclosing a hostname at all. This document
describes some of the protocols that reveal hostnames today and describes some of the protocols that reveal hostnames today and
sketches another possible remedy, which is to replace static sketches another possible remedy, which is to replace static
hostnames by frequently changing randomized values. hostnames by frequently changing randomized values.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on August 7, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8117.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Naming Practices . . . . . . . . . . . . . . . . . . . . . . 3 2. Naming Practices . . . . . . . . . . . . . . . . . . . . . . 3
3. Partial Identifiers . . . . . . . . . . . . . . . . . . . . . 4 3. Partial Identifiers . . . . . . . . . . . . . . . . . . . . . 4
4. Protocols that leak Hostnames . . . . . . . . . . . . . . . . 4 4. Protocols That Leak Hostnames . . . . . . . . . . . . . . . . 5
4.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. DNS Address to Name Resolution . . . . . . . . . . . . . 5 4.2. DNS Address to Name Resolution . . . . . . . . . . . . . 5
4.3. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Link-local Multicast Name Resolution . . . . . . . . . . 6 4.4. Link-Local Multicast Name Resolution . . . . . . . . . . 6
4.5. DNS-Based Service Discovery . . . . . . . . . . . . . . . 6 4.5. DNS-Based Service Discovery . . . . . . . . . . . . . . . 7
4.6. NetBIOS-over-TCP . . . . . . . . . . . . . . . . . . . . 7 4.6. NetBIOS-over-TCP . . . . . . . . . . . . . . . . . . . . 7
5. Randomized Hostnames as Remedy . . . . . . . . . . . . . . . 7 5. Randomized Hostnames as a Remedy . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. Informative References . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
There is a long established practice of giving names to computers. There is a long established practice of giving names to computers.
In the Internet protocols, these names are referred to as "hostnames" In the Internet protocols, these names are referred to as "hostnames"
[RFC7719] . Hostnames are normally used in conjunction with a domain [RFC7719]. Hostnames are normally used in conjunction with a domain
name suffix to build the "Fully Qualified Domain Name" (FQDN) of a name suffix to build the Fully Qualified Domain Name (FQDN) of a host
host [RFC1983]. However, it is common practice to use the hostname [RFC1983]. However, it is common practice to use the hostname
without further qualification in a variety of applications from file without further qualification in a variety of applications from file
sharing to network management. Hostnames are typically published as sharing to network management. Hostnames are typically published as
part of domain names, and can be obtained through a variety of name part of domain names and can be obtained through a variety of name
lookup and discovery protocols. lookup and discovery protocols.
Hostnames have to be unique within the domain in which they are Hostnames have to be unique within the domain in which they are
created and used. They do not have to be globally unique created and used. They do not have to be globally unique
identifiers, but they will always be at least partial identifiers, as identifiers, but they will always be at least partial identifiers, as
discussed in Section 3. discussed in Section 3.
The disclosure of information through hostnames creates a problem for The disclosure of information through hostnames creates a problem for
mobile devices. Adversaries that monitor a remote network such as a mobile devices. Adversaries that monitor a remote network such as a
Wi-Fi hot spot can obtain the hostname through passive monitoring or Wi-Fi hot spot can obtain the hostname through passive monitoring or
active probing of a variety of Internet protocols, such as for active probing of a variety of Internet protocols, such as DHCP or
example DHCP, or multicast DNS (mDNS). They can correlate the Multicast DNS (mDNS). They can correlate the hostname with various
hostname with various other information extracted from traffic other information extracted from traffic analysis and other
analysis and other information sources, and can potentially identify information sources, and they can potentially identify the device,
the device, device properties and its user [TRAC2016]. device properties, and its user [TRAC2016].
2. Naming Practices 2. Naming Practices
There are many reasons to give names to computers. This is There are many reasons to give names to computers. This is
particularly true when computers operate on a network. Operating particularly true when computers operate on a network. Operating
systems like Microsoft Windows or Unix assume that computers have a systems like Microsoft Windows or Unix assume that computers have a
"hostname." This enables users and administrators to do things such "hostname." This enables users and administrators to do things such
as ping a computer, add its name to an access control list, remotely as ping a computer, add its name to an access control list, remotely
mount a computer disk, or connect to the computer through tools such mount a computer disk, or connect to the computer through tools such
as telnet or remote desktop. Other operating systems maintain as telnet or remote desktop. Other operating systems maintain
multiple hostnames for different purposes, e.g. for use with certain multiple hostnames for different purposes, e.g., for use with certain
protocols such as mDNS. protocols such as mDNS.
In most consumer networks, naming is pretty much left to the fancy of In most consumer networks, naming is pretty much left to the
the user. Some will pick names of planets or stars, other names of discretion of the user. Some will pick names of planets or stars,
fruits or flowers, and other will pick whatever suits their mood when others will pick names of fruits or flowers, and still others will
they unwrap the device. As long as users are careful to not pick a pick whatever suits their mood when they unwrap the device. As long
name already in use on the same network, anything goes. Very often as users are careful to not pick a name already in use on the same
however, the operating system is suggesting a hostname at install network, anything goes. Very often, however, the operating system
time, which can contain the user name, the login name and information suggests a hostname at the time of installation, which can contain
learned from the device itself such as the brand, model or maker of the user name, the login name, and information learned from the
the device [TRAC2016]. device itself such as the brand, model, or maker of the device
[TRAC2016].
In large organizations, collisions are more likely and a more In large organizations, collisions are more likely and a more
structured approach is necessary. In theory, organizations could use structured approach is necessary. In theory, organizations could use
multiple DNS subdomains to ease the pressure on uniqueness, but in multiple DNS subdomains to ease the pressure on uniqueness, but in
practice many don't and insist on unique flat names, if only to practice many don't and insist on unique flat names, if only to
simplify network management. To ensure unique names, organizations simplify network management. To ensure unique names, organizations
will set naming guidelines and enforce some kind of structured will set naming guidelines and enforce some kind of structured
naming. For example, within the Microsoft corporate network, naming. For example, within the Microsoft corporate network,
computer names are derived from the login name of the main user, computer names are derived from the login name of the main user,
leading to names like "huitema-test2" for a machine that one of the which leads to names like "huitema-test2" for a machine that one of
authors used to test software. the authors used to test software.
There is less pressure to assign names to small devices, including There is less pressure to assign names to small devices including,
for example smart phones, as these devices typically do not enable for example, smart phones, as these devices typically do not enable
sharing of their disks or remote login. As a consequence, these sharing of their disks or remote login. As a consequence, these
devices often have manufacturer assigned names, which vary from very devices often have manufacturer-assigned names, which vary from
generic like "Windows Phone" to completely unique like "BrandX- generic names like "Windows Phone" to completely unique names like
123456-7890-abcdef" and often contain the name of the device owner, "BrandX-123456-7890-abcdef" and often contain the name of the device
the device's brand name, and often also a hint as to which language owner, the device's brand name, and often also a hint as to which
the device owner speaks [TRAC2016]. language the device owner speaks [TRAC2016].
3. Partial Identifiers 3. Partial Identifiers
Suppose an adversary wants to track the people connecting to a Suppose an adversary wants to track the people connecting to a
specific Wi-Fi hot spot, for example in a railroad station. Assume specific Wi-Fi hot spot, for example, in a railroad station. Assume
that the adversary is able to retrieve the hostname used by a that the adversary is able to retrieve the hostname used by a
specific laptop. That, in itself, might not be enough to identify specific laptop. That, in itself, might not be enough to identify
the laptop's owner. Suppose however that the adversary observes that the laptop's owner. Suppose, however, that the adversary observes
the laptop name is "dthaler-laptop" and that the laptop has that the laptop name is "dthaler-laptop" and that the laptop has
established a VPN connection to the Microsoft corporate network. The established a VPN connection to the Microsoft corporate network. The
two pieces of information, put together, firmly point to Dave Thaler, two pieces of information, put together, firmly point to Dave Thaler,
employed by Microsoft. The identification is successful. employed by Microsoft. The identification is successful.
In the example, we saw a login name inside the hostname, and that In the example, we saw a login name inside the hostname, and that
certainly helped identification. But generic names like "jupiter" or certainly helped identification. But generic names like "jupiter" or
"rosebud" also provide partial identification, especially if the "rosebud" also provide partial identification, especially if the
adversary is capable of maintaining a database recording, among other adversary is capable of maintaining a database recording, among other
information, the hostnames of devices used by specific users. information, the hostnames of devices used by specific users.
Generic names are picked from vocabularies that include thousands of Generic names are picked from vocabularies that include thousands of
potential choices. Finding the name reduces the scope of the search potential choices. Finding the name reduces the scope of the search
significantly. Other information such as the visited sites will significantly. Other information such as the visited sites will
quickly complement that data and can lead to user identification. quickly complement that data and can lead to user identification.
Also the special circumstances of the network can play a role. Also, the special circumstances of the network can play a role.
Experiments on operational networks such as the IETF meeting network Experiments on operational networks such as the IETF meeting network
have shown that with the help of external data such as the publicly have shown that, with the help of external data such as the publicly
available IETF attendees list or other data sources such as LDAP available IETF attendees list or other data sources such as
servers on the network [TRAC2016], the identification of the device Lightweight Directory Access Protocol (LDAP) servers on the network
owner can become trivial given only partial identifiers in a [TRAC2016], the identification of the device owner can become trivial
hostname. given only partial identifiers in a hostname.
Unique names assigned by manufacturers do not directly encode a user Unique names assigned by manufacturers do not directly encode a user
identifier, but they have the property of being stable and unique to identifier, but they have the property of being stable and unique to
the device in a large context. A unique name like "BrandX- the device in a large context. A unique name like "BrandX-
123456-7890-abcdef" allows efficient tracking across multiple 123456-7890-abcdef" allows efficient tracking across multiple
domains. In theory, this only allows tracking of the device but not domains. In theory, this only allows tracking of the device but not
of the user. However, an adversary could correlate the device to the of the user. However, an adversary could correlate the device to the
user through other means, for example the one-time capture of some user through other means, for example, the one-time capture of some
clear text traffic. Adversaries could then maintain databases cleartext traffic. Adversaries could then maintain databases linking
linking unique host name to user identity. This will allow efficient a unique hostname to a user identity. This will allow efficient
tracking of both the user and the device. tracking of both the user and the device.
4. Protocols that leak Hostnames 4. Protocols That Leak Hostnames
Many IETF protocols can leak the "hostname" of a computer. A non Many IETF protocols can leak the "hostname" of a computer. A non-
exhaustive list includes DHCP, DNS address to name resolution, exhaustive list includes DHCP, DNS address to name resolution,
Multicast DNS, Link-local Multicast Name Resolution, and DNS service Multicast DNS, Link-local Multicast Name Resolution, and DNS service
discovery. discovery.
4.1. DHCP 4.1. DHCP
Shortly after connecting to a new network, a host can use DHCP Shortly after connecting to a new network, a host can use DHCP
[RFC2131] to acquire an IPv4 address and other parameters [RFC2132]. [RFC2131] to acquire an IPv4 address and other parameters [RFC2132].
A DHCP query can disclose the "hostname." DHCP traffic is sent to A DHCP query can disclose the "hostname." DHCP traffic is sent to
the broadcast address and can be easily monitored, enabling the broadcast address and can be easily monitored, enabling
skipping to change at page 5, line 30 skipping to change at page 5, line 51
The domain name service design [RFC1035] includes the specification The domain name service design [RFC1035] includes the specification
of the special domain "in-addr.arpa" for resolving the name of the of the special domain "in-addr.arpa" for resolving the name of the
computer using a particular IPv4 address, using the PTR format computer using a particular IPv4 address, using the PTR format
defined in [RFC1033]. A similar domain, "ip6.arpa", is defined in defined in [RFC1033]. A similar domain, "ip6.arpa", is defined in
[RFC3596] for finding the name of a computer using a specific IPv6 [RFC3596] for finding the name of a computer using a specific IPv6
address. address.
Adversaries who observe a particular address in use on a specific Adversaries who observe a particular address in use on a specific
network can try to retrieve the PTR record associated with that network can try to retrieve the PTR record associated with that
address, and thus the hostname of the computer, or even the fully address and thus the hostname of the computer, or even the FQDN of
qualified domain name of that computer. The retrieval may not be that computer. The retrieval may not be useful in many IPv4 networks
useful in many IPv4 networks due to the prevalence of NAT, but it due to the prevalence of NAT, but it could work in IPv6 networks.
could work in IPv6 networks. Other name lookup mechanisms, such as Other name lookup mechanisms, such as [RFC4620], share similar
[RFC4620], share similar issues. issues.
4.3. Multicast DNS 4.3. Multicast DNS
Multicast DNS (mDNS) is defined in [RFC6762]. It enables hosts to Multicast DNS (mDNS) is defined in [RFC6762]. It enables hosts to
send DNS queries over multicast, and to elicit responses from hosts send DNS queries over multicast and to elicit responses from hosts
participating in the service. participating in the service.
If an adversary suspects that a particular host is present on a If an adversary suspects that a particular host is present on a
network, the adversary can send mDNS requests to find, for example, network, the adversary can send mDNS requests to find, for example,
the A or AAAA records associated with the hostname in the ".local" the A or AAAA records associated with the hostname in the ".local"
domain. A positive reply will confirm the presence of the host. domain. A positive reply will confirm the presence of the host.
When a new responder starts, it must send a set of multicast queries When a new responder starts, it must send a set of multicast queries
to verify that the name that it advertises is unique on the network, to verify that the name that it advertises is unique on the network
and also to populate the caches of other mDNS hosts. Adversaries can and to populate the caches of other mDNS hosts. Adversaries can
monitor this traffic and discover the hostname of computers as they monitor this traffic and discover the hostname of computers as they
join the monitored network. join the monitored network.
mDNS further allows to send queries via unicast to port 5353. An mDNS further allows queries to be sent via unicast to port 5353. An
adversary might decide to use unicast instead of multicast in order adversary might decide to use unicast instead of multicast in order
to hide from e.g. intrusion detection systems. to hide from, e.g., intrusion detection systems.
4.4. Link-local Multicast Name Resolution 4.4. Link-Local Multicast Name Resolution
Link-local Multicast Name Resolution (LLMNR) is defined in [RFC4795]. Link-Local Multicast Name Resolution (LLMNR) is defined in [RFC4795].
The specification did not achieve consensus as an IETF standard, but The specification did not achieve consensus as an IETF standard, but
it is widely deployed. Like mDNS, it enables hosts to send DNS it is widely deployed. Like mDNS, it enables hosts to send DNS
queries over multicast, and to elicit responses from computers queries over multicast and to elicit responses from computers
implementing the LLMNR service. implementing the LLMNR service.
Like mDNS, LLMNR can be used by adversaries to confirm the presence Like mDNS, LLMNR can be used by adversaries to confirm the presence
of a specific host on a network, by issuing a multicast request to of a specific host on a network by issuing a multicast request to
find the A or AAAA records associated with the hostname in the find the A or AAAA records associated with the hostname in the
".local" domain. ".local" domain.
When an LLMNR responder starts, it sends a set of multicast queries When an LLMNR responder starts, it sends a set of multicast queries
to verify that the name that it advertises is unique on the network. to verify that the name that it advertises is unique on the network.
Adversaries can monitor this traffic and discover the hostname of Adversaries can monitor this traffic and discover the hostname of
computers as they join the monitored network. computers as they join the monitored network.
4.5. DNS-Based Service Discovery 4.5. DNS-Based Service Discovery
DNS-Based Service Discovery (DNS-SD) is described in [RFC6763]. It DNS-based Service Discovery (DNS-SD) is described in [RFC6763]. It
enables participating hosts to retrieve the location of services enables participating hosts to retrieve the location of services
proposed by other hosts. It can be used with DNS servers, or in proposed by other hosts. It can be used with DNS servers or in
conjunction with mDNS in a server-less environment. conjunction with mDNS in a serverless environment.
Participating hosts publish a service described by an "instance Participating hosts publish a service described by an "instance
name", typically chosen by the user responsible for the publication. name", which is typically chosen by the user responsible for the
While this is obviously an active disclosure of information, privacy publication. While this is obviously an active disclosure of
aspects can be mitigated by user control. Services should only be information, privacy aspects can be mitigated by user control.
published when deciding to do so, and the information disclosed in Services should only be published when deciding to do so, and the
the service name should be well under the control of the device's information disclosed in the service name should be well under the
owner. control of the device's owner.
In theory there should not be any privacy issue, but in practice the In theory, there should not be any privacy issue, but in practice the
publication of a service also forces the publication of the hostname, publication of a service also forces the publication of the hostname
due to a chain of dependencies. The service name is used to publish due to a chain of dependencies. The service name is used to publish
a PTR record announcing the service. The PTR record typically points a PTR record announcing the service. The PTR record typically points
to the service name in the local domain. The service names, in turn, to the service name in the local domain. The service names, in turn,
are used to publish TXT records describing service parameters, and are used to publish TXT records describing service parameters and SRV
SRV records describing the service location. records describing the service location.
SRV records are described in [RFC2782]. Each record contains 4 SRV records are described in [RFC2782]. Each record contains four
parameters: priority, weight, port number and hostname. While the parameters: priority, weight, port number, and hostname. While the
service name published in the PTR record is chosen by the user, the service name published in the PTR record is chosen by the user, the
"hostname" in the SRV record is indeed the hostname of the device. "hostname" in the SRV record is indeed the hostname of the device.
Adversaries can monitor the mDNS traffic associated with DNS-SD and Adversaries can monitor the mDNS traffic associated with DNS-SD and
retrieve the hostname of computers advertising any service with DNS- retrieve the hostname of computers advertising any service with DNS-
SD. SD.
4.6. NetBIOS-over-TCP 4.6. NetBIOS-over-TCP
Amongst other things, NetBIOS-over-TCP ([RFC1002]) implements a name Amongst other things, NetBIOS-over-TCP [RFC1002] implements a name
registration and resolution mechanism called the NetBIOS Name registration and resolution mechanism called the NetBIOS Name
Service. In practice, NetBIOS resource names are often based on Service. In practice, NetBIOS resource names are often based on
hostnames. hostnames.
NetBIOS allows an application to register resource names and to NetBIOS allows an application to register resource names and to
resolve such names to IP addresses. In environments without an resolve such names to IP addresses. In environments without a
NetBIOS Name Server, the protocol makes extensive use of broadcasts NetBIOS Name Server, the protocol makes extensive use of broadcasts
from which resource names can be easily extracted. NetBIOS also from which resource names can be easily extracted. NetBIOS also
allows querying for the names registered by a node directly (node allows querying for the names registered by a node directly (node
status). status).
5. Randomized Hostnames as Remedy 5. Randomized Hostnames as a Remedy
There are several ways to remedy the hostname practices. We could There are several ways to remedy the hostname practices. We could
instruct people to just turn off any protocol that leaks hostnames, instruct people to just turn off any protocol that leaks hostnames,
at least when they visit some "insecure" place. We could also at least when they visit some "insecure" place. We could also
examine each particular standard that publishes hostnames, and examine each particular standard that publishes hostnames and somehow
somehow fix the corresponding protocols. Or, we could attempt to fix the corresponding protocols. Or, we could attempt to revise the
revise the way devices manage the hostname parameter. way devices manage the hostname parameter.
There is a lot of merit in "turning off unneeded protocols when There is a lot of merit in turning off unneeded protocols when
visiting insecure places." This amounts to attack surface reduction, visiting insecure places. This amounts to attack-surface reduction
and is clearly beneficial -- this is an advantage of the stealth mode and is clearly beneficial -- this is an advantage of the stealth mode
defined in [RFC7288]. However, there are two issues with this defined in [RFC7288]. However, there are two issues with this
advice. First, it relies on recognizing which networks are secure or advice. First, it relies on recognizing which networks are secure or
insecure. This is hard to automate, but relying on end-user judgment insecure. This is hard to automate, but relying on end-user judgment
may not always provide good results. Second, some protocols such as may not always provide good results. Second, some protocols such as
DHCP cannot be turned off without losing connectivity, which limits DHCP cannot be turned off without losing connectivity, which limits
the value of this option. Also, the services that rely on protocols the value of this option. Also, the services that rely on protocols
that leak hostnames such as mDNS will not be available when switched that leak hostnames such as mDNS will not be available when switched
off. In addition, not always are hostname-leaking protocols well- off. In addition, not always are hostname-leaking protocols well-
known as they might be proprietary and come with an installed known, as they might be proprietary and come with an installed
application instead of being provided by the operating system. application instead of being provided by the operating system.
It may be possible in many cases to examine a protocol and prevent it It may be possible in many cases to examine a protocol and prevent it
from leaking hostnames. This is for example what is attempted for from leaking hostnames. This is, for example, what is attempted for
DHCP in [RFC7844]. However, it is unclear that we can identify, DHCP in [RFC7844]. However, it is unclear that we can identify,
revisit and fix all the protocols that publish hostnames. In revisit, and fix all the protocols that publish hostnames. In
particular, this is impossible for proprietary protocols. particular, this is impossible for proprietary protocols.
We may be able to mitigate most of the effects of hostname leakage by We may be able to mitigate most of the effects of hostname leakage by
revisiting the way platforms handle hostnames. This is in a way revisiting the way platforms handle hostnames. In a way, this is
similar to the approach of MAC address randomization described in similar to the approach of Media Access Control (MAC) address
[RFC7844]. Let's assume that the operating system, at the time of randomization described in [RFC7844]. Let's assume that the
connecting to a new network, picks a random hostname and starts operating system, at the time of connecting to a new network, picks a
publicizing that random name in protocols such as DHCP or mDNS, random hostname and starts publicizing that random name in protocols
instead of the static value. This will render monitoring and such as DHCP or mDNS, instead of the static value. This will render
identification of users by adversaries much more difficult, without monitoring and identification of users by adversaries much more
preventing protocols such as DNS-SD from operating as expected. This difficult without preventing protocols such as DNS-SD from operating
has of course implications on the applications making use of such as expected. This, of course, has implications on the applications
protocols e.g. when the hostname is being displayed to users of the making use of such protocols, e.g., when the hostname is being
application. They will not as easily be able to identify e.g. displayed to users of the application. They will not as easily be
network shares or services based on the hostname carried in the able to identify, e.g., network shares or services based on the
underlying protocols. Also, the generation of new hostnames should hostname carried in the underlying protocols. Also, the generation
be synchronized with the change of other tokens used in network of new hostnames should be synchronized with the change of other
protocols such as the MAC or IP address to prevent correlation of tokens used in network protocols such as the MAC or IP address to
this information. E.g. if the IP address changes but the hostname prevent correlation of this information. For example, if the IP
stays the same, the new IP address can be correlated to belong to the address changes but the hostname stays the same, the new IP address
same device based on a leaked hostname. can be correlated to belong to the same device based on a leaked
hostname.
Some operating systems, including Windows, support "per network" Some operating systems, including Windows, support "per network"
hostnames, but some other operating systems only support "global" hostnames, but some other operating systems only support "global"
hostnames. In that case, changing the hostname may be difficult if hostnames. In that case, changing the hostname may be difficult if
the host is multi-homed, as the same name will be used on several the host is multihomed, as the same name will be used on several
networks. Other operating systems already use potentially different networks. Other operating systems already use potentially different
hostnames for different purposes, which might be a good model to hostnames for different purposes, which might be a good model to
combine both static hostnames and randomized hostnames based on their combine both static hostnames and randomized hostnames based on their
potential use and threat to a user's privacy. potential use and threat to a user's privacy.
Obviously, further studies are required before the idea of randomized Obviously, further studies are required before the idea of randomized
hostnames can be implemented. hostnames can be implemented.
6. Security Considerations 6. Security Considerations
This draft does not introduce any new protocol. It does point to This document does not introduce any new protocol. It does point to
potential privacy issues in a set of existing protocols. potential privacy issues in a set of existing protocols.
There are obvious privacy gains to changing to randomized hostnames There are obvious privacy gains to changing to randomized hostnames
and also to change these names frequently. Wide deployment might and also to changing these names frequently. However, wide
however affect security functions or current practices. For example, deployment might affect security functions or current practices. For
incident response using hostnames to track the source of traffic example, incident response using hostnames to track the source of
might be affected. It is common practice to include hostnames and traffic might be affected. It is common practice to include
reverse lookup information at various times during an investigation. hostnames and reverse lookup information at various times during an
investigation.
7. IANA Considerations 7. IANA Considerations
This draft does not require any IANA action. This document does not require any IANA actions.
8. Acknowledgments
Thanks to the members of the INTAREA Working Group for discussions
and reviews.
9. Informative References 8. Informative References
[RFC1002] NetBIOS Working Group in the Defense Advanced Research [RFC1002] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, and End-to-End Projects Agency, Internet Activities Board, and End-to-End
Services Task Force, "Protocol standard for a NetBIOS Services Task Force, "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Detailed specifications", service on a TCP/UDP transport: Detailed specifications",
STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987,
<http://www.rfc-editor.org/info/rfc1002>. <http://www.rfc-editor.org/info/rfc1002>.
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", [RFC1033] Lottor, M., "Domain Administrators Operations Guide",
RFC 1033, DOI 10.17487/RFC1033, November 1987, RFC 1033, DOI 10.17487/RFC1033, November 1987,
skipping to change at page 11, line 5 skipping to change at page 11, line 27
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
Considerations for DHCPv6", RFC 7824, Considerations for DHCPv6", RFC 7824,
DOI 10.17487/RFC7824, May 2016, DOI 10.17487/RFC7824, May 2016,
<http://www.rfc-editor.org/info/rfc7824>. <http://www.rfc-editor.org/info/rfc7824>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844, Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016, DOI 10.17487/RFC7844, May 2016,
<http://www.rfc-editor.org/info/rfc7844>. <http://www.rfc-editor.org/info/rfc7844>.
[TRAC2016] [TRAC2016] Faath, M., Winter, R., and F. Weisshaar, "How Broadcast
Faath, M., Weisshaar, F., and R. Winter, "How Broadcast Data Reveals Your Identity and Social Graph", IEEE,
Data Reveals Your Identity and Social Graph", 7th Wireless Communications and Mobile Computing Conference
International Workshop on TRaffic Analysis and (IWCMC), 2016 International,
Characterization IEEE TRAC 2016, September 2016. DOI 10.1109/IWCMC.2016.7577084, September 2016.
Acknowledgments
Thanks to the members of the INTAREA Working Group for discussions
and reviews.
Authors' Addresses Authors' Addresses
Christian Huitema Christian Huitema
Private Octopus Inc. Private Octopus Inc.
Friday Harbor, WA 98250 Friday Harbor, WA 98250
U.S.A. United States of America
Email: huitema@huitema.net Email: huitema@huitema.net
Dave Thaler Dave Thaler
Microsoft Microsoft
Redmond, WA 98052 Redmond, WA 98052
U.S.A. United States of America
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
Rolf Winter Rolf Winter
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
Augsburg Augsburg
DE DE
Email: rolf.winter@hs-augsburg.de Email: rolf.winter@hs-augsburg.de
 End of changes. 59 change blocks. 
150 lines changed or deleted 151 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/