draft-ietf-intarea-hostname-practice-00.txt   draft-ietf-intarea-hostname-practice-01.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft D. Thaler Internet-Draft D. Thaler
Intended status: Informational Microsoft Intended status: Informational Microsoft
Expires: April 15, 2016 October 13, 2015 Expires: October 17, 2016 April 15, 2016
Current Hostname Practice Considered Harmful Current Hostname Practice Considered Harmful
draft-ietf-intarea-hostname-practice-00.txt draft-ietf-intarea-hostname-practice-01.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
network to hot spot is the Internet equivalent of walking around with one network to another is the Internet equivalent of walking around
a name tag affixed to your lapel. The practice can significantly with a name tag affixed to your lapel. This current practice can
compromise your privacy, and should stop. significantly compromise your privacy, and something should change in
order to mitigate these privacy threads.
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
studies another possible remedy, which is to replace the static describes some of the protocols that reveal hostnames today and
hostnames by frequently changing randomized values. This idea sketches another possible remedy, which is to replace static
obviously needs more work. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 15, 2016. This Internet-Draft will expire on October 17, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Naming practices . . . . . . . . . . . . . . . . . . . . . . 3 2. Naming Practices . . . . . . . . . . . . . . . . . . . . . . 3
3. Partial identifiers . . . . . . . . . . . . . . . . . . . . . 3 3. Partial Identifiers . . . . . . . . . . . . . . . . . . . . . 4
4. Protocols that leak hostnames . . . . . . . . . . . . . . . . 4 4. Protocols that leak Hostnames . . . . . . . . . . . . . . . . 4
4.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. DNS address to name resolution . . . . . . . . . . . . . 4 4.2. DNS Address to Name Resolution . . . . . . . . . . . . . 5
4.3. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Link-local Multicast Name Resolution . . . . . . . . . . 5 4.4. Link-local Multicast Name Resolution . . . . . . . . . . 6
4.5. DNS service discovery . . . . . . . . . . . . . . . . . . 5 4.5. DNS-Based Service Discovery . . . . . . . . . . . . . . . 6
5. Randomized Host Names as Remedy . . . . . . . . . . . . . . . 6 5. Randomized Hostames as Remedy . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . 7 9. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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 In the Internet protocols, these names are referred to as "hostnames"
"hostnames." hostnames are normally used in conjunction with a domain [RFC7719] . Hostnames are normally used in conjunction with a domain
name prefix to build the "Fully Qualified Domain Name" (FQDN) of a name suffix to build the "Fully Qualified Domain Name" (FQDN) of a
host. However, it is common practice to use the hostname without host. However, it is common practice to use the hostname without
further qualification in a variety of applications from file sharing further qualification in a variety of applications from file sharing
to network management. Hostnames are typically published as part of to network management. Hostnames are typically published as part of
domain names, and can be obtained through a variety of name lookups domain names, and can be obtained through a variety of name lookup
and discovery protocols. 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 or active Wi-Fi hot spot can obtain the hostname through passive monitoring or
monitoring of a variety of Internet protocols, such as for example active probing of a variety of Internet protocols, such as for
DHCP, or multicast DNS. They can correlate the hostname with various example DHCP, or multicast DNS (mDNS). They can correlate the
other information extracted from traffic analysis, and identify the hostname with various other information extracted from traffic
device and its user. analysis and other information sources, and can potentially identify
the device, 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 enable 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. as telnet or remote desktop. Other operating systems maintain
multiple hostnames for different purposes, e.g. for use with certain
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 fancy of
the user. Some will pick names of planets or stars, other names of the user. Some will pick names of planets or stars, other names of
fruits or flowers, and other will pick whatever suits their mood when fruits or flowers, and other will pick whatever suits their mood when
they unwrap the device. As long as users are careful to not pick a they unwrap the device. As long as users are careful to not pick a
name already in use on the same network, anything goes. name already in use on the same network, anything goes. Very often
however, the operating system is suggesting a hostname at install
time, which can contain the user name, the login name and information
learned from the 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 leading to names like "huitema-test2" for a machine that one of the
authors uses to test software. authors uses 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 very
generic like "Windows Phone" to completely unique like "BrandX- generic like "Windows Phone" to completely unique like "BrandX-
123456-7890-abcdef." 123456-7890-abcdef" and often contain the name of the device owner
the device's brand name and often also a hint as to which 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, is not enough to identify the specific laptop. That, in itself, might not be enough to identify
laptop's owner. Suppose however that the adversary observes that the the laptop's owner. Suppose however that the adversary observes that
laptop name is "huitema-laptop" and that the laptop has established a the laptop name is "huitema-laptop" and that the laptop has
VPN connection to the Microsoft corporate network. The two pieces of established a VPN connection to the Microsoft corporate network. The
information, put together, firmly point to Christian Huitema, two pieces of information, put together, firmly point to Christian
employed by Microsoft. The identification is successful. Huitema, 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
by maybe a factor of a thousand. Other information such as the significantly. Other information such as the visited sites will
visited sites will quickly complement that data and lead to user quickly complement that data and can lead to user identification.
identification.
Of course, unique names assigned by manufacturers are even more Also the special circumstances of the network can play a role.
interesting for such adversaries capable of maintaining a database Experiments on operational networks such as the IETF meeting network
recording the hostnames of devices used by specific user. With a have shown that with the help of external data such as the publicly
unique name like "BrandX-123456-7890-abcdef" identification can be available IETF attendees list or other data sources such as LDAP
pretty much immediate. servers on the network can [TRAC2016], the identification of the
device owner can become trivial given only partial identifiers in a
hostname.
4. Protocols that leak hostnames Unique names assigned by manufacturers do not directly encode a user
identifier, but they have the property of being stable and unique to
the device in a large context. A unique name like "BrandX-
123456-7890-abcdef" allows efficient tracking across multiple
domains. In theory, this only allows tracking of the device but not
of the user. However, an adversary could correlate the device to the
user through other means, for example the one-time capture of some
clear text traffic. Adversaries could then maintain databases
linking unique host name to user identity. This will allow efficient
tracking of both the user and the device.
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
multicast addresses and can be easily monitored, enabling adversaries the broadcast address and can be easily monitored, enabling
to discover the hostname associated with a computer visiting a adversaries to discover the hostname associated with a computer
particular network. DHCPv6 [RFC3315] shares similar issues. visiting a particular network. DHCPv6 [RFC3315] shares similar
issues.
The problems with the hostnames and FQDN parameters in DHCP are The problems with the hostname and FQDN parameters in DHCP are
analyzed in [I-D.ietf-dhc-dhcp-privacy] and analyzed in [I-D.ietf-dhc-dhcp-privacy] and
[I-D.ietf-dhc-dhcpv6-privacy]. Possible mitigations are described in [I-D.ietf-dhc-dhcpv6-privacy]. Possible mitigations are described in
[I-D.ietf-dhc-anonymity-profile]. [I-D.ietf-dhc-anonymity-profile].
4.2. DNS address to name resolution 4.2. DNS Address to Name Resolution
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 fully
qualified domain name of that computer. The retrieval may not be qualified domain name of that computer. The retrieval may not be
useful in many IPv4 networks due to the prevalence of NAT, but it useful in many IPv4 networks due to the prevalence of NAT, but it
could work in IPv6 networks. could work in IPv6 networks.
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 a multicast port, and to elicit responses from send DNS queries over multicast, and to elicit responses from hosts
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 also 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.
4.4. Link-local Multicast Name Resolution 4.4. Link-local Multicast Name Resolution
The Link-local Multicast Name Resolution (LLMNR) is defined in Link-local Multicast Name Resolution (LLMNR) is defined in [RFC4795].
[RFC4795]. The specification did not achieve consensus as an IETF The specification did not achieve consensus as an IETF standard, but
standard, but is widely deployed. Like MDNS, it enables hosts to it is widely deployed. Like mDNS, it enables hosts to send DNS
send DNS queries over a multicast port, and to elicit responses from queries over multicast, and to elicit responses from computers
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
on a network of a specific host, by issuing a multicast requests to of a specific host on a network, by issuing a multicast requests 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 to When an LLMNR responder starts, it sends a set of multicast queries
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 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 host 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 server-less 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," typically chosen by the user responsible for the publication.
While this is obviously an active disclosure of information, privacy While this is obviously an active disclosure of information, privacy
aspects can be mitigated by user control. Services should only be aspects can be mitigated by user control. Services should only be
published when deciding to do so, and the information disclosed in published when deciding to do so, and the information disclosed in
the service name should be well under the control of the device's the service name should be well under the control of the device's
owner. 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
skipping to change at page 6, line 24 skipping to change at page 7, line 5
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 records describing the service location. SRV records describing the service location.
SRV records are described in [RFC2782]. Each record contains 4 SRV records are described in [RFC2782]. Each record contains 4
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 host name of computers advertising any service with DNS- retrieve the hostname of computers advertising any service with DNS-
SD. SD.
5. Randomized Host Names as Remedy 5. Randomized Hostames as 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 fix the corresponding protocols. Or, we could attempt to somehow fix the corresponding protocols. Or, we could attempt to
revise the way our devices manage the hostname parameter. revise the 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. the value of this option. Also, the services that rely on protocols
that leak hostnames such as mDNS will not be available when switched
off. Also, not always are hostname-leaking protocols well-known as
they might be proprietary and come with an installed 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 [I-D.ietf-dhc-anonymity-profile]. However, it is unclear DHCP in [I-D.ietf-dhc-anonymity-profile]. However, it is unclear
that we can identify, revisit an fix all the protocols that publish that we can identify, revisit and fix all the protocols that publish
hostnames. hostnames. In 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. This is in a way
similar to the approach of MAC address randomization described in similar to the approach of MAC address randomization described in
[I-D.ietf-dhc-anonymity-profile]. Let's assume that the operating [I-D.ietf-dhc-anonymity-profile]. Let's assume that the operating
system, at the time of connecting to a new network, picks a random system, at the time of connecting to a new network, picks a random
hostname and start publicizing that random name in protocols such as hostname and start publicizing that random name in protocols such as
DHCP or MDNS, instead of the static value. This will frustrate DHCP or mDNS, instead of the static value. This will render
monitoring by adversaries, without preventing protocols such as DNS monitoring and identification of users by adversaries much more
SD from operating as expected. difficult, without preventing protocols such as DNS-SD from operating
as expected. This has of course implications on the applications
making use of such protocols e.g. when the hostname is being
displayed to users of the application. They will not as easily be
able to identify e.g. network shares or services based on the
hostname carried in the underlying protocols. Also, the generation
of new hostnames should be synchronized with the change of other
tokens used in network protocols such as the MAC or IP address to
prevent correlation of this information.
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 multi-homed, as the same name will be used on several
networks. Obviously, further studies are required before the idea of networks. Other operating systems already use potentially different
randomized hostnames can be implemented. hostnames for different purposes, which might be a good model to
combine both static hostnames and randomized hostnames based on their
potential use and thread to a users privacy. Obviously, further
studies are required before the idea of randomized hostnames can be
implemented.
6. Security Considerations 6. Security Considerations
This draft does not introduce any new protocol. It does point to This draft 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.
7. IANA Considerations 7. IANA Considerations
This draft does not require any IANA action. This draft does not require any IANA action.
8. Acknowledgments 8. Acknowledgments
Contributions will be gladly acknowledged. We would like to thank Rolf Winter for his many contributions to this
document.
9. Informative References 9. Informative References
[I-D.ietf-dhc-anonymity-profile] [I-D.ietf-dhc-anonymity-profile]
Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
profile for DHCP clients", draft-ietf-dhc-anonymity- profile for DHCP clients", draft-ietf-dhc-anonymity-
profile-04 (work in progress), October 2015. profile-08 (work in progress), February 2016.
[I-D.ietf-dhc-dhcp-privacy] [I-D.ietf-dhc-dhcp-privacy]
Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
considerations for DHCPv4", draft-ietf-dhc-dhcp-privacy-01 considerations for DHCP", draft-ietf-dhc-dhcp-privacy-05
(work in progress), August 2015. (work in progress), February 2016.
[I-D.ietf-dhc-dhcpv6-privacy] [I-D.ietf-dhc-dhcpv6-privacy]
Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
considerations for DHCPv6", draft-ietf-dhc- considerations for DHCPv6", draft-ietf-dhc-
dhcpv6-privacy-01 (work in progress), August 2015. dhcpv6-privacy-05 (work in progress), February 2016.
[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,
<http://www.rfc-editor.org/info/rfc1033>. <http://www.rfc-editor.org/info/rfc1033>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
skipping to change at page 9, line 5 skipping to change at page 10, line 5
<http://www.rfc-editor.org/info/rfc6762>. <http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>. <http://www.rfc-editor.org/info/rfc6763>.
[RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288,
DOI 10.17487/RFC7288, June 2014, DOI 10.17487/RFC7288, June 2014,
<http://www.rfc-editor.org/info/rfc7288>. <http://www.rfc-editor.org/info/rfc7288>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>.
[TRAC2016]
Faath, M., Weisshaar, F., and R. Winter, "How Broadcast
Data Reveals Your Identity and Social Graph", 7th
International Workshop on TRaffic Analysis and
Characterization IEEE TRAC 2016, September 2016.
Authors' Addresses Authors' Addresses
Christian Huitema Christian Huitema
Microsoft Microsoft
Redmond, WA 98052 Redmond, WA 98052
U.S.A. U.S.A.
Email: huitema@microsoft.com Email: huitema@microsoft.com
Dave Thaler Dave Thaler
 End of changes. 46 change blocks. 
95 lines changed or deleted 145 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/