< draft-ietf-doh-dns-over-https-00.txt		draft-ietf-doh-dns-over-https-01.txt >
	Network Working Group P. Hoffman		Network Working Group P. Hoffman
	Internet-Draft ICANN		Internet-Draft ICANN
	Intended status: Standards Track P. McManus		Intended status: Standards Track P. McManus
	Expires: April 21, 2018 Mozilla		Expires: May 3, 2018 Mozilla
	October 18, 2017		October 30, 2017
	DNS Queries over HTTPS		DNS Queries over HTTPS
	draft-ietf-doh-dns-over-https-00		draft-ietf-doh-dns-over-https-01
	Abstract		Abstract
	DNS queries sometimes experience problems with end to end		DNS queries sometimes experience problems with end to end
	connectivity at times and places where HTTPS flows freely.		connectivity at times and places where HTTPS flows freely.
	HTTPS provides the most practical mechanism for reliable end to end		HTTPS provides the most practical mechanism for reliable end to end
	communication. Its use of TLS provides integrity and confidentiality		communication. Its use of TLS provides integrity and confidentiality
	guarantees and its use of HTTP allows it to interoperate with		guarantees and its use of HTTP allows it to interoperate with
	proxies, firewalls, and authentication systems where required for		proxies, firewalls, and authentication systems where required for
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 April 21, 2018.		This Internet-Draft will expire on May 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 4		4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 4
	4.1. Non-requirements . . . . . . . . . . . . . . . . . . . . 4		4.1. Non-requirements . . . . . . . . . . . . . . . . . . . . 4
	5. The HTTP Request . . . . . . . . . . . . . . . . . . . . . . 4		5. The HTTP Request . . . . . . . . . . . . . . . . . . . . . . 4
	5.1. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . 5		5.1. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . 5
	5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6		5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. The HTTP Response . . . . . . . . . . . . . . . . . . . . . . 6		6. The HTTP Response . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7		6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 7		7. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 8
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Registration of Well-Known URI . . . . . . . . . . . . . 8		8.1. Registration of Well-Known URI . . . . . . . . . . . . . 8
	8.2. Registration of application/dns-udpwireformat Media Type 8		8.2. Registration of application/dns-udpwireformat Media Type 8
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 10		9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	11.1. Normative References . . . . . . . . . . . . . . . . . . 10		11.1. Normative References . . . . . . . . . . . . . . . . . . 11
	11.2. Informative References . . . . . . . . . . . . . . . . . 11		11.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Previous Work on DNS over HTTP or in Other Formats . 12		Appendix A. Previous Work on DNS over HTTP or in Other Formats . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The Internet does not always provide end to end reachability for		The Internet does not always provide end to end reachability for
	native DNS. On-path network devices may spoof DNS responses, block		native DNS. On-path network devices may spoof DNS responses, block
	DNS requests, or just redirect DNS queries to different DNS servers		DNS requests, or just redirect DNS queries to different DNS servers
	that give less-than-honest answers.		that give less-than-honest answers.
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 40 ¶
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119		and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
	[RFC2119].		[RFC2119].
	3. Use Cases		3. Use Cases
	There are two primary use cases for this protocol.		There are two primary use cases for this protocol.
	The primary one is to prevent on-path network devices from		The primary use case is to prevent on-path network devices from
	interfering with native DNS operations. This interference includes,		interfering with native DNS operations. This interference includes,
	but is not limited to, spoofing DNS responses, blocking DNS requests,		but is not limited to, spoofing DNS responses, blocking DNS requests,
	and tracking. HTTP authentication and proxy friendliness are		and tracking. HTTP authentication and proxy friendliness are
	expected to make this protocol function in some environments where		expected to make this protocol function in some environments where
	DNS directly on TLS ([RFC7858]) would not.		unsecured DNS ([DNS]) or DNS directly on TLS ([RFC7858]) would not.
	A secondary use case is web applications that want to access DNS		A secondary use case is web applications that want to access DNS
	information. Standardizing an HTTPS mechanism allows this to be done		information. Standardizing an HTTPS mechanism allows this to be done
	in a way consistent with the cross-origin resource sharing [CORS]		in a way consistent with the cross-origin resource sharing security
	security model of the web and also integrate the caching mechanisms		model of the web [CORS] and also integrate the caching mechanisms of
	of DNS with those of HTTP. These applications may be interested in		DNS with those of HTTP. These applications may be interested in
	using a different media type than traditional clients.		using a different media type than traditional clients.
	[ This paragraph is to be removed when this document is published as		[[ This paragraph is to be removed when this document is published as
	an RFC ] Note that these use cases are different than those in a		an RFC ]] Note that these use cases are different than those in a
	similar protocol described at [I-D.ietf-dnsop-dns-wireformat-http].		similar protocol described at [I-D.ietf-dnsop-dns-wireformat-http].
	The use case for that protocol is proxying DNS queries over HTTP		The use case for that protocol is proxying DNS queries over HTTP
	instead of over DNS itself. The use cases in this document all		instead of over DNS itself. The use cases in this document all
	involve query origination instead of proxying.		involve query origination instead of proxying.
	4. Protocol Requirements		4. Protocol Requirements
	The protocol described here bases its design on the following		The protocol described here bases its design on the following
	protocol requirements:		protocol requirements:
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 33 ¶
	o The protocol must allow implementations to use HTTP's content		o The protocol must allow implementations to use HTTP's content
	negotiation mechanism.		negotiation mechanism.
	o The protocol must ensure interoperable media formats through a		o The protocol must ensure interoperable media formats through a
	mandatory to implement format wherein a query must be able to		mandatory to implement format wherein a query must be able to
	contain one or more EDNS extensions, including those not yet		contain one or more EDNS extensions, including those not yet
	defined.		defined.
	o The protocol must use a secure transport that meets the		o The protocol must use a secure transport that meets the
	requirements for modern https://.		requirements for modern HTTPS.
	4.1. Non-requirements		4.1. Non-requirements
	o Supporting network-specific DNS64 [RFC6147]		o Supporting network-specific DNS64 [RFC6147]
	o Supporting other network-specific inferences from plaintext DNS		o Supporting other network-specific inferences from plaintext DNS
	queries		queries
	o Supporting insecure HTTP		o Supporting insecure HTTP
	o Supporting legacy HTTP versions		o Supporting legacy HTTP versions
	5. The HTTP Request		5. The HTTP Request
			To make a DNS API query, a DNS API client sends an HTTP request to
			the URI of the DNS API.
	The URI scheme MUST be https.		The URI scheme MUST be https.
	The path SHOULD be "/.well-known/dns-query" but a different path can		A client can be configured with a DNS API URI, or it can discover the
	be used if the DNS API Client has prior knowledge about a DNS API		URI. This document defines a well-known URI path of "/.well-known/
	service on a different path at the origin being used. (See Section 8		dns-query" so that a discovery process that produces a domain name or
	for the registration of this in the well-known URI registry.) Using		domain name and port can be used to construct the DNS API URI. (See
	the well-known path allows automated discovery of a DNS API Service,		Section 8 for the registration of this in the well-known URI
	and also helps contextualize DNS Query requests pushed over an active		registry.) DNS API servers SHOULD use this well-known path to help
	HTTP/2 connection.		contextualize DNS Query requests that use server push [RFC7540].
	A DNS API Client encodes the DNS query into the HTTP request using		A DNS API Client encodes the DNS query into the HTTP request using
	either the HTTP GET or POST methods.		either the HTTP GET or POST methods.
	When using the POST method, the DNS query is included as the message		When using the POST method, the DNS query is included as the message
	body of the HTTP request and the Content-Type request header		body of the HTTP request and the Content-Type request header
	indicates the media type of the message. POST-ed requests are		indicates the media type of the message. POST-ed requests are
	smaller than their GET equivalents.		smaller than their GET equivalents.
	When using the GET method, the URI path MUST contain a query		When using the GET method, the URI path MUST contain a query
	parameter of the form content-type=TTT and another of the form		parameter of the form content-type=TTT and another of the form
	body=BBBB, where "TTT" is the media type of the format used for the		body=BBBB, where "TTT" is the media type of the format used for the
	body parameter, and "BBB" is the content of the body encoded with		body parameter, and "BBB" is the content of the body encoded with
	base64url [RFC4648]. Using the GET method is friendlier to many HTTP		base64url [RFC4648]. Using the GET method is friendlier to many HTTP
	cache implementations.		cache implementations.
	The DNS API Client SHOULD include an HTTP "Accept:" request header to		The DNS API Client SHOULD include an HTTP "Accept:" request header to
	say what type of content can be understood in response. The client		say what type of content can be understood in response. The client
	MUST be prepared to process "application/dns-udpwireformat"		MUST be prepared to process "application/dns-udpwireformat"
	{{dnswire} responses but MAY process any other type it receives.		Section 5.1 responses but MAY process any other type it receives.
	In order to maximize cache friendliness, DNS API clients using media		In order to maximize cache friendliness, DNS API clients using media
	formats that include DNS ID, such as application/dns-udpwireformat,		formats that include DNS ID, such as application/dns-udpwireformat,
	should use a DNS ID of 0 in every DNS request. HTTP semantics		should use a DNS ID of 0 in every DNS request. HTTP semantics
	correlate the request and response, thus eliminating the need for the		correlate the request and response, thus eliminating the need for the
	ID in a media type such as application/dns-udpwireformat.		ID in a media type such as application/dns-udpwireformat.
	DNS API clients can use HTTP/2 padding and compression in the same		DNS API clients can use HTTP/2 padding and compression in the same
	way that other HTTP/2 clients use (or don't use) them.		way that other HTTP/2 clients use (or don't use) them.
	5.1. DNS Wire Format		5.1. DNS Wire Format
	The media type is "application/dns-udpwireformat". The body is the		The media type is "application/dns-udpwireformat". The body is the
	DNS on-the-wire format is defined in [RFC1035]. The body MUST be		DNS on-the-wire format is defined in [RFC1035].
	encoded with base64url [RFC4648]. Padding characters for base64url
	MUST NOT be included.		When using the GET method, the body MUST be encoded with base64url
			[RFC4648]. Padding characters for base64url MUST NOT be included.
			When using the POST method, the body is not encoded.
	DNS API clients using the DNS wire format MAY have one or more		DNS API clients using the DNS wire format MAY have one or more
	EDNS(0) extensions [RFC6891] in the request.		EDNS(0) extensions [RFC6891] in the request.
	5.2. Examples		5.2. Examples
	For example, assume a DNS API server is following this specification		For example, assume a DNS API server is following this specification
	on origin https://dnsserver.example.net/ and the well-known path.		on origin https://dnsserver.example.net/ and the well-known path.
	The DNS API client chooses to send its requests in appliation/dns-		The DNS API client chooses to send its requests in appliation/dns-
	udpwirefomat but indicates it can parse replies in that format or as		udpwirefomat but indicates it can parse replies in that format or as
	skipping to change at page 6, line 51 ¶		skipping to change at page 7, line 7 ¶
	6. The HTTP Response		6. The HTTP Response
	Different response media types will provide more or less information		Different response media types will provide more or less information
	from a DNS response. For example, one response type might include		from a DNS response. For example, one response type might include
	the information from the DNS header bytes while another might omit		the information from the DNS header bytes while another might omit
	it. The amount and type of information that a media type gives is		it. The amount and type of information that a media type gives is
	solely up to the format, and not defined in this protocol.		solely up to the format, and not defined in this protocol.
	At the time this is published, the response types are works in		At the time this is published, the response types are works in
	progress. The only known response type is "application/dns-		progress. The only known response type is "application/dns-
	udpwireformat", but it is likely that at least one JSON-based		udpwireformat", but it is possible that at least one JSON-based
	response format will be defined in the future.		response format will be defined in the future.
	The DNS response for "application/dns-udpwireformat" in Section 5.1		The DNS response for "application/dns-udpwireformat" in Section 5.1
	MAY have one or more EDNS(0) extensions, depending on the extension		MAY have one or more EDNS(0) extensions, depending on the extension
	definition of the extensions given in the DNS request.		definition of the extensions given in the DNS request.
	Native HTTP methods are used to correlate requests and responses.		Native HTTP methods are used to correlate requests and responses.
	Responses may be returned in a different temporal order than requests		Responses may be returned in a different temporal order than requests
	were made using the protocols native multi-streaming functionality.		were made using the protocols native multi-streaming functionality.
	skipping to change at page 7, line 48 ¶		skipping to change at page 8, line 7 ¶
	<64 bytes represented by the following hex encoding>		<64 bytes represented by the following hex encoding>
	abcd 8180 0001 0001 0000 0000 0377 7777		abcd 8180 0001 0001 0000 0000 0377 7777
	0765 7861 6d70 6c65 0363 6f6d 0000 0100		0765 7861 6d70 6c65 0363 6f6d 0000 0100
	0103 7777 7707 6578 616d 706c 6503 636f		0103 7777 7707 6578 616d 706c 6503 636f
	6d00 0001 0001 0000 0080 0004 5db8 d822		6d00 0001 0001 0000 0080 0004 5db8 d822
	7. HTTP Integration		7. HTTP Integration
	In order to satisfy the security requirements of DNS over HTTPS, this
	protocol MUST use HTTP/2 [RFC7540] or its successors. HTTP/2
	enforces a modern TLS profile necessary for achieving the security
	requirements of this protocol.
	This protocol MUST be used with https scheme URI [RFC7230].		This protocol MUST be used with https scheme URI [RFC7230].
	The messages in classic UDP based DNS [RFC1035] are inherently		This protocol MUST use HTTP/2 [RFC7540] or its successors in order to
	unordered and have low overhead. A competitive HTTP transport needs		satisfy the security requirements of DNS over HTTPS. Further, the
	to support reordering, priority, parallelism, and header compression.		messages in classic UDP based DNS [RFC1035] are inherently unordered
	For this additional reason, this protocol MUST use HTTP/2 [RFC7540]		and have low overhead. A competitive HTTP transport needs to support
	or its successors.		reordering, priority, parallelism, and header compression, all of
			which are supported by HTTP/2 [RFC7540] or its successors.
	8. IANA Considerations		8. IANA Considerations
	8.1. Registration of Well-Known URI		8.1. Registration of Well-Known URI
	This specification registers a Well-Known URI [RFC5785]:		This specification registers a Well-Known URI [RFC5785]:
	o URI Suffix: dns-query		o URI Suffix: dns-query
	o Change Controller: IETF		o Change Controller: IETF
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 7 ¶
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: n/a		Restrictions on usage: n/a
	Author: Paul Hoffman, paul.hoffman@icann.org		Author: Paul Hoffman, paul.hoffman@icann.org
	Change controller: IESG		Change controller: IESG
	9. Security Considerations		9. Security Considerations
	Running DNS over https:// relies on the security of the underlying		Running DNS over HTTPS relies on the security of the underlying HTTP
	HTTP connection. By requiring at least [RFC7540] levels of support		connection. By requiring at least [RFC7540] levels of support for
	for TLS this protocol expects to use current best practices for		TLS, this protocol expects to use current best practices for secure
	secure transport.		transport.
	Session level encryption has well known weaknesses with respect to		Session level encryption has well known weaknesses with respect to
	traffic analysis which might be particularly acute when dealing with		traffic analysis which might be particularly acute when dealing with
	DNS queries. Sections 10.6 (Compression) and 10.7 (Padding) of		DNS queries. Sections 10.6 (Compression) and 10.7 (Padding) of
	[RFC7540] provide some further advice on mitigations within an HTTP/2		[RFC7540] provide some further advice on mitigations within an HTTP/2
	context.		context.
			[[ From the WG charter:
			The working group will analyze the security and privacy issues that
			could arise from accessing DNS over HTTPS. In particular, the
			working group will consider the interaction of DNS and HTTP caching.
			]]
	A server that is acting both as a normal web server and a DNS API		A server that is acting both as a normal web server and a DNS API
	server is in a position to choose which DNS names it forces a client		server is in a position to choose which DNS names it forces a client
	to resolve (through its web service) and also be the one to answer		to resolve (through its web service) and also be the one to answer
	those queries (through its DNS API service). An untrusted DNS API		those queries (through its DNS API service). An untrusted DNS API
	server can thus easily cause damage by poisoning a client's cache		server can thus easily cause damage by poisoning a client's cache
	with names that the DNS API server chooses to poison. A client MUST		with names that the DNS API server chooses to poison. A client MUST
	NOT trust a DNS API server simply because it was discovered, or		NOT trust a DNS API server simply because it was discovered, or
	because the client was told to trust the DNS API server by an		because the client was told to trust the DNS API server by an
	untrusted party. Instead, a client MUST only trust DNS API server		untrusted party. Instead, a client MUST only trust DNS API server
	that is configured as trustworthy.		that is configured as trustworthy.
			[[ From the WG charter:
			The working group may define mechanisms for discovery of DOH servers
			similar to existing mechanisms for discovering other DNS servers if
			the chairs determine that there is both sufficient interest and
			working group consensus.
			]]
	10. Acknowledgments		10. Acknowledgments
	Joe Hildebrand contributed lots of material for a different iteration		Joe Hildebrand contributed lots of material for a different iteration
	of this document. Helpful early comments were given by Ben Schwartz		of this document. Helpful early comments were given by Ben Schwartz
	and Mark Nottingham.		and Mark Nottingham.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	skipping to change at page 11, line 35 ¶		skipping to change at page 12, line 5 ¶
	[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
	and P. Hoffman, "Specification for DNS over Transport		and P. Hoffman, "Specification for DNS over Transport
	Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May		Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
	2016, <https://www.rfc-editor.org/info/rfc7858>.		2016, <https://www.rfc-editor.org/info/rfc7858>.
	11.2. Informative References		11.2. Informative References
	[CORS] W3C, "Cross-Origin Resource Sharing", 2014,		[CORS] W3C, "Cross-Origin Resource Sharing", 2014,
	<https://www.w3.org/TR/cors/>.		<https://www.w3.org/TR/cors/>.
			[DNS] Mockapetris, P., "Domain names - implementation and
			specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
			November 1987, <https://www.rfc-editor.org/info/rfc1035>.
	[I-D.ietf-dnsop-dns-wireformat-http]		[I-D.ietf-dnsop-dns-wireformat-http]
	Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire-		Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire-
	format over HTTP", draft-ietf-dnsop-dns-wireformat-http-01		format over HTTP", draft-ietf-dnsop-dns-wireformat-http-01
	(work in progress), March 2017.		(work in progress), March 2017.
	[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van		[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
	Beijnum, "DNS64: DNS Extensions for Network Address		Beijnum, "DNS64: DNS Extensions for Network Address
	Translation from IPv6 Clients to IPv4 Servers", RFC 6147,		Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
	DOI 10.17487/RFC6147, April 2011, <https://www.rfc-		DOI 10.17487/RFC6147, April 2011, <https://www.rfc-
	editor.org/info/rfc6147>.		editor.org/info/rfc6147>.
End of changes. 21 change blocks.
	41 lines changed or deleted		64 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/