draft-ietf-intarea-hostname-practice-01.txt   draft-ietf-intarea-hostname-practice-02.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: October 17, 2016 April 15, 2016 Expires: November 12, 2016 R. Winter
University of Applied Sciences Augsburg
May 11, 2016
Current Hostname Practice Considered Harmful Current Hostname Practice Considered Harmful
draft-ietf-intarea-hostname-practice-01.txt draft-ietf-intarea-hostname-practice-02.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 40 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 October 17, 2016. This Internet-Draft will expire on November 12, 2016.
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 7, line 28 skipping to change at page 7, line 28
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,
and is clearly beneficial -- this is an advantage of the stealth mode and is clearly beneficial -- this is an advantage of the stealth mode
defined in [RFC7288]. However, there are two issues with this defined in [RFC7288]. However, there are two issues with this
advice. First, it relies on recognizing which networks are secure or advice. First, it relies on recognizing which networks are secure or
insecure. This is hard to automate, but relying on end-user judgment insecure. This is hard to automate, but relying on end-user judgment
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. Also, not always are hostname-leaking protocols well-known as off. In addition, not always are hostname-leaking protocols well-
they might be proprietary and come with an installed application known as they might be proprietary and come with an installed
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 [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
skipping to change at page 8, line 6 skipping to change at page 8, line 6
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
prevent correlation of this information. 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" 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 users privacy. Obviously, further potential use and thread 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
This draft does not require any IANA action. This draft does not require any IANA action.
8. Acknowledgments 8. Acknowledgments
We would like to thank Rolf Winter for his many contributions to this Thanks to the members of the INTAREA Working Group for discussions
document. and reviews.
9. Informative References 9. Informative References
[I-D.ietf-dhc-anonymity-profile] [I-D.ietf-dhc-anonymity-profile]
Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
profile for DHCP clients", draft-ietf-dhc-anonymity- profile for DHCP clients", draft-ietf-dhc-anonymity-
profile-08 (work in progress), February 2016. profile-08 (work in progress), February 2016.
[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.
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", [RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC
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", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
RFC 2131, DOI 10.17487/RFC2131, March 1997, 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, "DNS Extensions to Support IP Version 6", RFC 3596, DOI
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>.
[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, Multicast Name Resolution (LLMNR)", RFC 4795, DOI
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
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, [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, DOI
DOI 10.17487/RFC7288, June 2014, 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>.
[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
skipping to change at line 451 skipping to change at page 10, line 30
U.S.A. U.S.A.
Email: huitema@microsoft.com Email: huitema@microsoft.com
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
University of Applied Sciences Augsburg
Augsburg
DE
Email: rolf.winter@hs-augsburg.de
 End of changes. 13 change blocks. 
20 lines changed or deleted 24 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/