--- 1/draft-ietf-intarea-hostname-practice-04.txt 2017-02-03 17:13:09.526858345 -0800 +++ 2/draft-ietf-intarea-hostname-practice-05.txt 2017-02-03 17:13:09.554859010 -0800 @@ -1,21 +1,21 @@ Network Working Group C. Huitema Internet-Draft Private Octopus Inc. Intended status: Informational D. Thaler -Expires: July 27, 2017 Microsoft +Expires: August 7, 2017 Microsoft R. Winter University of Applied Sciences Augsburg - January 23, 2017 + February 3, 2017 Current Hostname Practice Considered Harmful - draft-ietf-intarea-hostname-practice-04.txt + draft-ietf-intarea-hostname-practice-05.txt Abstract Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats. There are several possible remedies, such as fixing a variety of @@ -32,21 +32,21 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -63,36 +63,36 @@ 3. Partial Identifiers . . . . . . . . . . . . . . . . . . . . . 4 4. Protocols that leak Hostnames . . . . . . . . . . . . . . . . 4 4.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. DNS Address to Name Resolution . . . . . . . . . . . . . 5 4.3. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Link-local Multicast Name Resolution . . . . . . . . . . 6 4.5. DNS-Based Service Discovery . . . . . . . . . . . . . . . 6 4.6. NetBIOS-over-TCP . . . . . . . . . . . . . . . . . . . . 7 5. Randomized Hostnames as Remedy . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 9 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction There is a long established practice of giving names to computers. In the Internet protocols, these names are referred to as "hostnames" [RFC7719] . Hostnames are normally used in conjunction with a domain name suffix to build the "Fully Qualified Domain Name" (FQDN) of a - host. However, it is common practice to use the hostname without - further qualification in a variety of applications from file sharing - to network management. Hostnames are typically published as part of - domain names, and can be obtained through a variety of name lookup - and discovery protocols. + host [RFC1983]. However, it is common practice to use the hostname + without further qualification in a variety of applications from file + sharing to network management. Hostnames are typically published as + part of domain names, and can be obtained through a variety of name + lookup and discovery protocols. Hostnames have to be unique within the domain in which they are created and used. They do not have to be globally unique identifiers, but they will always be at least partial identifiers, as discussed in Section 3. The disclosure of information through hostnames creates a problem for mobile devices. Adversaries that monitor a remote network such as a Wi-Fi hot spot can obtain the hostname through passive monitoring or active probing of a variety of Internet protocols, such as for @@ -143,24 +143,24 @@ the device's brand name, and often also a hint as to which language the device owner speaks [TRAC2016]. 3. Partial Identifiers Suppose an adversary wants to track the people connecting to a specific Wi-Fi hot spot, for example in a railroad station. Assume that the adversary is able to retrieve the hostname used by a specific laptop. That, in itself, might not be enough to identify 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 - two pieces of information, put together, firmly point to Christian - Huitema, employed by Microsoft. The identification is successful. + two pieces of information, put together, firmly point to Dave Thaler, + employed by Microsoft. The identification is successful. In the example, we saw a login name inside the hostname, and that certainly helped identification. But generic names like "jupiter" or "rosebud" also provide partial identification, especially if the adversary is capable of maintaining a database recording, among other information, the hostnames of devices used by specific users. Generic names are picked from vocabularies that include thousands of potential choices. Finding the name reduces the scope of the search significantly. Other information such as the visited sites will quickly complement that data and can lead to user identification. @@ -262,21 +262,21 @@ computers as they join the monitored network. 4.5. DNS-Based Service Discovery DNS-Based Service Discovery (DNS-SD) is described in [RFC6763]. It enables participating hosts to retrieve the location of services proposed by other hosts. It can be used with DNS servers, or in conjunction with mDNS in a server-less environment. 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 aspects can be mitigated by user control. Services should only be published when deciding to do so, and the information disclosed in the service name should be well under the control of the device's owner. In theory there should not be any privacy issue, but in practice the publication of a service also forces the publication of the hostname, due to a chain of dependencies. The service name is used to publish a PTR record announcing the service. The PTR record typically points @@ -356,29 +356,37 @@ stays the same, the new IP address can be correlated to belong to the same device based on a leaked hostname. Some operating systems, including Windows, support "per network" hostnames, but some other operating systems only support "global" hostnames. In that case, changing the hostname may be difficult if the host is multi-homed, as the same name will be used on several networks. Other operating systems already use potentially different hostnames for different purposes, which might be a good model to combine both static hostnames and randomized hostnames based on their - potential use and threat to a user's privacy. Obviously, further - studies are required before the idea of randomized hostnames can be - implemented. + potential use and threat to a user's privacy. + + Obviously, further studies are required before the idea of randomized + hostnames can be implemented. 6. Security Considerations This draft does not introduce any new protocol. It does point to 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 This draft does not require any IANA action. 8. Acknowledgments Thanks to the members of the INTAREA Working Group for discussions and reviews. 9. Informative References @@ -391,20 +399,24 @@ . [RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, DOI 10.17487/RFC1033, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . + [RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18, + RFC 1983, DOI 10.17487/RFC1983, August 1996, + . + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782,