draft-ietf-intarea-hostname-practice-02.txt   draft-ietf-intarea-hostname-practice-03.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: November 12, 2016 R. Winter Expires: January 9, 2017 R. Winter
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
May 11, 2016 July 8, 2016
Current Hostname Practice Considered Harmful Current Hostname Practice Considered Harmful
draft-ietf-intarea-hostname-practice-02.txt draft-ietf-intarea-hostname-practice-03.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 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 threads. 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
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 November 12, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . 6
5. Randomized Hostames as Remedy . . . . . . . . . . . . . . . . 7 4.6. NetBIOS-over-TCP . . . . . . . . . . . . . . . . . . . . 7
5. Randomized Hostnames as Remedy . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . 8 9. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 "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. 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
skipping to change at page 4, line 31 skipping to change at page 4, line 31
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 LDAP
servers on the network can [TRAC2016], the identification of the servers on the network [TRAC2016], the identification of the device
device owner can become trivial given only partial identifiers in a owner can become trivial given only partial identifiers in a
hostname. 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 clear text traffic. Adversaries could then maintain databases
skipping to change at page 5, line 34 skipping to change at page 5, line 34
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. Other name lookup mechanisms, such as
[RFC4620], share similar 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 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.
mDNS further allows to send queries via unicast to port 5353. An
adversary might decide to use unicast instead of multicast in order
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 requests 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
skipping to change at page 7, line 9 skipping to change at page 7, line 11
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 hostname of computers advertising any service with DNS- retrieve the hostname of computers advertising any service with DNS-
SD. SD.
5. Randomized Hostames as Remedy 4.6. NetBIOS-over-TCP
Amongst 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.
NetBIOS allows an application to register resource names and to
resolve such names to IP addresses. In environments without an
NetBIOS Name Server, the protocol makes extensive use of broadcasts
from which resource names can be easily extracted. NetBIOS also
allows querying for the names registered by a node directly (node
status).
5. Randomized Hostnames 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 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,
skipping to change at page 7, line 44 skipping to change at page 8, line 12
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 and fix all the protocols that publish that we can identify, revisit and fix all the protocols that publish
hostnames. In particular, this is impossible for proprietary hostnames. In particular, this is impossible for proprietary
protocols. 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 starts publicizing that random name in protocols such as
DHCP or mDNS, instead of the static value. This will render DHCP or mDNS, instead of the static value. This will render
monitoring and identification of users by adversaries much more monitoring and identification of users by adversaries much more
difficult, without preventing protocols such as DNS-SD from operating difficult, without preventing protocols such as DNS-SD from operating
as expected. This has of course implications on the applications as expected. This has of course implications on the applications
making use of such protocols e.g. when the hostname is being making use of such protocols e.g. when the hostname is being
displayed to users of the application. They will not as easily be displayed to users of the application. They will not as easily be
able to identify e.g. network shares or services based on the able to identify e.g. network shares or services based on the
hostname carried in the underlying protocols. Also, the generation hostname carried in the underlying protocols. Also, the generation
of new hostnames should be synchronized with the change of other of new hostnames should be synchronized with the change of other
tokens used in network protocols such as the MAC or IP address to tokens used in network protocols such as the MAC or IP address to
skipping to change at page 8, line 17 skipping to change at page 8, line 34
changes but the hostname stays the same, the new IP address can be 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. 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 multi-homed, 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 thread to a user's privacy. Obviously, further potential use and threat to a user's privacy. Obviously, further
studies are required before the idea of randomized hostnames can be studies are required before the idea of randomized hostnames can be
implemented. 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
skipping to change at page 9, line 5 skipping to change at page 9, line 22
[I-D.ietf-dhc-dhcp-privacy] [I-D.ietf-dhc-dhcp-privacy]
Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
considerations for DHCP", draft-ietf-dhc-dhcp-privacy-05 considerations for DHCP", draft-ietf-dhc-dhcp-privacy-05
(work in progress), February 2016. (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-05 (work in progress), February 2016. dhcpv6-privacy-05 (work in progress), February 2016.
[RFC1002] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, and End-to-End
Services Task Force, "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Detailed specifications",
STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987,
<http://www.rfc-editor.org/info/rfc1002>.
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC [RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC
1033, DOI 10.17487/RFC1033, November 1987, 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", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, DOI 10.17487/RFC2131, March 1997, 2131, DOI 10.17487/RFC2131, March 1997,
skipping to change at page 9, line 36 skipping to change at page 10, line 15
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, DOI "DNS Extensions to Support IP Version 6", RFC 3596, DOI
10.17487/RFC3596, October 2003, 10.17487/RFC3596, October 2003,
<http://www.rfc-editor.org/info/rfc3596>. <http://www.rfc-editor.org/info/rfc3596>.
[RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information
Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006,
<http://www.rfc-editor.org/info/rfc4620>.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795, DOI Multicast Name Resolution (LLMNR)", RFC 4795, DOI
10.17487/RFC4795, January 2007, 10.17487/RFC4795, January 2007,
<http://www.rfc-editor.org/info/rfc4795>. <http://www.rfc-editor.org/info/rfc4795>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<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
 End of changes. 15 change blocks. 
13 lines changed or deleted 44 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/