draft-ietf-intarea-hostname-practice-04.txt   draft-ietf-intarea-hostname-practice-05.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Private Octopus Inc. Internet-Draft Private Octopus Inc.
Intended status: Informational D. Thaler Intended status: Informational D. Thaler
Expires: July 27, 2017 Microsoft Expires: August 7, 2017 Microsoft
R. Winter R. Winter
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
January 23, 2017 February 3, 2017
Current Hostname Practice Considered Harmful Current Hostname Practice Considered Harmful
draft-ietf-intarea-hostname-practice-04.txt 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 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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 July 27, 2017. This Internet-Draft will expire on August 7, 2017.
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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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
4.6. NetBIOS-over-TCP . . . . . . . . . . . . . . . . . . . . 7 4.6. NetBIOS-over-TCP . . . . . . . . . . . . . . . . . . . . 7
5. Randomized Hostnames as Remedy . . . . . . . . . . . . . . . 7 5. Randomized Hostnames as Remedy . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 [RFC1983]. However, it is common practice to use the hostname
further qualification in a variety of applications from file sharing without further qualification in a variety of applications from file
to network management. Hostnames are typically published as part of sharing to network management. Hostnames are typically published as
domain names, and can be obtained through a variety of name lookup part of domain names, and can be obtained through a variety of name
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 for
skipping to change at page 4, line 12 skipping to change at page 4, line 12
the device's brand name, and often also a hint as to which language the device's brand name, and often also a hint as to which language
the device owner speaks [TRAC2016]. 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 that
the laptop name is "huitema-laptop" and that the laptop has 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 Christian two pieces of information, put together, firmly point to Dave Thaler,
Huitema, 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.
skipping to change at page 6, line 35 skipping to change at page 6, line 35
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 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 8, line 34 skipping to change at page 8, line 34
stays the same, the new IP address can be correlated to belong to the stays the same, the new IP address can be correlated to belong to the
same device based on a leaked hostname. 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 threat to a user's privacy. Obviously, further potential use and threat to a user's privacy.
studies are required before the idea of randomized hostnames can be
implemented. 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.
There are obvious privacy gains to changing to randomized hostnames
and also to change these names frequently. Wide deployment might
however affect security functions or current practices. For example,
incident response using hostnames to track the source of traffic
might be affected. It is common practice to include 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 draft does not require any IANA action.
8. Acknowledgments 8. Acknowledgments
Thanks to the members of the INTAREA Working Group for discussions Thanks to the members of the INTAREA Working Group for discussions
and reviews. and reviews.
9. Informative References 9. Informative References
skipping to change at page 9, line 22 skipping to change at page 9, line 31
<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,
<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>.
[RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18,
RFC 1983, DOI 10.17487/RFC1983, August 1996,
<http://www.rfc-editor.org/info/rfc1983>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>. <http://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<http://www.rfc-editor.org/info/rfc2132>. <http://www.rfc-editor.org/info/rfc2132>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
 End of changes. 13 change blocks. 
19 lines changed or deleted 31 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/