< draft-dkg-dprive-demux-dns-http-01.txt		draft-dkg-dprive-demux-dns-http-02.txt >
	dprive D. Gillmor		dprive D. Gillmor
	Internet-Draft ACLU		Internet-Draft ACLU
	Updates: 1035, 7230, 7540 (if approved) May 03, 2017		Updates: 1035, 7230, 7540 (if approved) May 03, 2017
	Intended status: Informational		Intended status: Informational
	Expires: November 4, 2017		Expires: November 4, 2017
	Demultiplexing Streamed DNS from HTTP		Demultiplexing Streamed DNS from HTTP
	draft-dkg-dprive-demux-dns-http-01		draft-dkg-dprive-demux-dns-http-02
	Abstract		Abstract
	DNS over TCP and traditional HTTP are both stream-oriented, client-		DNS over TCP and traditional HTTP are both stream-oriented, client-
	speaks-first protocols. They can both be run over a stream-based		speaks-first protocols. They can both be run over a stream-based
	security protocol like TLS. A server accepting a stream-based client		security protocol like TLS. A server accepting a stream-based client
	can distinguish between a valid stream of DNS queries and valid		can distinguish between a valid stream of DNS queries and valid
	stream of HTTP requests by simple observation of the first few octets		stream of HTTP requests by simple observation of the first few octets
	sent by the client. This can be done without any external		sent by the client. This can be done without any external
	demultiplexing mechanism like TCP port number or ALPN.		demultiplexing mechanism like TCP port number or ALPN.
	Implicit multiplexing of the two protocols over a single listening		Implicit multiplexing of the two protocols over a single listening
	port can be useful for obscuring the presence of DNS queries from a		port can be useful for obscuring the presence of DNS queries from a
	network observer, which makes it relevant for DNS privacy.		network observer, which makes it relevant for DNS privacy.
			Widespread adoption of the described approach could constrain future
			evolution of the stream-based variants of both DNS ([RFC1035]) and
			HTTP ([RFC7230] and [RFC7540]) by ossifying existing distinguishing
			bit patterns in early octets sent by the client.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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/.
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 23 ¶
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Distinguish only at the start of a stream . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
			2. Distinguish only at the start of a stream . . . . . . . . . . 4
	2.1. Why not ALPN? . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Why not ALPN? . . . . . . . . . . . . . . . . . . . . . . 4
	3. Overview of initial octets . . . . . . . . . . . . . . . . . 4		3. Overview of initial octets . . . . . . . . . . . . . . . . . 4
	3.1. DNS stream initial octets . . . . . . . . . . . . . . . . 4		3.1. DNS stream initial octets . . . . . . . . . . . . . . . . 4
	3.2. HTTP initial octets . . . . . . . . . . . . . . . . . . . 5		3.2. HTTP initial octets . . . . . . . . . . . . . . . . . . . 5
	3.2.1. HTTP/0.9 . . . . . . . . . . . . . . . . . . . . . . 6		3.2.1. HTTP/0.9 . . . . . . . . . . . . . . . . . . . . . . 6
	3.2.2. HTTP/1.0 and HTTP/1.1 . . . . . . . . . . . . . . . . 6		3.2.2. HTTP/1.0 and HTTP/1.1 . . . . . . . . . . . . . . . . 6
	3.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 7		3.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Specific octets . . . . . . . . . . . . . . . . . . . . . . . 8		4. Specific octets . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. octets 0 and 1 . . . . . . . . . . . . . . . . . . . . . 8		4.1. octets 0 and 1 . . . . . . . . . . . . . . . . . . . . . 8
	4.2. octets 2 and 3 . . . . . . . . . . . . . . . . . . . . . 8		4.2. octets 2 and 3 . . . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 46 ¶
	presents explicit mitigations that such a DNS client MAY decide to		presents explicit mitigations that such a DNS client MAY decide to
	use.		use.
	This document limits its discussion of HTTP over TCP or TLS or some		This document limits its discussion of HTTP over TCP or TLS or some
	other classical stream-based protocol (it excludes HTTP over QUIC,		other classical stream-based protocol (it excludes HTTP over QUIC,
	for example). Likewise, it considers only the TCP variant of DNS		for example). Likewise, it considers only the TCP variant of DNS
	(and excludes DNS over UDP or any other datagram transport).		(and excludes DNS over UDP or any other datagram transport).
	FIXME: address network stack ossification here?		FIXME: address network stack ossification here?
			1.1. Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	2. Distinguish only at the start of a stream		2. Distinguish only at the start of a stream
	A server which attempts to distinguish DNS queries from HTTP requests		A server which attempts to distinguish DNS queries from HTTP requests
	individually might consider using these guidelines in the middle of a		individually might consider using these guidelines in the middle of a
	running stream (e.g. at natural boundaries, like the end of an HTTP		running stream (e.g. at natural boundaries, like the end of an HTTP
	request, or after a DNS message), but this document focuses		request, or after a DNS message), but this document focuses
	specifically on a heuristic choice for the whole stream, based on the		specifically on a heuristic choice for the whole stream, based on the
	initial few octets sent by the client.		initial few octets sent by the client.
	While it's tempting to consider distinguishing at multiple points in		While it's tempting to consider distinguishing at multiple points in
	skipping to change at page 11, line 43 ¶		skipping to change at page 11, line 43 ¶
	If any of these four inequalities hold, then the packet is clearly		If any of these four inequalities hold, then the packet is clearly
	DNS, not HTTP.		DNS, not HTTP.
	if none of them hold, then there are at least 0x0A00 (2560) Questions		if none of them hold, then there are at least 0x0A00 (2560) Questions
	and 3*2560 == 7680 RRs. But:		and 3*2560 == 7680 RRs. But:
	12 + 5*2560 + 11*7680 == 97292		12 + 5*2560 + 11*7680 == 97292
	So the smallest possible DNS message where none of these four		So the smallest possible DNS message where none of these four
	inequalites hold is 97292 octets. But a DNS message is limited in		inequalities hold is 97292 octets. But a DNS message is limited in
	size to 65535 octets.		size to 65535 octets.
	Therefore at least one of these inequalities holds, and one of the		Therefore at least one of these inequalities holds, and one of the
	first 14 octets of a DNS steam is < 0x0A.		first 14 octets of a DNS steam is < 0x0A.
	But in a standard HTTP request, none of the first 14 octets can have		But in a standard HTTP request, none of the first 14 octets can have
	a value < 0x0A, so a valid DNS message cannot be mistaken for an HTTP		a value < 0x0A, so a valid DNS message cannot be mistaken for an HTTP
	request.		request.
	6. Guidance for Demultiplexing Servers		6. Guidance for Demultiplexing Servers
	skipping to change at page 14, line 36 ¶		skipping to change at page 14, line 36 ¶
	server gets to see in the fragmented stream case are in square		server gets to see in the fragmented stream case are in square
	brackets after each mitigation]:		brackets after each mitigation]:
	o Ensure the first message is marked as a query (QR = 0), and it		o Ensure the first message is marked as a query (QR = 0), and it
	uses opcode 0 ("Standard Query"). [bytestream[4] < 0x08]		uses opcode 0 ("Standard Query"). [bytestream[4] < 0x08]
	o Ensure that the first message has RA = 0, Z = 0, and RCODE = 0.		o Ensure that the first message has RA = 0, Z = 0, and RCODE = 0.
	[bytestream[5] == 0x00]		[bytestream[5] == 0x00]
	o Ensure that the high bit of the first octet of the message ID of		o Ensure that the high bit of the first octet of the message ID of
	the first message is set. [bytesteam[2] > 0x7F]		the first message is set. [bytestream[2] > 0x7F]
	o Send an initial short Server Status DNS message ahead of the		o Send an initial short Server Status DNS message ahead of the
	otherwise intended initial DNS message. [bytstream[0] == 0x00]		otherwise intended initial DNS message. [bytestream[0] == 0x00]
	o Use the EDNS(0) padding option [RFC7830] to pad the first message		o Use the EDNS(0) padding option [RFC7830] to pad the first message
	to a multiple of 256 octets. [bytestream[1] == 0x00]		to a multiple of 256 octets. [bytestream[1] == 0x00]
	7.1. Interpreting failure		7.1. Interpreting failure
	FIXME: A DNS client that does not already know that a server is		FIXME: A DNS client that does not already know that a server is
	willing to carry both types of traffic SHOULD expect a transport		willing to carry both types of traffic SHOULD expect a transport
	connection failure of some sort. Can we say something specific about		connection failure of some sort. Can we say something specific about
	what it should expect?		what it should expect?
	skipping to change at page 15, line 20 ¶		skipping to change at page 15, line 20 ¶
	to distinguish the two protocols.		to distinguish the two protocols.
	9. Security Considerations		9. Security Considerations
	FIXME: Clients should locally validate DNSSEC (servers may still be		FIXME: Clients should locally validate DNSSEC (servers may still be
	able to omit some records)		able to omit some records)
	FIXME: if widely deployed, consider amplification for DDoS against		FIXME: if widely deployed, consider amplification for DDoS against
	authoritative servers?		authoritative servers?
	FIXME: consider dnssec transparency		FIXME: consider DNSSEC transparency
	FIXME: consider TLS session resumption - this counts as a new stream		FIXME: consider TLS session resumption - this counts as a new stream
	boundary, so the multiplexing decision need not persist across		boundary, so the multiplexing decision need not persist across
	resumption.		resumption.
	FIXME: consider 0-RTT		FIXME: consider 0-RTT
	FIXME: consider X.509 cert validation		FIXME: consider X.509 cert validation
	FIXME: what other security considerations should clients take?		FIXME: what other security considerations should clients take?
	skipping to change at page 16, line 34 ¶		skipping to change at page 16, line 34 ¶
	[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>.
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext		[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
	Transfer Protocol -- HTTP/1.0", RFC 1945,		Transfer Protocol -- HTTP/1.0", RFC 1945,
	DOI 10.17487/RFC1945, May 1996,		DOI 10.17487/RFC1945, May 1996,
	<http://www.rfc-editor.org/info/rfc1945>.		<http://www.rfc-editor.org/info/rfc1945>.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,		[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
	"Dynamic Updates in the Domain Name System (DNS UPDATE)",		"Dynamic Updates in the Domain Name System (DNS UPDATE)",
	RFC 2136, DOI 10.17487/RFC2136, April 1997,		RFC 2136, DOI 10.17487/RFC2136, April 1997,
	<http://www.rfc-editor.org/info/rfc2136>.		<http://www.rfc-editor.org/info/rfc2136>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<http://www.rfc-editor.org/info/rfc5234>.
End of changes. 9 change blocks.
	6 lines changed or deleted		24 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/