idnits 2.17.1 draft-hoffman-dns-in-existing-http2-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 130: '... DNS frames MAY also contain padding...' RFC 2119 keyword, line 164: '... DNS frames MUST be associated with ...' RFC 2119 keyword, line 165: '...ifier field is 0x0, the recipient MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 10, 2017) is 2566 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Intended status: Standards Track April 10, 2017 5 Expires: October 12, 2017 7 Running DNS in Existing HTTP/2 Connections 8 draft-hoffman-dns-in-existing-http2-00 10 Abstract 12 Intermediaries such as governments and ISPs spoof DNS responses, and 13 block DNS requests to particular recursive resolvers, for a variety 14 of reasons. They spoof by capturing traffic on port 53, or by 15 redirecting port 853 traffic in the hopes that the client is using 16 opportunistic encryption. They block if they know the address of a 17 resolver that they don't like, such as public resolvers that give 18 honest answers. 20 This document describes how to run DNS service over existing HTTP/2 21 connections over TLS, such as those being used for HTTP for basic web 22 service. This design prevents intermediaries from spoofing DNS 23 responses, and makes it impossible for intermediaries to block the 24 use of those recursive resolvers without blocking the desired HTTP 25 connections. It also prevents intermediaries or passive observers 26 from seeing the DNS traffic. This design is meant for communication 27 between a DNS stub resolver and a DNS recursive resolver. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 12, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. DNS in Existing HTTP/2 over TLS Connections . . . . . . . . . 3 65 2.1. HTTP/2 DNS Frame Definition . . . . . . . . . . . . . . . 3 66 2.2. Service Discovery . . . . . . . . . . . . . . . . . . . . 4 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 5.2. Informative References . . . . . . . . . . . . . . . . . 5 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1. Introduction 76 HTTP/2 [RFC7540] over TLS is now used widely by many web sites. 77 Large web sites who care about good DNS resolution service (that is, 78 DNS resolution that is not subject to getting wrong answers from 79 intermediaries) might want to offer DNS resolution on the same 80 servers as those running HTTP/2 over TLS. Running DNS over existing 81 HTTP/2 over TLS connection prevents intermediaries from spoofing DNS 82 responses, and makes it impossible for intermediaries to block the 83 use of those recursive resolvers without blocking the desired HTTP 84 connections. 86 This document covers only the use case of getting DNS service once a 87 HTTP/2 over TLS connection is already set up. That means that the 88 user already has some DNS service before getting to the DNS resolver 89 that is running in the existing HTTP/2 connection. That original DNS 90 service might be standard DNS running on port 53 ([RFC1035]), or DNS- 91 in-TLS running on port 853 ([RFC7858]), or even DNS in its own HTTP/2 92 over TLS connection that could be defined in the future. Regardless, 93 this document is describing a second DNS service for the user, one 94 that was bootstrapped by running DNS in a way that might have been 95 spoofed by an intermediary. 97 A beneficial effect of using DNS over existing HTTP/2 over TLS 98 connections after using DNS over port 53 is that the DNS messages are 99 then encrypted. 101 A parallel document, [draft-hoffman-dns-in-existing-quic], covers 102 approximately the same use cases as this one, but describes how to 103 carry DNS in QUIC streams. 105 2. DNS in Existing HTTP/2 over TLS Connections 107 **** This section, which is the meat of the protocol, is completely 108 tentative. People might have strong opinions on how to best run DNS 109 over HTTP/2. The choice of using a new frame is an early guess for a 110 protocol that meets the desing objectives given above; the HTTPBIS WG 111 might have (much) better alternatives. For example, reserved streams 112 might be a better idea than a new type of frame. **** 114 This document defines a new type of HTTP/2 frame, "DNS". 116 DNS in HTTP/2 is run as a stream of DNS frames. The DNS stub 117 resolver opens an HTTP/2 stream if it is not already open. The stub 118 resolver then sends DNS wire-format requests ([RFC1035]), and the 119 recursive resolver sends wire-format requests in the same stream. 120 The wire format used is that for DNS over UDP (not with the extra 121 two-octet header defined in [RFC1035] for TCP). Either side can 122 close the HTTP/2 stream for DNS whenever they wish. 124 2.1. HTTP/2 DNS Frame Definition 126 DNS frames (type=0xTBD) convey variable-length sequences of octets 127 associated with a DNS message. One or more DNS frames are used, for 128 instance, to carry a DNS request or response payload. 130 DNS frames MAY also contain padding. Padding can be added to DNS 131 frames to obscure the size of messages. Padding is a security 132 feature; see Section 4. 134 The format of the DNS frame is: 136 +---------------+ 137 |Pad Length? (8)| 138 +---------------+-----------------------------------------------+ 139 | DNS message (*) ... 140 +---------------------------------------------------------------+ 141 | Padding (*) ... 142 +---------------------------------------------------------------+ 144 Figure 1: DNS frame format 146 The DNS frame contains the following fields: 148 Pad Length: An 8-bit field containing the length of the frame 149 padding in units of octets. This field is conditional (as 150 signified by a "?" in the diagram) and is only present if the 151 PADDED flag is set for the frame. 153 DNS message: The wire-format of the message. The wire format used 154 is that for DNS over UDP (not with the extra two-octet header 155 defined in [RFC1035] for TCP). 157 Padding: Padding octets that contain no application semantic value. 158 This is handled identically to padding in the DATA frame in 159 [RFC7540]. 161 The DNS frame uses the END_STREAM and PADDED frame flags, identically 162 to the DATA frame in [RFC7540]. 164 DNS frames MUST be associated with a stream. If a DNS frame is 165 received whose stream identifier field is 0x0, the recipient MUST 166 respond with a connection error of type PROTOCOL_ERROR. 168 DNS frames are subject to flow control identical to the DATA frame in 169 [RFC7540]. 171 2.2. Service Discovery 173 The DNS stub resolver discovers whether the HTTP/2 server with the 174 exisiting connection supports DNS resolution by attempting to open a 175 DNS stream in the HTTP/2 connection. Because opening a HTTP/2 stream 176 requires sending protocol data, the stub resolver needs to pick a DNS 177 request to use as a probe for DNS resolution service. The stub 178 resolver might send a request for data it actually wants, or it could 179 send a request that it does not care about, such as the A record for 180 example.com. 182 3. IANA Considerations 184 This section will eventually have a request to assign a new value, 185 TBD, to the "HTTP/2 Frame Type" registry. 187 4. Security Considerations 189 Running DNS over existing HTTP/2 over TLS connections relies on the 190 security of the TLS connections themselves. 192 A beneficial effect of using DNS over existing HTTP/2 over TLS 193 connections after using DNS over port 53 is that the DNS messages are 194 then encrypted. 196 *** Copy some text about the uses (and abuses) of padding from 197 Section 10.7 of RFC 7540 here. *** 199 5. References 201 5.1. Normative References 203 [RFC1035] Mockapetris, P., "Domain names - implementation and 204 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 205 November 1987, . 207 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 208 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 209 DOI 10.17487/RFC7540, May 2015, 210 . 212 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 213 and P. Hoffman, "Specification for DNS over Transport 214 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 215 2016, . 217 5.2. Informative References 219 [draft-hoffman-dns-in-existing-quic] 220 Hoffman, P., "Running DNS in Existing QUIC Connections", 221 2017, . 224 Author's Address 226 Paul Hoffman 227 ICANN 229 Email: paul.hoffman@icann.org