draft-ietf-intarea-hostname-practice-02.txt		draft-ietf-intarea-hostname-practice-03.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: November 12, 2016 R. Winter		Expires: January 9, 2017 R. Winter
	University of Applied Sciences Augsburg		University of Applied Sciences Augsburg
	May 11, 2016		July 8, 2016
	Current Hostname Practice Considered Harmful		Current Hostname Practice Considered Harmful
	draft-ietf-intarea-hostname-practice-02.txt		draft-ietf-intarea-hostname-practice-03.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 42 ¶		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 November 12, 2016.		This Internet-Draft will expire on January 9, 2017.
	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 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Naming Practices . . . . . . . . . . . . . . . . . . . . . . 3		2. Naming Practices . . . . . . . . . . . . . . . . . . . . . . 3
	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
	5. Randomized Hostames as Remedy . . . . . . . . . . . . . . . . 7		4.6. NetBIOS-over-TCP . . . . . . . . . . . . . . . . . . . . 7
			5. Randomized Hostnames as Remedy . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	9. Informative References . . . . . . . . . . . . . . . . . . . 8		9. Informative References . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	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. However, it is common practice to use the hostname without
	further qualification in a variety of applications from file sharing		further qualification in a variety of applications from file sharing
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 31 ¶
	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.
	Also the special circumstances of the network can play a role.		Also the special circumstances of the network can play a role.
	Experiments on operational networks such as the IETF meeting network		Experiments on operational networks such as the IETF meeting network
	have shown that with the help of external data such as the publicly		have shown that with the help of external data such as the publicly
	available IETF attendees list or other data sources such as LDAP		available IETF attendees list or other data sources such as LDAP
	servers on the network can [TRAC2016], the identification of the		servers on the network [TRAC2016], the identification of the device
	device owner can become trivial given only partial identifiers in a		owner can become trivial given only partial identifiers in a
	hostname.		hostname.
	Unique names assigned by manufacturers do not directly encode a user		Unique names assigned by manufacturers do not directly encode a user
	identifier, but they have the property of being stable and unique to		identifier, but they have the property of being stable and unique to
	the device in a large context. A unique name like "BrandX-		the device in a large context. A unique name like "BrandX-
	123456-7890-abcdef" allows efficient tracking across multiple		123456-7890-abcdef" allows efficient tracking across multiple
	domains. In theory, this only allows tracking of the device but not		domains. In theory, this only allows tracking of the device but not
	of the user. However, an adversary could correlate the device to the		of the user. However, an adversary could correlate the device to the
	user through other means, for example the one-time capture of some		user through other means, for example the one-time capture of some
	clear text traffic. Adversaries could then maintain databases		clear text traffic. Adversaries could then maintain databases
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 34 ¶
	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.
	Adversaries who observe a particular address in use on a specific		Adversaries who observe a particular address in use on a specific
	network can try to retrieve the PTR record associated with that		network can try to retrieve the PTR record associated with that
	address, and thus the hostname of the computer, or even the fully		address, and thus the hostname of the computer, or even the fully
	qualified domain name of that computer. The retrieval may not be		qualified domain name of that computer. The retrieval may not be
	useful in many IPv4 networks due to the prevalence of NAT, but it		useful in many IPv4 networks due to the prevalence of NAT, but it
	could work in IPv6 networks.		could work in IPv6 networks. Other name lookup mechanisms, such as
			[RFC4620], share similar issues.
	4.3. Multicast DNS		4.3. Multicast DNS
	Multicast DNS (mDNS) is defined in [RFC6762]. It enables hosts to		Multicast DNS (mDNS) is defined in [RFC6762]. It enables hosts to
	send DNS queries over multicast, and to elicit responses from hosts		send DNS queries over multicast, and to elicit responses from hosts
	participating in the service.		participating in the service.
	If an adversary suspects that a particular host is present on a		If an adversary suspects that a particular host is present on a
	network, the adversary can send mDNS requests to find, for example,		network, the adversary can send mDNS requests to find, for example,
	the A or AAAA records associated with the hostname in the ".local"		the A or AAAA records associated with the hostname in the ".local"
	domain. A positive reply will confirm the presence of the host.		domain. A positive reply will confirm the presence of the host.
	When a new responder starts, it must send a set of multicast queries		When a new responder starts, it must send a set of multicast queries
	to verify that the name that it advertises is unique on the network,		to verify that the name that it advertises is unique on the network,
	and also to populate the caches of other mDNS hosts. Adversaries can		and also to populate the caches of other mDNS hosts. Adversaries can
	monitor this traffic and discover the hostname of computers as they		monitor this traffic and discover the hostname of computers as they
	join the monitored network.		join the monitored network.
			mDNS further allows to send queries via unicast to port 5353. An
			adversary might decide to use unicast instead of multicast in order
			to hide from e.g. intrusion detection systems.
	4.4. Link-local Multicast Name Resolution		4.4. Link-local Multicast Name Resolution
	Link-local Multicast Name Resolution (LLMNR) is defined in [RFC4795].		Link-local Multicast Name Resolution (LLMNR) is defined in [RFC4795].
	The specification did not achieve consensus as an IETF standard, but		The specification did not achieve consensus as an IETF standard, but
	it is widely deployed. Like mDNS, it enables hosts to send DNS		it is widely deployed. Like mDNS, it enables hosts to send DNS
	queries over multicast, and to elicit responses from computers		queries over multicast, and to elicit responses from computers
	implementing the LLMNR service.		implementing the LLMNR service.
	Like mDNS, LLMNR can be used by adversaries to confirm the presence		Like mDNS, LLMNR can be used by adversaries to confirm the presence
	of a specific host on a network, by issuing a multicast requests to		of a specific host on a network, by issuing a multicast request to
	find the A or AAAA records associated with the hostname in the		find the A or AAAA records associated with the hostname in the
	".local" domain.		".local" domain.
	When an LLMNR responder starts, it sends a set of multicast queries		When an LLMNR responder starts, it sends a set of multicast queries
	to verify that the name that it advertises is unique on the network.		to verify that the name that it advertises is unique on the network.
	Adversaries can monitor this traffic and discover the hostname of		Adversaries can monitor this traffic and discover the hostname of
	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
	skipping to change at page 7, line 9 ¶		skipping to change at page 7, line 11 ¶
	SRV records are described in [RFC2782]. Each record contains 4		SRV records are described in [RFC2782]. Each record contains 4
	parameters: priority, weight, port number and hostname. While the		parameters: priority, weight, port number and hostname. While the
	service name published in the PTR record is chosen by the user, the		service name published in the PTR record is chosen by the user, the
	"hostname" in the SRV record is indeed the hostname of the device.		"hostname" in the SRV record is indeed the hostname of the device.
	Adversaries can monitor the mDNS traffic associated with DNS-SD and		Adversaries can monitor the mDNS traffic associated with DNS-SD and
	retrieve the hostname of computers advertising any service with DNS-		retrieve the hostname of computers advertising any service with DNS-
	SD.		SD.
	5. Randomized Hostames as Remedy		4.6. NetBIOS-over-TCP
			Amongst other things, NetBIOS-over-TCP ([RFC1002]) implements a name
			registration and resolution mechanism called the NetBIOS Name
			Service. In practice, NetBIOS resource names are often based on
			hostnames.
			NetBIOS allows an application to register resource names and to
			resolve such names to IP addresses. In environments without an
			NetBIOS Name Server, the protocol makes extensive use of broadcasts
			from which resource names can be easily extracted. NetBIOS also
			allows querying for the names registered by a node directly (node
			status).
			5. Randomized Hostnames as Remedy
	There are several ways to remedy the hostname practices. We could		There are several ways to remedy the hostname practices. We could
	instruct people to just turn off any protocol that leaks hostnames,		instruct people to just turn off any protocol that leaks hostnames,
	at least when they visit some "insecure" place. We could also		at least when they visit some "insecure" place. We could also
	examine each particular standard that publishes hostnames, and		examine each particular standard that publishes hostnames, and
	somehow fix the corresponding protocols. Or, we could attempt to		somehow fix the corresponding protocols. Or, we could attempt to
	revise the way devices manage the hostname parameter.		revise the way devices manage the hostname parameter.
	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,
	skipping to change at page 7, line 44 ¶		skipping to change at page 8, line 12 ¶
	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
	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		[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		system, at the time of connecting to a new network, picks a random
	hostname and start publicizing that random name in protocols such as		hostname and starts publicizing that random name in protocols such as
	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
	skipping to change at page 8, line 17 ¶		skipping to change at page 8, line 34 ¶
	changes but the hostname stays the same, the new IP address can be		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.		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 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
	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
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 22 ¶
	[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.
			[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,
			<http://www.rfc-editor.org/info/rfc1002>.
	[RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC		[RFC1033] Lottor, M., "Domain Administrators Operations Guide", 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", RFC		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
	2131, DOI 10.17487/RFC2131, March 1997,		2131, DOI 10.17487/RFC2131, March 1997,
	skipping to change at page 9, line 36 ¶		skipping to change at page 10, line 15 ¶
	[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, 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>.
			[RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information
			Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006,
			<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, 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
End of changes. 15 change blocks.
	13 lines changed or deleted		44 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/