diff --git a/draft-dkg-dprive-demux-dns-http.md b/draft-dkg-dprive-demux-dns-http.md
index ac3335425b03448dd6af4b7324bf501cadf57f48..734358df347febfd59095eaa1748b718f2aded66 100644
--- a/draft-dkg-dprive-demux-dns-http.md
+++ b/draft-dkg-dprive-demux-dns-http.md
@@ -8,7 +8,7 @@ ipr: trust200902
area: int
workgroup: dprive
keyword: Internet-Draft
-updates: 1035, 7230, 7540
+updates: 1035, 7230
stand_alone: yes
pi: [toc, sortrefs, symrefs]
@@ -53,39 +53,42 @@ normative:
--- abstract
-DNS over TCP and traditional HTTP are both stream-oriented,
+DNS over TCP and HTTP/1.x are both stream-oriented,
client-speaks-first protocols. They can both be run over a
stream-based security protocol like TLS. A server accepting a
stream-based client can distinguish between a valid stream of DNS
-queries and valid stream of HTTP requests by simple observation of the
-first few octets sent by the client. This can be done without any
+queries and valid stream of HTTP/1.x requests by simple observation of
+the first few octets sent by the client. This can be done without any
external demultiplexing mechanism like TCP port number or ALPN.
Implicit multiplexing of the two protocols over a single listening
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
+Widespread adoption of the described approach could constrain
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.
+HTTP/1.x ({{RFC7230}}) by ossifying existing distinguishing bit
+patterns in early octets sent by the client. However, this draft
+explicitly rules out multiplexing in this form with HTTP/2, so it
+should place no constraints on it or any higher version of HTTP.
--- middle
Introduction
============
-DNS and HTTP are both client-speaks-first protocols capable of running
-over stream-based transport like TCP, or as the payload of a typical
-TLS {{RFC5246}} session.
+DNS and HTTP/1.1 are both client-speaks-first protocols capable of
+running over stream-based transport like TCP, or as the payload of a
+typical TLS {{RFC5246}} session.
There are some contexts where it is useful for a server to be able to
decide what protocol is used by an incoming TCP stream, to choose
-dynamically between DNS and HTTP on the basis of the stream itself
+dynamically between DNS and HTTP/1.1 on the basis of the stream itself
(rather than a port designation or other explicit demultiplexing).
-For example, a TLS terminator listening on port 443 might be willing
-to serve DNS-over-TLS {{RFC7858}} as well as HTTPS.
+For example, a TLS terminator listening on port 443 and receiving
+either no ALPN token at all, or the "http/1.1" ALPN token might be
+willing to serve DNS-over-TLS {{RFC7858}} as well as HTTPS.
A simple demultiplexing server should do this demuxing based on the
first few bytes sent by the client on a given stream; once a choice
@@ -93,22 +96,21 @@ has been established, the rest of the stream is committed to one or
the other interpretation.
This document provides proof that a demultiplexer can robustly
-distinguish HTTP from DNS on the basis of the content of the stream
-alone.
+distinguish HTTP/1.1 from DNS on the basis of the content of the
+first few bytes of the client's stream alone.
A DNS client that knows it is talking to a server which is this
-position (e.g. trying to do DNS-over-TLS on TCP port 443, used
-traditionally only for HTTPS) might also want to be aware of network
-traffic patterns that could confuse such a server. This document
-presents explicit mitigations that such a DNS client MAY decide to
-use.
-
-This document limits its discussion of HTTP over TCP or TLS or some
-other classical stream-based protocol (it excludes HTTP over QUIC, for
-example). Likewise, it considers only the TCP variant of DNS (and
-excludes DNS over UDP or any other datagram transport).
-
-FIXME: address network stack ossification here?
+position (e.g. trying to do DNS-over-TLS on TCP port 443 with no ALPN
+token, used traditionally only for HTTPS) might also want to be aware
+of network traffic patterns that could confuse such a server. This
+document presents explicit mitigations that such a DNS client MAY
+decide to use.
+
+This document limits its discussion to HTTP/1.x over TCP or TLS or
+some other classical stream-based protocol (it excludes HTTP over
+QUIC, for example, and HTTP/2 or later). Likewise, it considers only
+the TCP variant of DNS (and excludes DNS over UDP or any other
+datagram transport).
Terminology
-----------
@@ -124,41 +126,62 @@ Scoping
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/1.x requests
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/1.1
request, or after a DNS message), but this document focuses
specifically on a heuristic choice for the whole stream, based on the
initial few octets sent by the client.
While it's tempting to consider distinguishing at multiple points in
the stream, the complexities of determining the specific end of an
-HTTP/1.1 request body, and the difficulty in distinguishing an HTTP/2
-frame header from a streamed DNS message make this more difficult to
-implement. Interleaving the responses themselves on a stream with
-multiple data elements is also challenging. So do not use this
+HTTP/1.1 request body and handling HTTP/1.x error cases make this more
+difficult to implement on the side of a DNS client configured to talk
+to such a server. Interleaving the responses themselves on a stream
+with multiple data elements is also challenging. So do not use this
technique anywhere but at the beginning of a stream!
If being able to interleave DNS queries with HTTP requests on a single
stream is desired, a strategy like {{I-D.hoffman-dns-over-https}} or
{{I-D.ietf-dnsop-dns-wireformat-http}} is recommended instead.
+HTTP/2 is not always client-speaks-first
+----------------------------------------
+
+While this demultiplexing technique functions for HTTP/1.0 and
+HTTP/1.1, it does not work for HTTP/2 because HTTP/2 is not guaranteed
+to be a client-speaks-first protocol. In the event that HTTP/2 is to
+be transported over TLS, the ALPN token negotiated in the TLS session
+is "h2", which allows the server to know as soon as the handshake is
+complete that it can start pushing data to the client.
+
+A standard DNS-over-TLS client connecting to a server that might be
+multiplexing DNS with HTTP on the same listener MUST NOT indicate an
+intent to speak HTTP/2 that could prompt this unsolicited first flight
+from the server. Concretely, a DNS client connecting over TLS on TCP
+port 443 expecting to speak standard DNS-over-TLS {{RFC7858}} MUST NOT
+offer or accept the "h2" ALPN token.
+
+If use of DNS in the same channel as HTTP/2 is deisred, a strategy
+like {{I-D.hoffman-dns-over-https}} is recommended instead.
+
Avoid multiplexing in the clear
-------------------------------
-The widespread deployment of transparent HTTP proxies makes it likely
-that any attempt to do this kind of multiplexing/demultiplexing on a
-cleartext channel that normally carries HTTP (e.g. TCP port 80) will
-fail or trigger other "interesting" behaviors. This approach should
-be done only in channels sufficiently obscured that a transparent
-proxy would not try to interpret the resultant stream.
+The widespread deployment of transparent HTTP/1.x proxies makes it
+likely that any attempt to do this kind of multiplexing/demultiplexing
+on a cleartext channel that normally carries HTTP/1.x (e.g. TCP port
+80) will fail or trigger other "interesting" behaviors. The approach
+described in this draft should be done only in channels sufficiently
+obscured that a transparent proxy would not try to interpret the
+resultant stream.
Avoid mixing with other demultiplexing
--------------------------------------
Some other (non-IETF) systems (e.g. {{HAPROXY}}) take a similar
-approach with multiplexing data on top of HTTP by taking advantage of
-bitpatterns that are presumed to not be present in normal HTTP
+approach with multiplexing data on top of HTTP/1.x by taking advantage
+of bitpatterns that are presumed to not be present in normal HTTP/1.x
requests.
Use of the approach described in this draft in conjunction with these
@@ -175,19 +198,31 @@ these environments, an explicit HTTP proxy is available, and clients
must use the HTTP CONNECT pseudo-method to make https connections.
While this multiplexing approach can be used in such a restrictive
environment, it would be necessary to teach the DNS client how to talk
-to the HTTP proxy. These details are out of scope for this document.
+to (and through) the HTTP proxy. These details are out of scope for
+this document. A DNS client capable of this additional layer of
+complexity may prefer to pursue a strategy like
+{{I-D.hoffman-dns-over-https}} instead.
Why not ALPN?
-------------
If this is done over TLS, a natural question is whether the client
should simply indicate its preferred protocol in the TLS handshake's
-ALPN {{RFC7301}} extension.
-
-However, ALPN headers are visible to a network observer, and a network
-controller attempting to confine the user's DNS traffic to a limited
-set of servers could use the ALPN header as a signal to block
-DNS-specific streams.
+ALPN {{RFC7301}} extension (e.g. with some new ALPN token "dns").
+
+However, ALPN tokens requested by the client are visible to a network
+observer (and the ALPN token selected by the server is visible to a
+network observer in TLS 1.2 and earlier), so a network controller
+attempting to confine the user's DNS traffic to a limited set of
+servers could use the ALPN extension as a signal to block DNS-specific
+streams.
+
+Another alternative could be an ALPN token that indicates
+potentially-multiplexed traffic (e.g. "http/1.1-or-dns"). This has a
+comparable problem when confronted with a network adversary that
+intends to penalize or hamper DNS-over-TLS. Existing HTTP clients
+will not send this token, and even if some start to offer it, it will
+provide less cover for DNS-over-TLS clients.
Overview of initial octets
==========================
@@ -238,15 +273,15 @@ stream:
All DNS streams sent over TCP start with at least these 14 octets.
-HTTP initial octets
+HTTP/1.x initial octets
-------------------
-In an HTTP stream, the first octets sent from the client are either
-the so-called `Simple-Request` (for HTTP/0.9), the `Request-Line` (for
-HTTP/1.0 and HTTP/1.1), which has variable characteristics, or the
-"connection preface" (for HTTP/2) which is a fixed string.
+In an HTTP stream before HTTP/2, the first octets sent from the client
+are either the so-called `Simple-Request` (for HTTP/0.9) or the
+`Request-Line` (for HTTP/1.0 and HTTP/1.1). The data in this initial
+stream has variable characteristics.
-Some servers may wish to ignore the oldest of these, HTTP/0.9.
+Most servers may wish to ignore the oldest of these, HTTP/0.9.
### HTTP/0.9
@@ -329,27 +364,6 @@ So we should also consider accepting an arbitrary number of repeated
CRLF sequences before the request-line as a potentially-valid HTTP
client behavior.
-### HTTP/2
-
-{{RFC7540}} section 3.5 says:
-
- In HTTP/2, each endpoint is required to send a connection preface as
- a final confirmation of the protocol in use and to establish the
- initial settings for the HTTP/2 connection. The client and server
- each send a different connection preface.
-
- The client connection preface starts with a sequence of 24 octets,
- which in hex notation is:
-
- 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
-
- That is, the connection preface starts with the string "PRI *
- HTTP/2.0\r\n\r\nSM\r\n\r\n").
-
-The highest valued octet here is 0x54 ("T"), and the lowest is 0x0A
-(LF).
-
-
Specific octets
===============
@@ -360,12 +374,12 @@ octets 0 and 1
--------------
Any DNS message less than 3338 octets sent as the initial query over
-TCP can be reliably distinguished from any version of HTTP by the
+TCP can be reliably distinguished from any version of HTTP/1.x by the
first two octets of the TCP stream alone.
-3338 is 0x0D0A, or the ASCII string CRLF, which some HTTP clients
-might send before an initial request. No HTTP client can legitimately
-send anything lower than this.
+3338 is 0x0D0A, or the ASCII string CRLF, which some HTTP/1.x clients
+might send before an initial request. No HTTP/1.x client can
+legitimately send anything lower than this.
Most DNS queries are easily within this range automatically.
@@ -386,10 +400,10 @@ values.
With a standard DNS client which fully-randomizes these values, only
25% of generated queries will have the high bits of both octets set to
-0. 100% of all HTTP requests will have the high bits of both of these
-octets cleared. Similarly, some small percentage of
+0. 100% of all HTTP/1.x requests will have the high bits of both of
+these octets cleared. Similarly, some small percentage of
randomly-generated DNS queries will have values here lower than 0x0A,
-while no HTTP clients will ever send these low values.
+while no HTTP/1.x clients will ever send these low values.
octet 4
-------
@@ -405,12 +419,12 @@ In a standard DNS query sent over a streaming interface, QR, Opcode,
AA, and TC are all set to 0. The least-significant bit (RD --
Recursion Desired) is set when a packet is sent from a stub to a
recursive resolver. The value of such an octet is 0x01. This value
-never occurs in octet 4 of a legitimate HTTP client.
+never occurs in octet 4 of a legitimate HTTP/1.x client.
But under DNS UPDATE ({{RFC2136}}, Opcode is set to 5 and all the
option bits are cleared, which means this value would have 0x40 (ASCII
-'@'), which could legitimately occur in some HTTP requests at this
-position..
+'@'), which could legitimately occur in some HTTP/1.x requests at this
+position.
octet 5
-------
@@ -434,7 +448,7 @@ Data.
So many queries, particularly from DNSSEC-validating DNS clients, are
likely to set bits 2 and 3, resulting in a value 0x30 (ASCII '0').
-This is usually a legitimate value for octet 5 in an HTTP request.
+This is usually a legitimate value for octet 5 in an HTTP/1.x request.
octets 6 and 7
--------------
@@ -443,7 +457,7 @@ In DNS, octets 6 and 7 represent the query count. Most DNS clients
will send one query at a time, which makes this value 0x0001. As long
as the number of initial queries does not exceed 0x0A0A (2570), then
at least one of these octets will have a value less than 0x0A. No
-HTTP client sends an octet less than 0x0A in positions 6 or 7.
+HTTP/1.x client sends an octet less than 0x0A in positions 6 or 7.
In DNS UPDATE, octets 6 and 7 represent the zone count. Entries in
the Zone section of the DNS UPDATE message are structured identically
@@ -458,8 +472,8 @@ counts in DNS UPDATE. Standard DNS queries will set them both 0. DNS
UPDATE queries are likely to include some records in these sections,
so they won't be all zero, but as long as no more than 2570
Prerequisite records and no more than 2570 Update records are sent, at
-least one octet will have value less than 0x0A. But No HTTP client
-sends an octet less tan 0x0A in these positions.
+least one octet will have value less than 0x0A. But no HTTP/1.x
+client sends an octet less than 0x0A in these positions.
octets 12 and 13
----------------
@@ -469,7 +483,7 @@ RRs. When a DNS query is sent with EDNS(0), the OPT RR is accounted
for here. So this is often either 0x0000 or 0x0001. In a Secure DNS
UPDATE {{RFC3007}}, the SIG(0) or TSIG record is also found in this
section, which could increase the values of these octets to 0x0002.
-No HTTP client will send octets with these low values at these
+No HTTP/1.x client will send octets with these low values at these
positions.
Combinations of octets
@@ -497,7 +511,7 @@ It's possible to compare this value with the expected first query size:
if `first_query_size` is less than `min_first_query_size` we can be
confident that the stream is not DNS.
-### Proof: a valid DNS message cannot be an HTTP query
+### Proof: a valid DNS message cannot be an HTTP/1.x query
For any a valid, stream-based DNS message:
@@ -510,7 +524,7 @@ For any a valid, stream-based DNS message:
* If there are fewer than 0x0A00 Additional RRs, then octet 12 < 0x0A.
If any of these four inequalities hold, then the packet is clearly
-DNS, not HTTP.
+DNS, not HTTP/1.x.
if none of them hold, then there are at least 0x0A00 (2560) Questions
and 3*2560 == 7680 RRs. But:
@@ -524,22 +538,23 @@ size to 65535 octets.
Therefore at least one of these inequalities holds, and one of the
first 14 octets of a DNS steam is < 0x0A.
-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
-request.
+But in a standard HTTP/1.x request, none of the first 14 octets can
+have a value < 0x0A, so a valid DNS message cannot be mistaken for an
+HTTP/1.x request.
Guidance for Demultiplexing Servers
===================================
-Upon receiving a connection stream that might be either DNS or HTTP, a
-server can inspect the initial octets of the stream to decide where to
-send it.
+Upon receiving a connection stream that might be either DNS or
+HTTP/1.x, a server can inspect the initial octets of the stream to
+decide where to send it.
Without supporting HTTP/0.9
---------------------------
A server that doesn't care about HTTP/0.9 can simply wait for the
-first 14 octets of the client's request to come in. Then the algorithm is:
+first 14 octets of the client's request to come in. Then the
+algorithm is:
bytestream = read_from_client(14)
for x in bytestream:
@@ -591,21 +606,31 @@ valid HTTP nor valid DNS, and can be discarded.
Signaling demultiplexing capacity
---------------------------------
-FIXME: should there be a way for a listener to signal somehow that it
-is willing and capable of handling both DNS and HTTP traffic? There
-would need to be a different signaling mechanism for each stream
-(unless the signalling is done somehow in an outer layer like TLS).
-This is probably out-of-scope for this draft.
+This document assumes that clients can learn out-of-band which
+listening service they can connect to. For example, the administrator
+of a machine can configure a local forwarding stub resolver to use
+DNS-over-TLS on port 443 of some specific server. This explicit
+configuration carries with it some level of trust -- the client is
+choosing to trust the configured server with its DNS queries.
+
+In some circumstances, it might be useful for a listener to signal to
+a client that it is willing and capable of handling both DNS and
+HTTP/1.x traffic. While such signalling could be useful for dynamic
+discovery, it opens questions of trust (which servers should the
+client be willing to rely on for DNS resolution?) and is out-of-scope
+for this draft.
Guidance for DNS clients
========================
Consider a DNS client that connects to a server that might be
-interested in answering HTTP requests on the same address/port (or
+interested in answering HTTP/1.x requests on the same address/port (or
other channel identifier). The client wants to send traffic that is
unambiguously DNS traffic to make it easy for the server to
-distinguish it from inbound HTTP requests. Fortunately, this is
-trivial to do.
+distinguish it from inbound HTTP/1.x requests. Fortunately, this is
+trivial to do. In fact, any sensibly-implemented DNS-over-TLS client
+can use this approach without modification, just by adjusting the port
+number of the upstream recursive resolver from 853 to 443.
Such a client should follow these guidelines:
@@ -706,12 +731,23 @@ registries.
However, it does update the DNS and HTTP specifications, to reflect
the fact that services using this demultiplexing technique may be
-constrained in adoption of future versions of either DNS or HTTP if
-those future versions modify either protocol in a way that breaks with
-the distinctions documented here.
+constrained in adoption of future versions of either stream-based DNS
+or HTTP/1.x if those future versions modify either protocol in a way
+that breaks with the distinctions documented here.
+
+In particular, this draft assumes that all future stream-based
+versions of HTTP/1.x should have the following properties:
+
+ * the client will speak first
+
+ * the client will send at least 14 octets before expecting a response
+ from the server.
+
+ * none of those first 14 octets will be below 0x0A (LF) or above 0x7F
+ (DEL).
-Future revisions of or extensions to stream-based DNS or HTTP should
-take this demultiplexing technique into consideration.
+Future extensions to stream-based DNS or HTTP/1.x should take this
+demultiplexing technique into consideration.
Document Considerations
=======================