--- 1/draft-ietf-intarea-hostname-practice-03.txt 2017-01-23 19:13:08.267986742 -0800 +++ 2/draft-ietf-intarea-hostname-practice-04.txt 2017-01-23 19:13:08.295987397 -0800 @@ -1,28 +1,29 @@ Network Working Group C. Huitema -Internet-Draft D. Thaler -Intended status: Informational Microsoft -Expires: January 9, 2017 R. Winter +Internet-Draft Private Octopus Inc. +Intended status: Informational D. Thaler +Expires: July 27, 2017 Microsoft + R. Winter University of Applied Sciences Augsburg - July 8, 2016 + January 23, 2017 Current Hostname Practice Considered Harmful - draft-ietf-intarea-hostname-practice-03.txt + draft-ietf-intarea-hostname-practice-04.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 threads. + order to mitigate these privacy threats. There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -31,25 +32,25 @@ 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 January 9, 2017. + This Internet-Draft will expire on July 27, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -124,29 +125,29 @@ In large organizations, collisions are more likely and a more structured approach is necessary. In theory, organizations could use multiple DNS subdomains to ease the pressure on uniqueness, but in practice many don't and insist on unique flat names, if only to simplify network management. To ensure unique names, organizations will set naming guidelines and enforce some kind of structured naming. For example, within the Microsoft corporate network, 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 - authors uses to test software. + authors used to test software. There is less pressure to assign names to small devices, including for example smart phones, as these devices typically do not enable sharing of their disks or remote login. As a consequence, these devices often have manufacturer assigned names, which vary from very generic like "Windows Phone" to completely unique like "BrandX- - 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 + 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 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 @@ -194,23 +195,22 @@ Shortly after connecting to a new network, a host can use DHCP [RFC2131] to acquire an IPv4 address and other parameters [RFC2132]. A DHCP query can disclose the "hostname." DHCP traffic is sent to the broadcast address and can be easily monitored, enabling adversaries to discover the hostname associated with a computer visiting a particular network. DHCPv6 [RFC3315] shares similar issues. The problems with the hostname and FQDN parameters in DHCP are - analyzed in [I-D.ietf-dhc-dhcp-privacy] and - [I-D.ietf-dhc-dhcpv6-privacy]. Possible mitigations are described in - [I-D.ietf-dhc-anonymity-profile]. + analyzed in [RFC7819] and [RFC7824]. Possible mitigations are + described in [RFC7844]. 4.2. DNS Address to Name Resolution The domain name service design [RFC1035] includes the specification of the special domain "in-addr.arpa" for resolving the name of the computer using a particular IPv4 address, using the PTR format defined in [RFC1033]. A similar domain, "ip6.arpa", is defined in [RFC3596] for finding the name of a computer using a specific IPv6 address. @@ -325,44 +325,43 @@ may not always provide good results. Second, some protocols such as DHCP cannot be turned off without losing connectivity, which limits 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. In addition, 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 from leaking hostnames. This is for example what is attempted for - DHCP in [I-D.ietf-dhc-anonymity-profile]. However, it is unclear - that we can identify, revisit and fix all the protocols that publish - hostnames. In particular, this is impossible for proprietary - protocols. + DHCP in [RFC7844]. However, it is unclear that we can identify, + revisit and fix all the protocols that publish hostnames. In + particular, this is impossible for proprietary protocols. 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 similar to the approach of MAC address randomization described in - [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 - hostname and starts publicizing that random name in protocols such as - DHCP or mDNS, instead of the static value. This will render - monitoring and identification of users by adversaries much more - 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. E.g. if the IP address - 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. + [RFC7844]. Let's assume that the operating system, at the time of + connecting to a new network, picks a random hostname and starts + publicizing that random name in protocols such as DHCP or mDNS, + instead of the static value. This will render monitoring and + identification of users by adversaries much more 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. E.g. if the IP address 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. 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 @@ -377,112 +376,111 @@ 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 - [I-D.ietf-dhc-anonymity-profile] - Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity - profile for DHCP clients", draft-ietf-dhc-anonymity- - profile-08 (work in progress), February 2016. - - [I-D.ietf-dhc-dhcp-privacy] - Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy - considerations for DHCP", draft-ietf-dhc-dhcp-privacy-05 - (work in progress), February 2016. - - [I-D.ietf-dhc-dhcpv6-privacy] - Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy - considerations for DHCPv6", draft-ietf-dhc- - 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, . - [RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC - 1033, DOI 10.17487/RFC1033, November 1987, + [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, . - [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC - 2131, DOI 10.17487/RFC2131, March 1997, + [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, DOI 10.17487/RFC2782, February 2000, . [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, - "DNS Extensions to Support IP Version 6", RFC 3596, DOI - 10.17487/RFC3596, October 2003, + "DNS Extensions to Support IP Version 6", RFC 3596, + DOI 10.17487/RFC3596, October 2003, . [RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006, . [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local - Multicast Name Resolution (LLMNR)", RFC 4795, DOI - 10.17487/RFC4795, January 2007, + Multicast Name Resolution (LLMNR)", RFC 4795, + DOI 10.17487/RFC4795, January 2007, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . - [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, DOI - 10.17487/RFC7288, June 2014, + [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, + DOI 10.17487/RFC7288, June 2014, . [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, . + [RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy + Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, + April 2016, . + + [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy + Considerations for DHCPv6", RFC 7824, + DOI 10.17487/RFC7824, May 2016, + . + + [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity + Profiles for DHCP Clients", RFC 7844, + DOI 10.17487/RFC7844, May 2016, + . + [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 + Christian Huitema - Microsoft - Redmond, WA 98052 + Private Octopus Inc. + Friday Harbor, WA 98250 U.S.A. - Email: huitema@microsoft.com - + Email: huitema@huitema.net Dave Thaler Microsoft Redmond, WA 98052 U.S.A. Email: dthaler@microsoft.com Rolf Winter University of Applied Sciences Augsburg Augsburg