idnits 2.17.00 (12 Aug 2021) /tmp/idnits28441/draft-dkg-dprive-demux-dns-http-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 120: '...s that such a DNS client MAY decide to...' RFC 2119 keyword, line 298: '...e a request-line SHOULD ignore at leas...' RFC 2119 keyword, line 559: '... MAY also take one of the following ...' RFC 2119 keyword, line 582: '...types of traffic SHOULD expect a trans...' RFC 2119 keyword, line 588: '... HTTP clients SHOULD NOT send HTTP/0...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 24, 2017) is 1853 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '6' on line 421 -- Looks like a reference, but probably isn't: '7' on line 421 -- Looks like a reference, but probably isn't: '8' on line 422 -- Looks like a reference, but probably isn't: '10' on line 422 -- Looks like a reference, but probably isn't: '12' on line 422 -- Looks like a reference, but probably isn't: '9' on line 423 -- Looks like a reference, but probably isn't: '11' on line 423 -- Looks like a reference, but probably isn't: '13' on line 423 -- Looks like a reference, but probably isn't: '0' on line 574 -- Looks like a reference, but probably isn't: '1' on line 577 -- Looks like a reference, but probably isn't: '4' on line 565 -- Looks like a reference, but probably isn't: '5' on line 568 -- Looks like a reference, but probably isn't: '2' on line 571 == Outdated reference: A later version (-03) exists of draft-ietf-dnsop-dns-wireformat-http-01 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive D. Gillmor 3 Internet-Draft ACLU 4 Intended status: Informational April 24, 2017 5 Expires: October 26, 2017 7 Demultiplexing Streamed DNS from HTTP 8 draft-dkg-dprive-demux-dns-http-00 10 Abstract 12 DNS over TCP and traditional HTTP are both stream-oriented, client- 13 speaks-first protocols. They can both be run over a stream-based 14 security protocol like TLS. A server accepting a stream-based client 15 can distinguish between a valid stream of DNS queries and valid 16 stream of HTTP requests by simple observation of the first few octets 17 sent by the client. This can be done without any external 18 demultiplexing mechanism like TCP port number or ALPN. 20 Implicit multiplexing of the two protocols over a single listening 21 port can be useful for obscuring the presence of DNS queries from a 22 network observer, which makes it relevant for DNS privacy. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 26, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Distinguish only at the start of a stream . . . . . . . . . . 3 60 2.1. Why not ALPN? . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overview of initial octets . . . . . . . . . . . . . . . . . 4 62 3.1. DNS stream initial octets . . . . . . . . . . . . . . . . 4 63 3.2. HTTP initial octets . . . . . . . . . . . . . . . . . . . 5 64 3.2.1. HTTP/0.9 . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2.2. HTTP/1.0 and HTTP/1.1 . . . . . . . . . . . . . . . . 6 66 3.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Specific octets . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. octets 0 and 1 . . . . . . . . . . . . . . . . . . . . . 8 69 4.2. octets 2 and 3 . . . . . . . . . . . . . . . . . . . . . 8 70 4.3. octet 4 . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.4. octet 5 . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.5. octets 6 and 7 . . . . . . . . . . . . . . . . . . . . . 9 73 4.6. octets 8 through 11 . . . . . . . . . . . . . . . . . . . 9 74 4.7. octets 12 and 13 . . . . . . . . . . . . . . . . . . . . 10 75 5. Combinations of octets . . . . . . . . . . . . . . . . . . . 10 76 5.1. Proof: a valid DNS message cannot be an HTTP query . . . 10 77 6. Guidance for Demultiplexing Servers . . . . . . . . . . . . . 11 78 6.1. Without supporting HTTP/0.9 . . . . . . . . . . . . . . . 11 79 6.2. Supporting archaic HTTP/0.9 clients . . . . . . . . . . . 11 80 6.3. Signaling demultiplexing capacity . . . . . . . . . . . . 12 81 7. Guidance for DNS clients . . . . . . . . . . . . . . . . . . 12 82 7.1. Interpreting failure . . . . . . . . . . . . . . . . . . 13 83 8. Guidance for HTTP clients . . . . . . . . . . . . . . . . . . 14 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 87 12. Document Considerations . . . . . . . . . . . . . . . . . . . 15 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 90 13.2. Informative References . . . . . . . . . . . . . . . . . 15 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 DNS and HTTP are both client-speaks-first protocols capable of 96 running over stream-based transport like TCP, or as the payload of a 97 typical TLS [RFC5246] session. 99 There are some contexts where it is useful for a server to be able to 100 decide what protocol is used by an incoming TCP stream, to choose 101 dynamically between DNS and HTTP on the basis of the stream itself 102 (rather than a port designation or other explicit demultiplexing). 104 For example, a TLS terminator listening on port 443 might be willing 105 to serve DNS-over-TLS [RFC7858] as well as HTTPS. 107 A simple demultiplexing server should do this demuxing based on the 108 first few bytes sent by the client on a given stream; once a choice 109 has been established, the rest of the stream is committed to one or 110 the other interpretation. 112 This document provides proof that a demultiplexer can robustly 113 distinguish HTTP from DNS on the basis of the content of the stream 114 alone. 116 A DNS client that knows it is talking to a server which is this 117 position (e.g. trying to do DNS-over-TLS on TCP port 443, used 118 traditionally only for HTTPS) might also want to be aware of network 119 traffic patterns that could confuse such a server. This document 120 presents explicit mitigations that such a DNS client MAY decide to 121 use. 123 This document limits its discussion of HTTP over TCP or TLS or some 124 other classical stream-based protocol (it excludes HTTP over QUIC, 125 for example). Likewise, it considers only the TCP variant of DNS 126 (and excludes DNS over UDP or any other datagram transport). 128 FIXME: address network stack ossification here? 130 2. Distinguish only at the start of a stream 132 A server which attempts to distinguish DNS queries from HTTP requests 133 individually might consider using these guidelines in the middle of a 134 running stream (e.g. at natural boundaries, like the end of an HTTP 135 request, or after a DNS message), but this document focuses 136 specifically on a heuristic choice for the whole stream, based on the 137 initial few octets sent by the client. 139 While it's tempting to consider distinguishing at multiple points in 140 the stream, the complexities of determining the specific end of an 141 HTTP/1.1 request body, and the difficulty in distinguishing an HTTP/2 142 frame header from a streamed DNS message make this more difficult to 143 implement. Interleaving the responses themselves on a stream with 144 multiple data elements is also challenging. So do not use this 145 technique anywhere but at the beginning of a stream! 147 If being able to interleave DNS queries with HTTP requests on a 148 single stream is desired, a strategy like 149 [I-D.ietf-dnsop-dns-wireformat-http] is recommended instead. 151 2.1. Why not ALPN? 153 If this is done over TLS, a natural question is whether the client 154 should simply indicate its preferred protocol in the TLS handshake's 155 ALPN [RFC7301] extension. 157 However, ALPN headers are visible to a network observer, and a 158 network controller attempting to confine the user's DNS traffic to a 159 limited set of servers could use the ALPN header as a signal to block 160 DNS-specific streams. 162 3. Overview of initial octets 164 3.1. DNS stream initial octets 166 [RFC1035] section 4.2.2 ("TCP Usage") shows that every stream-based 167 DNS connection starts with a DNS message, preceded with a 2-octet 168 message length field: 170 The message is prefixed with a two byte length field which gives 171 the message length, excluding the two byte length field. 173 [RFC1035] section 4.1.1 represents the DNS message header section, 174 which is the first part of the DNS message on the wire (after the 175 message length). 177 1 1 1 1 1 1 178 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 179 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 180 | ID | 181 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 182 |QR| Opcode |AA|TC|RD|RA| Z | RCODE | 183 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 184 | QDCOUNT | 185 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 186 | ANCOUNT | 187 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 188 | NSCOUNT | 189 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 190 | ARCOUNT | 191 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 193 So in a DNS over TCP stream, the interpretation of the initial 14 194 octets are fixed based on information about the first query sent on 195 the stream: 197 o 0,1: length of initial DNS message 199 o 2,3: DNS Transaction ID 201 o 4,5: DNS opcode, flags, and response code 203 o 6,7: Question count 205 o 8,9: Answer count 207 o 10,11: Authority count 209 o 12,13: Additional RR count 211 All DNS streams sent over TCP start with at least these 14 octets. 213 3.2. HTTP initial octets 215 In an HTTP stream, the first octets sent from the client are either 216 the so-called "Simple-Request" (for HTTP/0.9), the "Request-Line" 217 (for HTTP/1.0 and HTTP/1.1), which has variable characteristics, or 218 the "connection preface" (for HTTP/2) which is a fixed string. 220 Some servers may wish to ignore the oldest of these, HTTP/0.9. 222 3.2.1. HTTP/0.9 224 [RFC1945] section 4.1 says that HTTP/0.9 queries (that is, HTTP 225 queries from before HTTP/1.0 was formalized) use this form: 227 Simple-Request = "GET" SP Request-URI CRLF 229 Note that HTTP/0.9 clients send this string and only this string, 230 nothing else (no request body, no subsequent requests). The 231 "Request-URI" token is guaranteed to start with a printable ASCII 232 character, and cannot contain any members of the CTL class (values 233 0x00 through 0x1F) but due to loose early specifications, it might 234 sometimes contain high-valued octets (those with the most-significant 235 bit set - 0x80 or above). 237 So the first 5 octets are all constrained to be no less than 0x20 238 (SP) and no more than 0x7F (DEL), and all subsequent octets sent from 239 the client have a value at least 0x0A (LF). 241 The shortest possible HTTP/0.9 client request is: 243 char: G E T SP / CR LF 244 index: 0 1 2 3 4 5 6 246 The lowest possible HTTP/0.9 client request (sorted ASCIIbetically) 247 is: 249 char: G E T SP + : CR LF 250 index: 0 1 2 3 4 5 6 7 252 3.2.2. HTTP/1.0 and HTTP/1.1 254 The request line format for HTTP/1.1 matches that of HTTP/1.0 255 (HTTP/1.1 adds protocol features like pipelining, but doesn't change 256 the request form itself). But unlike HTTP/0.9, the initial verb (the 257 "method") can vary. 259 [RFC7230] section 3.1.1 says that the first line of an HTTP/1.1 260 request is: 262 request-line = method SP request-target SP HTTP-version CRLF 263 method = token 265 and [RFC7230] section 3.2.6 says: 267 token = 1*tchar 269 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 270 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 271 / DIGIT / ALPHA 272 ; any VCHAR, except delimiters 274 and VCHAR is defined in [RFC5234] appendix B.1 as: 276 VCHAR = %x21-7E 278 "request-target" itself cannot contain 0x20 (SP) or any CTL 279 characters, or any characters above the US-ASCII range (> 0x7F). 281 And the "HTTP-version" token is either the literal string "HTTP/1.0" 282 or the literal string "HTTP/1.1", both of which are constrained to 283 the same printable-ASCII range. 285 The ASCIIbetically-lowest shortest possible HTTP/1.0 or HTTP/1.1 286 request is: 288 char: ! SP / H T T P / 1 . 0 CR LF CR LF 289 index: 0 1 2 3 4 5 6 7 8 9 0 a b c d 291 In any case, no HTTP/1.0 or HTTP/1.1 request line can include any 292 values lower than 0x0A (LF) or greater than 0x7F (DEL) in the first 293 14 octets. 295 However, [RFC7230] section 3.1.1 also says: 297 In the interest of robustness, a server that is expecting to receive 298 and parse a request-line SHOULD ignore at least one empty line (CRLF) 299 received prior to the request-line. 301 So we should also consider accepting an arbitrary number of repeated 302 CRLF sequences before the request-line as a potentially-valid HTTP 303 client behavior. 305 3.2.3. HTTP/2 307 [RFC7540] section 3.5 says: 309 In HTTP/2, each endpoint is required to send a connection preface as 310 a final confirmation of the protocol in use and to establish the 311 initial settings for the HTTP/2 connection. The client and server 312 each send a different connection preface. 314 The client connection preface starts with a sequence of 24 octets, 315 which in hex notation is: 317 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a 319 That is, the connection preface starts with the string "PRI * 320 HTTP/2.0\r\n\r\nSM\r\n\r\n"). 322 The highest valued octet here is 0x54 ("T"), and the lowest is 0x0A 323 (LF). 325 4. Specific octets 327 The sections below examine likely values of specific octet positions 328 in the stream. All octet indexes are 0-based. 330 4.1. octets 0 and 1 332 Any DNS message less than 3338 octets sent as the initial query over 333 TCP can be reliably distinguished from any version of HTTP by the 334 first two octets of the TCP stream alone. 336 3338 is 0x0D0A, or the ASCII string CRLF, which some HTTP clients 337 might send before an initial request. No HTTP client can 338 legitimately send anything lower than this. 340 Most DNS queries are easily within this range automatically. 342 4.2. octets 2 and 3 344 In a DNS stream, octets 2 and 3 represent the client-chosen message 345 ID. The message ID is used to bind messages with responses. Over 346 connectionless transports like UDP, this is an important anti- 347 spoofing measure, as well as a distinguishing measure for clients 348 reusing the same UDP port for multiple outstanding queries. Standard 349 DNS clients already explicitly randomize this value. 351 For the connection-oriented streaming DNS discussed here, the anti- 352 spoofing characteristics are not relevant (the connection itself 353 provides anti-spoofing), so the client is free to choose arbitrary 354 values. 356 With a standard DNS client which fully-randomizes these values, only 357 25% of generated queries will have the high bits of both octets set 358 to 0. 100% of all HTTP requests will have the high bits of both of 359 these octets cleared. Similarly, some small percentage of randomly- 360 generated DNS queries will have values here lower than 0x0A, while no 361 HTTP clients will ever send these low values. 363 4.3. octet 4 365 In a DNS stream, octet 4 combines several fields: 367 0 1 2 3 4 5 6 7 368 +--+--+--+--+--+--+--+--+ 369 |QR| Opcode |AA|TC|RD| 370 +--+--+--+--+--+--+--+--+ 372 In a standard DNS query sent over a streaming interface, QR, Opcode, 373 AA, and TC are all set to 0. The least-significant bit (RD - 374 Recursion Desired) is set when a packet is sent from a stub to a 375 recursive resolver. The value of such an octet is 0x01. This value 376 never occurs in octet 4 of a legitimate HTTP client. 378 4.4. octet 5 380 In a DNS stream, octet 5 also combines several fields: 382 0 1 2 3 4 5 6 7 383 +--+--+--+--+--+--+--+--+ 384 |RA| Z | RCODE | 385 +--+--+--+--+--+--+--+--+ 387 In a standard DNS message sent from a client, all these bits are 0. 388 No legitimate HTTP client ever sends a value of 0x00 in octet 5. 390 4.5. octets 6 and 7 392 In DNS, octets 6 and 7 represent the query count. Most DNS clients 393 will send one query at a time, which makes this value 0x0001. As 394 long as the number of initial queries does not exceed 0x0A0A (2570), 395 then at least one of these octets will have a value less than 0x0A. 396 No HTTP client sends an octet less than 0x0A in positions 6 or 7. 398 4.6. octets 8 through 11 400 In streaming DNS, octets 8 through 11 represent answer counts and 401 authority counts. Standard DNS queries will set them both 0. No 402 HTTP client sends a zero-valued octet in these positions. 404 4.7. octets 12 and 13 406 In streaming DNS, octets 12 and 13 represent the number of Additional 407 RRs. When a DNS query is sent with EDNS(0), the OPT RR is accounted 408 for here. So this is often either 0x0000 or 0x0001. No HTTP client 409 will send these values at these positions. 411 5. Combinations of octets 413 In a DNS message, each Question in the Question section is at least 5 414 octets (1 octet for zero-length QNAME + 2 octets for QTYPE + 2 octets 415 for QCLASS), and each RR (in the Answer, Authority, and Additional 416 sections) is at least 11 octets. And the header itself is 12 octets. 418 So we know that for a valid DNS stream, the first message has a size 419 of at least: 421 min_first_msg_size = 12 + 5 * (256*o[6] + o[7]) + 422 11 * (256*(o[8] + o[10] + o[12]) + 423 o[9] + o[11] + o[13]) 425 It's possible to compare this value with the expected first query 426 size: 428 first_msg_size = 256 * o[0] + o[1] 430 if "first_query_size" is less than "min_first_query_size" we can be 431 confident that the stream is not DNS. 433 5.1. Proof: a valid DNS message cannot be an HTTP query 435 For any a valid, stream-based DNS message: 437 o If there are fewer than 0x0A00 Questions then octet 6 < 0x0A. 439 o If there are fewer than 0x0A00 Answer RRs, then octet 8 < 0x0A. 441 o If there are fewer than 0x0A00 Authority RRs, then octet 10 < 442 0x0A. 444 o If there are fewer than 0x0A00 Additional RRs, then octet 12 < 445 0x0A. 447 If any of these four inequalities hold, then the packet is clearly 448 DNS, not HTTP. 450 if none of them hold, then there are at least 0x0A00 (2560) Questions 451 and 3*2560 == 7680 RRs. But: 453 12 + 5*2560 + 11*7680 == 97292 455 So the smallest possible DNS message where none of these four 456 inequalites hold is 97292 octets. But a DNS message is limited in 457 size to 65535 octets. 459 Therefore at least one of these inequalities holds, and one of the 460 first 14 octets of a DNS steam is < 0x0A. 462 But in a standard HTTP request, none of the first 14 octets can have 463 a value < 0x0A, so a valid DNS message cannot be mistaken for an HTTP 464 request. 466 6. Guidance for Demultiplexing Servers 468 Upon receiving a connection stream that might be either DNS or HTTP, 469 a server can inspect the initial octets of the stream to decide where 470 to send it. 472 6.1. Without supporting HTTP/0.9 474 A server that doesn't care about HTTP/0.9 can simply wait for the 475 first 14 octets of the client's request to come in. Then the 476 algorithm is: 478 bytestream = read_from_client(14) 479 for x in bytestream: 480 if (x < 0x0A) or (x > 0x7F): 481 return `DNS` 482 return `HTTP` 484 6.2. Supporting archaic HTTP/0.9 clients 486 A server that decides to try to support HTTP/0.9 clients has a 487 slightly more challenging task, since some of them may send fewer 488 octets than the initial DNS message, and the server shouldn't block 489 waiting for data that will never come. 491 bytestream = read_from_client(5) 492 for x in bytestream[0:5] 493 if (x < 0x0A) or (x > 0x7F): 494 return `DNS` 495 if (bytestream[0:4] != 'GET '): # not HTTP/0.9 496 bytestream += read_from_client(9) 497 for x in bytestream[5:14]: 498 if (x < 0x0A) or (x > 0x7f): 499 return `DNS` 500 return `HTTP` 501 else: # maybe HTTP/0.9 502 seen_sp = False 503 seen_high = False 504 while (len(bytestream) < 14): 505 if (seen_sp and seen_high): 506 return `DNS` 507 x = read_from_client(1) 508 bytestream += x 509 if (x > 0x7F): 510 seen_high = True 511 elif (x < 0x0A): 512 return `DNS` 513 elif (x == 0x20): 514 seen_sp = True # SP found before CRLF, not HTTP/0.9 515 elif (x == 0x0A): 516 return `HTTP` 517 return `HTTP` 519 Note that if read_from_client() ever fails to read the number of 520 requested bytes (e.g. because of EOF), then the stream is neither 521 valid HTTP nor valid DNS, and can be discarded. 523 6.3. Signaling demultiplexing capacity 525 FIXME: should there be a way for a listener to signal somehow that it 526 is willing and capable of handling both DNS and HTTP traffic? There 527 would need to be a different signaling mechanism for each stream 528 (unless the signalling is done somehow in an outer layer like TLS). 529 This is probably out-of-scope for this draft. 531 7. Guidance for DNS clients 533 Consider a DNS client that connects to a server that might be 534 interested in answering HTTP requests on the same address/port (or 535 other channel identifier). The client wants to send traffic that is 536 unambiguously DNS traffic to make it easy for the server to 537 distinguish it from inbound HTTP requests. Fortunately, this is 538 trivial to do. 540 Such a client should follow these guidelines: 542 o Send the DNS message size (a 16-bit integer) together in the same 543 packet with the full header of the first DNS message so that the 544 recipient can review as much as possible of the frame at once. 545 This is a best practice for efficient stream-based DNS anyway. 547 If the client is concerned about stream fragmentation that it cannot 548 control, and it is talking to a server that might be expecting 549 HTTP/0.9 clients, then the server might not be willing to wait for 550 the full initial 14 octets to make a decision. 552 Note that this fragmentation is not a concern for streams wrapped in 553 TLS when using modern AEAD ciphersuites. In this case, the client 554 gets to choose the size of the plaintext record, which is either 555 recovered by the server in full (unfragmented) or the connection 556 fails. 558 If the client does not have such a guarantee from the transport, it 559 MAY also take one of the following mitigating actions relating to the 560 first DNS message it sends in the stream [explanation of what the 561 server gets to see in the fragmented stream case are in square 562 brackets after each mitigation]: 564 o Ensure the first message is marked as a query (QR = 0), and it 565 uses opcode 0 ("Standard Query"). [bytestream[4] < 0x08] 567 o Ensure that the first message has RA = 0, Z = 0, and RCODE = 0. 568 [bytestream[5] == 0x00] 570 o Ensure that the high bit of the first octet of the message ID of 571 the first message is set. [bytesteam[2] > 0x7F] 573 o Send an initial short Server Status DNS message ahead of the 574 otherwise intended initial DNS message. [bytstream[0] == 0x00] 576 o Use the EDNS(0) padding option [RFC7830] to pad the first message 577 to a multiple of 256 octets. [bytestream[1] == 0x00] 579 7.1. Interpreting failure 581 FIXME: A DNS client that does not already know that a server is 582 willing to carry both types of traffic SHOULD expect a transport 583 connection failure of some sort. Can we say something specific about 584 what it should expect? 586 8. Guidance for HTTP clients 588 HTTP clients SHOULD NOT send HTTP/0.9 requests, since modern HTTP 589 servers are not required to support HTTP/0.9. Sending an HTTP/1.0 590 request (or any later version) is sufficient for a server to be able 591 to distinguish the two protocols. 593 9. Security Considerations 595 FIXME: Clients should locally validate DNSSEC (servers may still be 596 able to omit some records) 598 FIXME: if widely deployed, consider amplification for DDoS against 599 authoritative servers? 601 FIXME: consider dnssec transparency 603 FIXME: consider TLS session resumption - this counts as a new stream 604 boundary, so the multiplexing decision need not persist across 605 resumption. 607 FIXME: consider 0-RTT 609 FIXME: consider X.509 cert validation 611 FIXME: what other security considerations should clients take? 613 FIXME: what other security considerations should servers take? 615 10. Privacy Considerations 617 FIXME: DNS queries and HTTP requests can reveal potentially sensitive 618 information about the sender. 620 FIXME: consider DNS and HTTP traffic analysis - how should requests 621 or responses be padded, aggregated, or delayed given that streams are 622 multiplexed? 624 FIXME: any other privacy considerations? 626 11. IANA Considerations 628 This document does not ask IANA to make any changes to existing 629 registries. 631 12. Document Considerations 633 [ RFC Editor: please remove this section before publication ] 635 This document is currently edited as markdown. Minor editorial 636 changes can be suggested via merge requests at 637 https://gitlab.com/dkg/hddemux or by e-mail to the author. Please 638 direct all significant commentary to the public IETF DNS Privacy 639 mailing list: dns-privacy@ietf.org 641 13. References 643 13.1. Normative References 645 [RFC1035] Mockapetris, P., "Domain names - implementation and 646 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 647 November 1987, . 649 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 650 Transfer Protocol -- HTTP/1.0", RFC 1945, 651 DOI 10.17487/RFC1945, May 1996, 652 . 654 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 655 Specifications: ABNF", STD 68, RFC 5234, 656 DOI 10.17487/RFC5234, January 2008, 657 . 659 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 660 Protocol (HTTP/1.1): Message Syntax and Routing", 661 RFC 7230, DOI 10.17487/RFC7230, June 2014, 662 . 664 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 665 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 666 DOI 10.17487/RFC7540, May 2015, 667 . 669 13.2. Informative References 671 [I-D.ietf-dnsop-dns-wireformat-http] 672 Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire- 673 format over HTTP", draft-ietf-dnsop-dns-wireformat-http-01 674 (work in progress), March 2017. 676 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 677 (TLS) Protocol Version 1.2", RFC 5246, 678 DOI 10.17487/RFC5246, August 2008, 679 . 681 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 682 "Transport Layer Security (TLS) Application-Layer Protocol 683 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 684 July 2014, . 686 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 687 DOI 10.17487/RFC7830, May 2016, 688 . 690 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 691 and P. Hoffman, "Specification for DNS over Transport 692 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 693 2016, . 695 Author's Address 697 Daniel Kahn Gillmor 698 American Civil Liberties Union 699 125 Broad St. 700 New York, NY 10004 701 USA 703 Email: dkg@fifthhorseman.net