idnits 2.17.1 draft-hoffman-dns-in-existing-quic-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 134: '... DNS frames MAY also contain padding...' RFC 2119 keyword, line 168: '... DNS frames MUST be associated with ...' RFC 2119 keyword, line 169: '...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 2573 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) == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 QUIC Connections 8 draft-hoffman-dns-in-existing-quic-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 QUIC 21 connections, such as those being used for HTTP for basic web service. 22 This design prevents intermediaries from spoofing DNS responses, and 23 makes it impossible for intermediaries to block the use of those 24 recursive resolvers without blocking the desired HTTP connections. 25 It also prevents intermediaries or passive observers from seeing the 26 DNS traffic. This design is meant for communication between a DNS 27 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 QUIC Connections . . . . . . . . . . . . . . 3 65 2.1. QUIC 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 It is expected that, in the not-distant future, Internet users will 77 be running QUIC [I-D.ietf-quic-transport] for basic web service to 78 many web sites. Large web sites who care about good DNS resolution 79 service (that is, DNS resolution that is not subject to getting wrong 80 answers from intermediaries) might want to offer DNS resolution on 81 the same servers as those running HTTP over QUIC. Running DNS over 82 existing QUIC connection prevents intermediaries from spoofing DNS 83 responses, and makes it impossible for intermediaries to block the 84 use of those recursive resolvers without blocking the desired HTTP 85 connections. 87 This document covers only the use case of getting DNS service once a 88 QUIC connection is already set up. That means that the user already 89 has some DNS service before getting to the DNS resolver that is 90 running in the existing QUIC connection. That original DNS service 91 might be standard DNS running on port 53 ([RFC1035]), or DNS-in-TLS 92 running on port 853 ([RFC7858]), or even DNS in its own QUIC 93 connection that could be defined in the future. Regardless, this 94 document is describing a second DNS service for the user, one that 95 was bootstrapped by running DNS in a way that might have been spoofed 96 by an intermediary. 98 A beneficial effect of using DNS over existing QUIC connections after 99 using DNS over port 53 is that the DNS messages are then encrypted. 101 A parallel document, [draft-hoffman-dns-in-existing-http2], covers 102 approximately the same use cases as this one, but describes how to 103 carry DNS in HTTP/2 over TLS. A different parallel document, 104 [draft-huitema-quic-dnsoquic], covers a very different use case, 105 namely starting new individual QUIC connections in order to pass DNS 106 traffic. 108 2. DNS in Existing QUIC Connections 110 **** This section, which is the meat of the protocol, is completely 111 tentative. The choice of using a new frame is an early guess for a 112 protocol that meets the desing objectives given above; the QUIC WG 113 might have (much) better alternatives. For example, reserved streams 114 might be a better idea than a new type of frame. As 115 [I-D.ietf-quic-transport] matures, this section will become more 116 definitive. **** 118 This document defines a new type of QUIC frame, "DNS". 120 DNS in QUIC is run as a stream of DNS frames. The DNS stub resolver 121 opens an QUIC stream if it is not already open. The stub resolver 122 then sends DNS wire-format requests ([RFC1035]), and the recursive 123 resolver sends wire-format requests in the same stream. The wire 124 format used is that for DNS over UDP (not with the extra two-octet 125 header defined in [RFC1035] for TCP). Either side can close the QUIC 126 stream for DNS whenever they wish. 128 2.1. QUIC DNS Frame Definition 130 DNS frames (type=0xTBD) convey variable-length sequences of octets 131 associated with a DNS message. One or more DNS frames are used, for 132 instance, to carry a DNS request or response payload. 134 DNS frames MAY also contain padding. Padding can be added to DNS 135 frames to obscure the size of messages. Padding is a security 136 feature; see Section 4. 138 The format of the DNS frame is: 140 +---------------+ 141 |Pad Length? (8)| 142 +---------------+-----------------------------------------------+ 143 | DNS message (*) ... 144 +---------------------------------------------------------------+ 145 | Padding (*) ... 146 +---------------------------------------------------------------+ 148 Figure 1: DNS frame format 150 The DNS frame contains the following fields: 152 Pad Length: An 8-bit field containing the length of the frame 153 padding in units of octets. This field is conditional (as 154 signified by a "?" in the diagram) and is only present if the 155 PADDED flag is set for the frame. 157 DNS message: The wire-format of the message. The wire format used 158 is that for DNS over UDP (not with the extra two-octet header 159 defined in [RFC1035] for TCP). 161 Padding: Padding octets that contain no application semantic value. 162 This is handled identically to padding in the STREAM frame in 163 [I-D.ietf-quic-transport]. 165 The DNS frame uses the RST_STREAM and PADDED frame flags, identically 166 to the STREAM frame in [I-D.ietf-quic-transport]. 168 DNS frames MUST be associated with a stream. If a DNS frame is 169 received whose stream identifier field is 0x0, the recipient MUST 170 respond with a connection error of type PROTOCOL_ERROR. 172 DNS frames are subject to flow control identical to the STREAM frame 173 in [I-D.ietf-quic-transport]. 175 2.2. Service Discovery 177 The DNS stub resolver discovers whether the QUIC server with the 178 exisiting connection supports DNS resolution by attempting to open a 179 DNS stream in the QUIC connection. Because opening a QUIC stream 180 requires sending protocol data, the stub resolver needs to pick a DNS 181 request to use as a probe for DNS resolution service. The stub 182 resolver might send a request for data it actually wants, or it could 183 send a request that it does not care about, such as the A record for 184 example.com. 186 3. IANA Considerations 188 As this document gets closer to completion, this section will mostly 189 likely be filled in with an assignment from one or more QUIC-related 190 registries. 192 4. Security Considerations 194 Running DNS over existing QUIC connections relies on the security of 195 the QUIC connections themselves. 197 A beneficial effect of using DNS over existing QUIC connections after 198 using DNS over port 53 is that the DNS messages are then encrypted. 200 *** Copy some text about the uses (and abuses) of padding from 201 Section 10.7 of RFC 7540 here. *** 203 5. References 205 5.1. Normative References 207 [I-D.ietf-quic-transport] 208 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 209 and Secure Transport", draft-ietf-quic-transport-02 (work 210 in progress), March 2017. 212 [RFC1035] Mockapetris, P., "Domain names - implementation and 213 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 214 November 1987, . 216 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 217 and P. Hoffman, "Specification for DNS over Transport 218 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 219 2016, . 221 5.2. Informative References 223 [draft-hoffman-dns-in-existing-http2] 224 Hoffman, P., "Running DNS in Existing HTTP/2 Connections", 225 2017, . 228 [draft-huitema-quic-dnsoquic] 229 Huitema, C. and et. al, "Specification of DNS over QUIC", 230 2017, . 233 Author's Address 235 Paul Hoffman 236 ICANN 238 Email: paul.hoffman@icann.org