< draft-ietf-dprive-dnsoquic-08.txt		draft-ietf-dprive-dnsoquic-09.txt >
	Network Working Group C. Huitema		Network Working Group C. Huitema
	Internet-Draft Private Octopus Inc.		Internet-Draft Private Octopus Inc.
	Intended status: Standards Track S. Dickinson		Intended status: Standards Track S. Dickinson
	Expires: 14 July 2022 Sinodun IT		Expires: 12 August 2022 Sinodun IT
	A. Mankin		A. Mankin
	Salesforce		Salesforce
	10 January 2022		8 February 2022
	DNS over Dedicated QUIC Connections		DNS over Dedicated QUIC Connections
	draft-ietf-dprive-dnsoquic-08		draft-ietf-dprive-dnsoquic-09
	Abstract		Abstract
	This document describes the use of QUIC to provide transport privacy		This document describes the use of QUIC to provide transport privacy
	for DNS. The encryption provided by QUIC has similar properties to		for DNS. The encryption provided by QUIC has similar properties to
	that provided by TLS, while QUIC transport eliminates the head-of-		that provided by TLS, while QUIC transport eliminates the head-of-
	line blocking issues inherent with TCP and provides more efficient		line blocking issues inherent with TCP and provides more efficient
	packet loss recovery than UDP. DNS over QUIC (DoQ) has privacy		packet loss recovery than UDP. DNS over QUIC (DoQ) has privacy
	properties similar to DNS over TLS (DoT) specified in RFC7858, and		properties similar to DNS over TLS (DoT) specified in RFC7858, and
	latency characteristics similar to classic DNS over UDP. This		latency characteristics similar to classic DNS over UDP. This
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 14 July 2022.		This Internet-Draft will expire on 12 August 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 16		6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 16
	6.5.4. Controlling Connection Migration For Privacy . . . . 17		6.5.4. Controlling Connection Migration For Privacy . . . . 17
	6.6. Processing Queries in Parallel . . . . . . . . . . . . . 17		6.6. Processing Queries in Parallel . . . . . . . . . . . . . 17
	6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 17		6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 17
	6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 18		6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 18
	7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18		7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
	7.1. Performance Measurements . . . . . . . . . . . . . . . . 19		7.1. Performance Measurements . . . . . . . . . . . . . . . . 19
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 20		8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20		9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
	9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 20		9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 21
	9.2. Privacy Issues With Session Resumption . . . . . . . . . 21		9.2. Privacy Issues With Session Resumption . . . . . . . . . 21
	9.3. Privacy Issues With Address Validation Tokens . . . . . . 22		9.3. Privacy Issues With Address Validation Tokens . . . . . . 22
	9.4. Privacy Issues With Long Duration Sessions . . . . . . . 22		9.4. Privacy Issues With Long Duration Sessions . . . . . . . 23
	9.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23		9.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	10.1. Registration of DoQ Identification String . . . . . . . 23		10.1. Registration of DoQ Identification String . . . . . . . 23
	10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 23		10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 24
	10.2.1. Port number 784 for experimentations . . . . . . . . 24		10.3. Reservation of Extended DNS Error Code Too Early . . . . 25
	10.3. Reservation of Extended DNS Error Code Too Early . . . . 24
	10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 25		10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 25
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
	12.1. Normative References . . . . . . . . . . . . . . . . . . 27		12.1. Normative References . . . . . . . . . . . . . . . . . . 28
	12.2. Informative References . . . . . . . . . . . . . . . . . 29		12.2. Informative References . . . . . . . . . . . . . . . . . 30
	Appendix A. The NOTIFY Service . . . . . . . . . . . . . . . . . 30		Appendix A. The NOTIFY Service . . . . . . . . . . . . . . . . . 31
	Appendix B. Notable Changes From Previous Versions . . . . . . . 31		Appendix B. Notable Changes From Previous Versions . . . . . . . 32
	B.1. Stream Mapping Incompatibility With Draft-02 . . . . . . 31		B.1. Stream Mapping Incompatibility With Draft-02 . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	Domain Name System (DNS) concepts are specified in "Domain names -		Domain Name System (DNS) concepts are specified in "Domain names -
	concepts and facilities" [RFC1034]. The transmission of DNS queries		concepts and facilities" [RFC1034]. The transmission of DNS queries
	and responses over UDP and TCP is specified in "Domain names -		and responses over UDP and TCP is specified in "Domain names -
	implementation and specification" [RFC1035].		implementation and specification" [RFC1035].
	This document presents a mapping of the DNS protocol over the QUIC		This document presents a mapping of the DNS protocol over the QUIC
	transport [RFC9000] [RFC9001]. DNS over QUIC is referred here as		transport [RFC9000] [RFC9001]. DNS over QUIC is referred here as
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 34 ¶
	in conformance with the QUIC transport specification [RFC9000].		in conformance with the QUIC transport specification [RFC9000].
	The client MUST send the DNS query over the selected stream, and MUST		The client MUST send the DNS query over the selected stream, and MUST
	indicate through the STREAM FIN mechanism that no further data will		indicate through the STREAM FIN mechanism that no further data will
	be sent on that stream.		be sent on that stream.
	The server MUST send the response(s) on the same stream and MUST		The server MUST send the response(s) on the same stream and MUST
	indicate, after the last response, through the STREAM FIN mechanism		indicate, after the last response, through the STREAM FIN mechanism
	that no further data will be sent on that stream.		that no further data will be sent on that stream.
	Therefore, a single client-initiated DNS transaction consumes a		Therefore, a single DNS transaction consumes a single bidirectional
	single stream. This means that the client's first query occurs on		client-initiated stream. This means that the client's first query
	QUIC stream 0, the second on 4, and so on.		occurs on QUIC stream 0, the second on 4, and so on (see Section 2.1
			of [RFC9000].
	Servers MAY defer processing of a query until the STREAM FIN has been		Servers MAY defer processing of a query until the STREAM FIN has been
	indicated on the stream selected by the client. Servers and clients		indicated on the stream selected by the client. Servers and clients
	MAY monitor the number of "dangling" streams for which the expected		MAY monitor the number of "dangling" streams for which the expected
	queries or responses have been received but not the STREAM FIN.		queries or responses have been received but not the STREAM FIN.
	Implementations MAY impose a limit on the number of such dangling		Implementations MAY impose a limit on the number of such dangling
	streams. If limits are encountered, implementations MAY close the		streams. If limits are encountered, implementations MAY close the
	connection.		connection.
	5.2.1. DNS Message IDs		5.2.1. DNS Message IDs
	skipping to change at page 9, line 48 ¶		skipping to change at page 9, line 48 ¶
	DOQ_ERROR_RESERVED (0xd098ea5e): Alternative error code used for		DOQ_ERROR_RESERVED (0xd098ea5e): Alternative error code used for
	tests.		tests.
	See Section 10.4 for details on registering new error codes.		See Section 10.4 for details on registering new error codes.
	5.3.1. Transaction Cancellation		5.3.1. Transaction Cancellation
	In QUIC, sending STOP_SENDING requests that a peer cease transmission		In QUIC, sending STOP_SENDING requests that a peer cease transmission
	on a stream. If a DoQ client wishes to cancel an outstanding		on a stream. If a DoQ client wishes to cancel an outstanding
	request, it MUST issue a QUIC Stop Sending with error code		request, it MUST issue a QUIC STOP_SENDING with error code
	DOQ_REQUEST_CANCELLED. This may be sent at any time but will be		DOQ_REQUEST_CANCELLED. This may be sent at any time but will be
	ignored if the server response has already been acknowledged. The		ignored if the server response has already been acknowledged. The
	corresponding DNS transaction MUST be abandoned.		corresponding DNS transaction MUST be abandoned.
	Servers that receive STOP_SENDING act in accordance with Section 3.5		Servers that receive STOP_SENDING act in accordance with Section 3.5
	of [RFC9000]. Servers MAY impose implementation limits on the total		of [RFC9000]. Servers MAY impose implementation limits on the total
	number or rate of request cancellations. If limits are encountered,		number or rate of request cancellations. If limits are encountered,
	servers MAY close the connection. In this case, servers wanting to		servers MAY close the connection. In this case, servers wanting to
	help client debugging MAY use the error code DOQ_EXCESSIVE_LOAD.		help client debugging MAY use the error code DOQ_EXCESSIVE_LOAD.
	There is always a trade-off between helping good faith clients debug		There is always a trade-off between helping good faith clients debug
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 30 ¶
	If a peer encounters such an error condition it is considered a fatal		If a peer encounters such an error condition it is considered a fatal
	error. It SHOULD forcibly abort the connection using QUIC's		error. It SHOULD forcibly abort the connection using QUIC's
	CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code		CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code
	DOQ_PROTOCOL_ERROR.		DOQ_PROTOCOL_ERROR.
	It is noted that the restrictions on use of the above EDNS(0) options		It is noted that the restrictions on use of the above EDNS(0) options
	has implications for proxying message from TCP/DoT/DoH over DoQ.		has implications for proxying message from TCP/DoT/DoH over DoQ.
	5.3.4. Alternative error codes		5.3.4. Alternative error codes
	This specification suggests specific error codes Section 5.3.1,		This specification suggests specific error codes in Section 5.3.1,
	Section 5.3.2, and Section 5.3.3. These error codes are meant to		Section 5.3.2, and Section 5.3.3. These error codes are meant to
	facilitate investigation of failures and other incidents. New error		facilitate investigation of failures and other incidents. New error
	codes may be defined in future versions of DoQ, or registered as		codes may be defined in future versions of DoQ, or registered as
	specified in Section 10.4.		specified in Section 10.4.
	Because new error codes can be defined without negotiation, use of an		Because new error codes can be defined without negotiation, use of an
	error code in an unexpected context or receipt of an unknown error		error code in an unexpected context or receipt of an unknown error
	code MUST be treated as equivalent to DOQ_NO_ERROR.		code MUST be treated as equivalent to DOQ_NO_ERROR.
	Implementations MAY wish to test the support for the error code		Implementations MAY wish to test the support for the error code
	skipping to change at page 12, line 18 ¶		skipping to change at page 12, line 18 ¶
	exchange, which minimizes protocol overhead. Per Section 10.1 of		exchange, which minimizes protocol overhead. Per Section 10.1 of
	[RFC9000], the QUIC transport specification, the effective value of		[RFC9000], the QUIC transport specification, the effective value of
	the idle timeout is computed as the minimum of the values advertised		the idle timeout is computed as the minimum of the values advertised
	by the two endpoints. Practical considerations on setting the idle		by the two endpoints. Practical considerations on setting the idle
	timeout are discussed in Section 6.5.2.		timeout are discussed in Section 6.5.2.
	Clients SHOULD monitor the idle time incurred on their connection to		Clients SHOULD monitor the idle time incurred on their connection to
	the server, defined by the time spent since the last packet from the		the server, defined by the time spent since the last packet from the
	server has been received. When a client prepares to send a new DNS		server has been received. When a client prepares to send a new DNS
	query to the server, it will check whether the idle time is		query to the server, it will check whether the idle time is
	sufficient lower than the idle timer. If it is, the client will send		sufficiently lower than the idle timer. If it is, the client will
	the DNS query over the existing connection. If not, the client will		send the DNS query over the existing connection. If not, the client
	establish a new connection and send the query over that connection.		will establish a new connection and send the query over that
			connection.
	Clients MAY discard their connections to the server before the idle		Clients MAY discard their connections to the server before the idle
	timeout expires. A client that has outstanding queries SHOULD close		timeout expires. A client that has outstanding queries SHOULD close
	the connection explicitly using QUIC's CONNECTION_CLOSE mechanism and		the connection explicitly using QUIC's CONNECTION_CLOSE mechanism and
	the DoQ error code DOQ_NO_ERROR.		the DoQ error code DOQ_NO_ERROR.
	Clients and servers MAY close the connection for a variety of other		Clients and servers MAY close the connection for a variety of other
	reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers		reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers
	that send packets over a connection discarded by their peer MAY		that send packets over a connection discarded by their peer MAY
	receive a stateless reset indication. If a connection fails, all the		receive a stateless reset indication. If a connection fails, all the
	in progress transaction on that connection MUST be abandoned.		in progress transaction on that connection MUST be abandoned.
	5.5. Session Resumption and 0-RTT		5.5. Session Resumption and 0-RTT
	A client MAY take advantage of the session resumption mechanisms		A client MAY take advantage of the session resumption mechanisms
	supported by QUIC transport [RFC9000] and QUIC TLS [RFC9001].		supported by QUIC transport [RFC9000] and QUIC TLS [RFC9001].
	Clients SHOULD consider potential privacy issues associated with		Clients SHOULD consider potential privacy issues associated with
	session resumption before deciding to use this mechanism. These		session resumption before deciding to use this mechanism. These
	privacy issues are detailed in Section 9.2 and Section 9.1, and the		privacy issues are detailed in Section 9.1 and Section 9.2, and the
	implementation considerations are discussed in Section 6.5.3.		implementation considerations are discussed in Section 6.5.3.
	The 0-RTT mechanism SHOULD NOT be used to send DNS requests that are		The 0-RTT mechanism SHOULD NOT be used to send DNS requests that are
	not "replayable" transactions. In this specification, only		not "replayable" transactions. In this specification, only
	transactions that have an OPCODE of QUERY or NOTIFY are considered		transactions that have an OPCODE of QUERY or NOTIFY are considered
	replayable and MAY be sent in 0-RTT data. See Appendix A for a		replayable and MAY be sent in 0-RTT data. See Appendix A for a
	detailed discussion of why NOTIFY is included here.		detailed discussion of why NOTIFY is included here.
	Servers MUST NOT execute non replayable transactions received in		Servers MUST NOT execute non replayable transactions received in
	0-RTT data. Servers MUST adopt one of the following behaviors:		0-RTT data. Servers MUST adopt one of the following behaviors:
	skipping to change at page 15, line 27 ¶		skipping to change at page 15, line 27 ¶
	* if padding at the QUIC level is not available or not used, DNS		* if padding at the QUIC level is not available or not used, DNS
	over QUIC MUST ensure that all DNS queries and responses are		over QUIC MUST ensure that all DNS queries and responses are
	padded to a small set of fixed sizes, using the EDNS(0) padding		padded to a small set of fixed sizes, using the EDNS(0) padding
	extension as specified in [RFC7830].		extension as specified in [RFC7830].
	Implementation might choose not to use a QUIC API for padding if it		Implementation might choose not to use a QUIC API for padding if it
	is significantly simpler to re-use existing DNS message padding logic		is significantly simpler to re-use existing DNS message padding logic
	which is applied to other encrypted transports.		which is applied to other encrypted transports.
	In the absence of a standard policy for padding sizes,		In the absence of a standard policy for padding sizes,
	implementations should consider following the recommendations of the		implementations SHOULD follow the recommendations of the Experimental
	Experimental status "Padding Policies for Extension Mechanisms for		status "Padding Policies for Extension Mechanisms for DNS (EDNS(0))"
	DNS (EDNS(0))" [RFC8467].		[RFC8467]. While Experimental, these recommendations are referenced
			because they are implemented and deployed for DoT, and provide a way
			for implementations to be fully compliant with this specification.
	6.5. Connection Handling		6.5. Connection Handling
	"DNS Transport over TCP - Implementation Requirements" [RFC7766]		"DNS Transport over TCP - Implementation Requirements" [RFC7766]
	provides updated guidance on DNS over TCP, some of which is		provides updated guidance on DNS over TCP, some of which is
	applicable to DoQ. This section provides similar advice on		applicable to DoQ. This section provides similar advice on
	connection handling for DoQ.		connection handling for DoQ.
	6.5.1. Connection Reuse		6.5.1. Connection Reuse
	skipping to change at page 20, line 13 ¶		skipping to change at page 20, line 13 ¶
	less per message overhead when compared to DoH).		less per message overhead when compared to DoH).
	* Performs better in mobile environments due to the increased		* Performs better in mobile environments due to the increased
	resilience to packet loss		resilience to packet loss
	* Can maintain connections as users move between mobile networks via		* Can maintain connections as users move between mobile networks via
	its connection management		its connection management
	8. Security Considerations		8. Security Considerations
			A general Threat Analysis of the Domain Name System is found in
			[RFC3833]. This analysis was written before the development of DoT,
			DoH and DoQ, and probably needs to be updated.
	The security considerations of DoQ should be comparable to those of		The security considerations of DoQ should be comparable to those of
	DoT [RFC7858].		DoT [RFC7858]. DoT as specified in [RFC7858] only addresses the stub
			to recursive resolver scenario, but the considerations about person-
			in-the-middle attacks, middleboxes and caching of data from clear
			text connections also apply for DoQ to the resolver to authoritative
			server scenario. As stated in Section 6.1 the authentication
			requirements for securing zone transfer using DoQ are the same as
			those for zone transfer over DoT, therefore the general security
			considerations are entirely analogous to those described in
			[RFC9103].
			DoQ relies on QUIC, which itself relies on TLS 1.3 and thus supports
			by default the protections against downgrade attacks described in
			[BCP195]. QUIC specific issues and their mitigations are described
			in Section 21 of [RFC9000].
	9. Privacy Considerations		9. Privacy Considerations
	The general considerations of encrypted transports provided in "DNS		The general considerations of encrypted transports provided in "DNS
	Privacy Considerations" [RFC9076] apply to DoQ. The specific		Privacy Considerations" [RFC9076] apply to DoQ. The specific
	considerations provided there do not differ between DoT and DoQ, and		considerations provided there do not differ between DoT and DoQ, and
	are not discussed further here. Similarly, "Recommendations for DNS		are not discussed further here. Similarly, "Recommendations for DNS
	Privacy Service Operators" [RFC8932] (which covers operational,		Privacy Service Operators" [RFC8932] (which covers operational,
	policy, and security considerations for DNS privacy services) is also		policy, and security considerations for DNS privacy services) is also
	applicable to DoQ services.		applicable to DoQ services.
	skipping to change at page 24, line 15 ¶		skipping to change at page 24, line 32 ¶
	significant bit in each UDP payload. Such deployments ought to check		significant bit in each UDP payload. Such deployments ought to check
	the signatures of future versions or extensions (e.g.		the signatures of future versions or extensions (e.g.
	[I-D.ietf-quic-bit-grease]) of QUIC and DTLS before deploying them to		[I-D.ietf-quic-bit-grease]) of QUIC and DTLS before deploying them to
	serve DNS on the same port.		serve DNS on the same port.
	IANA is requested to update the following value in the "Service Name		IANA is requested to update the following value in the "Service Name
	and Transport Protocol Port Number Registry" in the System Range.		and Transport Protocol Port Number Registry" in the System Range.
	The registry for that range requires IETF Review or IESG Approval		The registry for that range requires IETF Review or IESG Approval
	[RFC6335].		[RFC6335].
	IANA responded to the early allocation request with the following
	TEMPORARY assignment:
	Service Name: domain-s		Service Name: domain-s
	Port Number: 853		Port Number: 853
	Transport Protocol(s): UDP		Transport Protocol(s): UDP
	Assignee: IETF DPRIVE Chairs		Assignee: IETF DPRIVE Chairs
	Contact: Brian Haberman		Contact: Brian Haberman
	Description: DNS query-response protocol run over DTLS or QUIC		Description: DNS query-response protocol run over DTLS or QUIC
	Reference: [RFC7858][RFC8094] This document		Reference: [RFC7858][RFC8094] This document
	The TEMPORARY assignment expires 13th December 2022.
	Additionally, IANA is requested to update the Description field for		Additionally, IANA is requested to update the Description field for
	the corresponding TCP port 853 allocation to be 'DNS query-response		the corresponding TCP port 853 allocation to be 'DNS query-response
	protocol run over TLS' for consistency and clarity.		protocol run over TLS' for consistency and clarity.
	10.2.1. Port number 784 for experimentations		(UPDATE ON IANA REQUEST: THIS SENTENCE TO BE REMOVED BEFORE
			PUBLICATION) Review by the port experts on 13th December 2021
	(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)		determined that the proposed updates to the existing port allocation
	Early experiments MAY use port 784. This port is marked in the IANA		were acceptable and will be made when this document is approved for
	registry as unassigned.		publication.
	(Note that version in -02 of this draft experiments were directed to
	use port 8853.)
	10.3. Reservation of Extended DNS Error Code Too Early		10.3. Reservation of Extended DNS Error Code Too Early
	IANA is requested to add the following value to the Extended DNS		IANA is requested to add the following value to the Extended DNS
	Error Codes registry [RFC8914]:		Error Codes registry [RFC8914]:
	INFO-CODE: TBD		INFO-CODE: TBD
	Purpose: Too Early		Purpose: Too Early
	skipping to change at page 27, line 11 ¶		skipping to change at page 27, line 44 ¶
	[I-D.ietf-quic-http] edited by Mike Bishop, and from the DoT		[I-D.ietf-quic-http] edited by Mike Bishop, and from the DoT
	specification [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann,		specification [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann,
	Allison Mankin, Duane Wessels, and Paul Hoffman.		Allison Mankin, Duane Wessels, and Paul Hoffman.
	The privacy issue with 0-RTT data and session resumption were		The privacy issue with 0-RTT data and session resumption were
	analyzed by Daniel Kahn Gillmor (DKG) in a message to the IETF		analyzed by Daniel Kahn Gillmor (DKG) in a message to the IETF
	"DPRIVE" working group [DNS0RTT].		"DPRIVE" working group [DNS0RTT].
	Thanks to Tony Finch for an extensive review of the initial version		Thanks to Tony Finch for an extensive review of the initial version
	of this draft, and to Robert Evans for the discussion of 0-RTT		of this draft, and to Robert Evans for the discussion of 0-RTT
	privacy issues. Reviews by Paul Hoffman and Martin Thomson and		privacy issues. Early reviews by Paul Hoffman and Martin Thomson and
	interoperability tests conducted by Stephane Bortzmeyer helped		interoperability tests conducted by Stephane Bortzmeyer helped
	improve the definition of the protocol.		improve the definition of the protocol.
			Thanks also to Martin Thomson and Martin Duke for their later reviews
			focussing on the low level QUIC details which helped clarify several
			aspects of DoQ. Thanks to Andrey Meshkov, Loganaden Velvindron,
			Lucas Pardue, Matt Joras, Mirja Kuelewind, Brian Trammell and Phillip
			Hallam-Baker for their reviews and contributions.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-dnsop-rfc8499bis]		[I-D.ietf-dnsop-rfc8499bis]
	Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in		Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in
	Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03,		Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03,
	28 September 2021, <https://www.ietf.org/archive/id/draft-		28 September 2021, <https://www.ietf.org/archive/id/draft-
	ietf-dnsop-rfc8499bis-03.txt>.		ietf-dnsop-rfc8499bis-03.txt>.
	skipping to change at page 28, line 47 ¶		skipping to change at page 29, line 37 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles		[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
	for DNS over TLS and DNS over DTLS", RFC 8310,		for DNS over TLS and DNS over DTLS", RFC 8310,
	DOI 10.17487/RFC8310, March 2018,		DOI 10.17487/RFC8310, March 2018,
	<https://www.rfc-editor.org/info/rfc8310>.		<https://www.rfc-editor.org/info/rfc8310>.
			[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
			for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
			October 2018, <https://www.rfc-editor.org/info/rfc8467>.
	[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.		[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
	Lawrence, "Extended DNS Errors", RFC 8914,		Lawrence, "Extended DNS Errors", RFC 8914,
	DOI 10.17487/RFC8914, October 2020,		DOI 10.17487/RFC8914, October 2020,
	<https://www.rfc-editor.org/info/rfc8914>.		<https://www.rfc-editor.org/info/rfc8914>.
	[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,		DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/info/rfc9000>.		<https://www.rfc-editor.org/info/rfc9000>.
	skipping to change at page 29, line 21 ¶		skipping to change at page 30, line 16 ¶
	QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,		QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
	<https://www.rfc-editor.org/info/rfc9001>.		<https://www.rfc-editor.org/info/rfc9001>.
	[RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.		[RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
	Mankin, "DNS Zone Transfer over TLS", RFC 9103,		Mankin, "DNS Zone Transfer over TLS", RFC 9103,
	DOI 10.17487/RFC9103, August 2021,		DOI 10.17487/RFC9103, August 2021,
	<https://www.rfc-editor.org/info/rfc9103>.		<https://www.rfc-editor.org/info/rfc9103>.
	12.2. Informative References		12.2. Informative References
			[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
			"Recommendations for Secure Use of Transport Layer
			Security (TLS) and Datagram Transport Layer Security
			(DTLS)", BCP 195, RFC 7525, May 2015.
			Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
			1.1", BCP 195, RFC 8996, March 2021.
			<https://www.rfc-editor.org/info/bcp195>
	[DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG		[DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG
	mailing list, 6 April 2016, <https://www.ietf.org/mail-		mailing list, 6 April 2016, <https://www.ietf.org/mail-
	archive/web/dns-privacy/current/msg01276.html>.		archive/web/dns-privacy/current/msg01276.html>.
	[I-D.ietf-quic-bit-grease]		[I-D.ietf-quic-bit-grease]
	Thomson, M., "Greasing the QUIC Bit", Work in Progress,		Thomson, M., "Greasing the QUIC Bit", Work in Progress,
	Internet-Draft, draft-ietf-quic-bit-grease-02, 10 November		Internet-Draft, draft-ietf-quic-bit-grease-02, 10 November
	2021, <https://www.ietf.org/archive/id/draft-ietf-quic-		2021, <https://www.ietf.org/archive/id/draft-ietf-quic-
	bit-grease-02.txt>.		bit-grease-02.txt>.
	skipping to change at page 29, line 42 ¶		skipping to change at page 30, line 47 ¶
	Bishop, M., "Hypertext Transfer Protocol Version 3		Bishop, M., "Hypertext Transfer Protocol Version 3
	(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-		(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
	quic-http-34, 2 February 2021,		quic-http-34, 2 February 2021,
	<https://www.ietf.org/archive/id/draft-ietf-quic-http-		<https://www.ietf.org/archive/id/draft-ietf-quic-http-
	34.txt>.		34.txt>.
	[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone		[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
	Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,		Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
	August 1996, <https://www.rfc-editor.org/info/rfc1996>.		August 1996, <https://www.rfc-editor.org/info/rfc1996>.
			[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
			Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August
			2004, <https://www.rfc-editor.org/info/rfc3833>.
	[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.		[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
	Cheshire, "Internet Assigned Numbers Authority (IANA)		Cheshire, "Internet Assigned Numbers Authority (IANA)
	Procedures for the Management of the Service Name and		Procedures for the Management of the Service Name and
	Transport Protocol Port Number Registry", BCP 165,		Transport Protocol Port Number Registry", BCP 165,
	RFC 6335, DOI 10.17487/RFC6335, August 2011,		RFC 6335, DOI 10.17487/RFC6335, August 2011,
	<https://www.rfc-editor.org/info/rfc6335>.		<https://www.rfc-editor.org/info/rfc6335>.
	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", BCP 205,		Code: The Implementation Status Section", BCP 205,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		RFC 7942, DOI 10.17487/RFC7942, July 2016,
	skipping to change at page 30, line 14 ¶		skipping to change at page 31, line 26 ¶
	[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram		[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
	Transport Layer Security (DTLS)", RFC 8094,		Transport Layer Security (DTLS)", RFC 8094,
	DOI 10.17487/RFC8094, February 2017,		DOI 10.17487/RFC8094, February 2017,
	<https://www.rfc-editor.org/info/rfc8094>.		<https://www.rfc-editor.org/info/rfc8094>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
	for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
	October 2018, <https://www.rfc-editor.org/info/rfc8467>.
	[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS		[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
	(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,		(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
	<https://www.rfc-editor.org/info/rfc8484>.		<https://www.rfc-editor.org/info/rfc8484>.
	[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,		[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
	Lemon, T., and T. Pusateri, "DNS Stateful Operations",		Lemon, T., and T. Pusateri, "DNS Stateful Operations",
	RFC 8490, DOI 10.17487/RFC8490, March 2019,		RFC 8490, DOI 10.17487/RFC8490, March 2019,
	<https://www.rfc-editor.org/info/rfc8490>.		<https://www.rfc-editor.org/info/rfc8490>.
	[RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and		[RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
End of changes. 25 change blocks.
	48 lines changed or deleted		80 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/