draft-ietf-intarea-hostname-practice-03.txt   draft-ietf-intarea-hostname-practice-04.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft D. Thaler Internet-Draft Private Octopus Inc.
Intended status: Informational Microsoft Intended status: Informational D. Thaler
Expires: January 9, 2017 R. Winter Expires: July 27, 2017 Microsoft
R. Winter
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
July 8, 2016 January 23, 2017
Current Hostname Practice Considered Harmful Current Hostname Practice Considered Harmful
draft-ietf-intarea-hostname-practice-03.txt draft-ietf-intarea-hostname-practice-04.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 threats.
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
describes some of the protocols that reveal hostnames today and describes some of the protocols that reveal hostnames today and
sketches another possible remedy, which is to replace static sketches another possible remedy, which is to replace static
hostnames by frequently changing randomized values. 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
skipping to change at page 1, line 42 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 January 9, 2017. This Internet-Draft will expire on July 27, 2017.
Copyright Notice 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. 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
skipping to change at page 3, line 42 skipping to change at page 3, line 42
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 used 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" and often contain the name of the device owner 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'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 "huitema-laptop" and that the laptop has
skipping to change at page 5, line 16 skipping to change at page 5, line 16
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
the broadcast address and can be easily monitored, enabling the broadcast address and can be easily monitored, enabling
adversaries to discover the hostname associated with a computer adversaries to discover the hostname associated with a computer
visiting a particular network. DHCPv6 [RFC3315] shares similar visiting a particular network. DHCPv6 [RFC3315] shares similar
issues. issues.
The problems with the hostname 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 [RFC7819] and [RFC7824]. Possible mitigations are
[I-D.ietf-dhc-dhcpv6-privacy]. Possible mitigations are described in described in [RFC7844].
[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.
skipping to change at page 7, line 50 skipping to change at page 7, line 50
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. Also, the services that rely on protocols the value of this option. Also, the services that rely on protocols
that leak hostnames such as mDNS will not be available when switched that leak hostnames such as mDNS will not be available when switched
off. In addition, not always are hostname-leaking protocols well- off. In addition, not always are hostname-leaking protocols well-
known as they might be proprietary and come with an installed known as they might be proprietary and come with an installed
application instead of being provided by the operating system. 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 [RFC7844]. However, it is unclear that we can identify,
that we can identify, revisit and fix all the protocols that publish revisit and fix all the protocols that publish hostnames. In
hostnames. In particular, this is impossible for proprietary 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 [RFC7844]. Let's assume that the operating system, at the time of
system, at the time of connecting to a new network, picks a random connecting to a new network, picks a random hostname and starts
hostname and starts publicizing that random name in protocols such as publicizing that random name in protocols such as DHCP or mDNS,
DHCP or mDNS, instead of the static value. This will render instead of the static value. This will render monitoring and
monitoring and identification of users by adversaries much more identification of users by adversaries much more difficult, without
difficult, without preventing protocols such as DNS-SD from operating preventing protocols such as DNS-SD from operating as expected. This
as expected. This has of course implications on the applications has of course implications on the applications making use of such
making use of such protocols e.g. when the hostname is being protocols e.g. when the hostname is being displayed to users of the
displayed to users of the application. They will not as easily be application. They will not as easily be able to identify e.g.
able to identify e.g. network shares or services based on the network shares or services based on the hostname carried in the
hostname carried in the underlying protocols. Also, the generation underlying protocols. Also, the generation of new hostnames should
of new hostnames should be synchronized with the change of other be synchronized with the change of other tokens used in network
tokens used in network protocols such as the MAC or IP address to protocols such as the MAC or IP address to prevent correlation of
prevent correlation of this information. E.g. if the IP address this information. E.g. if the IP address changes but the hostname
changes but the hostname stays the same, the new IP address can be stays the same, the new IP address can be correlated to belong to the
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. Obviously, further
studies are required before the idea of randomized hostnames can be studies are required before the idea of randomized hostnames can be
skipping to change at page 9, line 7 skipping to change at page 9, line 7
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
[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 [RFC1002] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, and End-to-End Projects Agency, Internet Activities Board, and End-to-End
Services Task Force, "Protocol standard for a NetBIOS Services Task Force, "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Detailed specifications", service on a TCP/UDP transport: Detailed specifications",
STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987,
<http://www.rfc-editor.org/info/rfc1002>. <http://www.rfc-editor.org/info/rfc1002>.
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC [RFC1033] Lottor, M., "Domain Administrators Operations Guide",
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", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
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,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>. <http://www.rfc-editor.org/info/rfc2782>.
[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,
10.17487/RFC3596, October 2003, DOI 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 [RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information
Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006, Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006,
<http://www.rfc-editor.org/info/rfc4620>. <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,
10.17487/RFC4795, January 2007, DOI 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
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, DOI [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288,
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 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>. 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy
Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819,
April 2016, <http://www.rfc-editor.org/info/rfc7819>.
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
Considerations for DHCPv6", RFC 7824,
DOI 10.17487/RFC7824, May 2016,
<http://www.rfc-editor.org/info/rfc7824>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016,
<http://www.rfc-editor.org/info/rfc7844>.
[TRAC2016] [TRAC2016]
Faath, M., Weisshaar, F., and R. Winter, "How Broadcast Faath, M., Weisshaar, F., and R. Winter, "How Broadcast
Data Reveals Your Identity and Social Graph", 7th Data Reveals Your Identity and Social Graph", 7th
International Workshop on TRaffic Analysis and International Workshop on TRaffic Analysis and
Characterization IEEE TRAC 2016, September 2016. Characterization IEEE TRAC 2016, September 2016.
Authors' Addresses Authors' Addresses
Christian Huitema Christian Huitema
Microsoft Private Octopus Inc.
Redmond, WA 98052 Friday Harbor, WA 98250
U.S.A. U.S.A.
Email: huitema@microsoft.com Email: huitema@huitema.net
Dave Thaler Dave Thaler
Microsoft Microsoft
Redmond, WA 98052 Redmond, WA 98052
U.S.A. U.S.A.
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
Rolf Winter Rolf Winter
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
Augsburg Augsburg
 End of changes. 21 change blocks. 
63 lines changed or deleted 61 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/