idnits 2.17.1 draft-bortzmeyer-dprive-resolver-to-auth-01.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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 117: '... Note that the server MAY use raw public keys ([RFC7250]) and so there...' RFC 2119 keyword, line 131: '... resolver MUST stop using this autho...' RFC 2119 keyword, line 133: '... MUST use the authoritative name ser...' RFC 2119 keyword, line 136: '... in strict mode, MAY use unsecure serv...' RFC 2119 keyword, line 153: '... resolver MAY use the knowledge of T...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 20, 2018) is 2228 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) -- Looks like a reference, but probably isn't: '1' on line 297 == Outdated reference: A later version (-07) exists of draft-ietf-tls-dnssec-chain-extension-06 == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-02 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-27 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Privacy (dprive) Working Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Intended status: Standards Track March 20, 2018 5 Expires: September 21, 2018 7 Encryption and authentication of the DNS resolver-to-authoritative 8 communication 9 draft-bortzmeyer-dprive-resolver-to-auth-01 11 Abstract 13 This document proposes a mechanism for securing (privacy-wise) the 14 communication between the DNS resolver and the authoritative name 15 server. 17 REMOVE BEFORE PUBLICATION: this document should be discussed in the 18 IETF DPRIVE group, through its mailing list. The source of the 19 document, as well as a list of open issues, is currently kept at 20 Github [1]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 21, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and background . . . . . . . . . . . . . . . . . 2 57 2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Operational considerations . . . . . . . . . . . . . . . . . 4 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 6.2. Informative References . . . . . . . . . . . . . . . . . 6 64 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 66 Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction and background 71 To improve the privacy of the DNS user ([RFC7626]), the standard 72 solution is to encrypt the requests with TLS ([RFC7858]). We use 73 this DNS-over-TLS solution as well here, since it is standardized, 74 already implemented in many programs, and relies on a well-known 75 security protocol (inventing a new security protocol is quite 76 dangerous). But just encrypting, without authenticating the remote 77 server, leaves the user's privacy vulnerable to active man-in-the- 78 middle attacks. [RFC7858] and 79 [I-D.ietf-dprive-dtls-and-tls-profiles] describe how to authenticate 80 the DNS resolver, in the stub-to-resolver link. We describe here 81 authentication of the authoritative name server, in the resolver-to- 82 authoritative link. 84 A stub DNS resolver has only a few resolvers, and there is typically 85 a pre-existing relationship. But a resolver speaks to many 86 authoritative name servers, without any prior relationship. This 87 means that, for instance, having a static key for the resolver makes 88 sense while it would be clearly unrealistic for the authoritative 89 server. 91 Instead, we rely on DANE ([RFC6698]). Authoritative name servers are 92 known by name (obtained from zone delegation). The manager of the 93 ns1.example.net name server adds a TLSA record under example.net. 94 The client establishes the TLS session, then authenticate in the 95 normal DANE way. 97 The original charter of the DPRIVE working group, in force at the 98 time of this draft, says "The primary focus of this Working Group is 99 to develop mechanisms that provide confidentiality between DNS 100 Clients and Iterative Resolvers" and adds "but it may also later 101 consider mechanisms that provide confidentiality between Iterative 102 Resolvers and Authoritative Servers". This document is here for this 103 second step, "between Iterative Resolvers and Authoritative Servers". 104 It will probably require a rechartering of the group. 106 2. Rules 108 A DNS full-service resolver who needs to query an authoritative name 109 server establishes a TLS-over-TCP session with this authoritative 110 name server. If the DNS material to perform DANE authentication is 111 sent in the TLS session ([I-D.ietf-tls-dnssec-chain-extension]), it 112 uses it. Otherwise, the resolver queries TLSA records ([RFC6698]) 113 for this name server and authenticates the key or certificate of the 114 server this way. If the name server is ns1.example.net, the TLSA 115 record to query is _853._tcp.ns1.example.net. 117 Note that the server MAY use raw public keys ([RFC7250]) and so there 118 is not always a certificate. If the server uses raw public keys, the 119 TLSA record's Selector field must be 1 (SPKI, SubjectPublicKeyInfo). 121 The recommended order is to try TLS before querying the TLSA records. 122 True, DANE signals if the server is willing to make DNS-over-TLS (and 123 can therefore save a TLS attempt) but cannot guarantee that it will 124 work (for instance if a middlebox blocks port 853). Also, the DANE 125 records may be transferred in the TLS session, not through the DNS. 127 If the TLS session establishement fails, or if the DANE 128 authentication fails, the result depends on whether the resolver runs 129 in strict or opportunistic mode 130 ([I-D.ietf-dprive-dtls-and-tls-profiles]). In strict mode, the 131 resolver MUST stop using this authoritative name server, and MUST try 132 other servers of the DNS zone. In opportunistic mode, the resolver 133 MUST use the authoritative name server despite the failure. It MAY 134 try other name servers of the zone before, in the hope they will 135 accept TLS and be authenticated. To avoid a chicken-and-egg problem, 136 the resolver, even in strict mode, MAY use unsecure servers for the 137 meta-queries (getting the TLSA records). More specifically: 139 (0)The resolver remembers the keys of the authoritative name 140 servers (in the same way it remembers the lowest RTT among an NS 141 RRset), 142 (1)When the resolver needs to talk to a server (say 143 ns2.example.net) for which it does not know the key, it does a 144 TLSA request for _853._tcp.ns2.example.net, 146 (2)If the resolution of this request requires that we talk to the 147 same server for which we're searching for the TLSA record, the 148 resolver connects to this server with TLS to port 853, does not 149 bother to authenticate, and sends the query. This step offers no 150 authentication. 152 (See also [I-D.ietf-dprive-dtls-and-tls-profiles], section 5.) A 153 resolver MAY use the knowledge of TLS authentication it has to choose 154 an authoritative name server among a NS RRset. 156 As of this revision, we do not expect resolvers to use strict mode, 157 since the encryption and authentication modes described in this 158 document are not yet supported in authoritative name servers. 160 3. Operational considerations 162 DNS-over-TLS depends on TCP, and the resolver and the authoritative 163 name server must therefore support persistent TCP connections 164 ([RFC7766], specially section 6.2.1). 166 A resolver may have a lot of client-side state, when managing 167 hundreds of connections to remote authoritative servers ([tdns]). 169 The latency when connecting to a authoritative name server is 170 certainly an issue. TLS 1.3 and TCP Fast Open ([RFC7413]) may help. 172 Open question: do we require a minimum TLS version of 1.3? 173 ([I-D.ietf-tls-tls13]) 175 Because the resolver cannot know in advance if the TLS connection 176 will work (even if there is a DANE record), using parallel attempts 177 ("happy eyeballs", [RFC8305]) is important. A resolver working in 178 opportunistic mode should try ports 53 and 853 in parallel. 180 An authoritative name server cannot know if the resolver 181 authenticated it, nor how. In the future, it may be interesting to 182 have an EDNS option to signal a successful authentication, or a 183 failure, but this is out of scope currently. 185 If it is a concern that the same authoritative name servers are used 186 for ordinary DNS and for encrypted DNS, there are several ways to 187 address this concern. A server operator may use front-end systems 188 dispatching requests to ports 53 and 853 to different servers. 190 A resolver must be configurable to operate in strict or opportunistic 191 modes. Until the features described herein are widely supported, 192 opportunistic mode should not be the default since strict mode would 193 yield frequent failures. A resolver may have a configuration 194 mechanism to be in strict mode only for some domains. 196 4. IANA Considerations 198 No action for IANA. This section can be deleted. 200 5. Security Considerations 202 The state to be kept in both the client and the server may make some 203 denial-of-service attacks easier. Following the advice contained in 204 section 10 of [RFC7766] is recommended. 206 In opportunistic mode, there is no guarantee to have a secure use of 207 the DNS, or even a guarantee to be informed of a problem. 208 Opportunistic mode is a "best effort" privacy service. Even in 209 strict mode, some leaks may occur, through the DANE meta-queries, and 210 through SNI indication ([I-D.ietf-tls-sni-encryption]) in the TLS 211 session. 213 Neither transport encryption nor authentication protect DNS users 214 from authentic servers which nonetheless abuse users' privacy once 215 they've received their queries. These techniques must therefore be 216 combined with data minimization techniques ([RFC7816]). 218 6. References 220 6.1. Normative References 222 [I-D.ietf-dprive-dtls-and-tls-profiles] 223 Dickinson, S., Gillmor, D., and T. Reddy, "Usage and 224 (D)TLS Profiles for DNS-over-(D)TLS", draft-ietf-dprive- 225 dtls-and-tls-profiles-11 (work in progress), September 226 2017. 228 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 229 of Named Entities (DANE) Transport Layer Security (TLS) 230 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 231 2012, . 233 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 234 and P. Hoffman, "Specification for DNS over Transport 235 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 236 2016, . 238 6.2. Informative References 240 [I-D.bortzmeyer-dprive-step-2] 241 Bortzmeyer, S., "Next step for DPRIVE: resolver-to-auth 242 link", draft-bortzmeyer-dprive-step-2-05 (work in 243 progress), December 2016. 245 [I-D.ietf-tls-dnssec-chain-extension] 246 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 247 Record and DNSSEC Authentication Chain Extension for TLS", 248 draft-ietf-tls-dnssec-chain-extension-06 (work in 249 progress), January 2018. 251 [I-D.ietf-tls-sni-encryption] 252 Huitema, C. and E. Rescorla, "SNI Encryption in TLS 253 Through Tunneling", draft-ietf-tls-sni-encryption-02 (work 254 in progress), March 2018. 256 [I-D.ietf-tls-tls13] 257 Rescorla, E., "The Transport Layer Security (TLS) Protocol 258 Version 1.3", draft-ietf-tls-tls13-27 (work in progress), 259 March 2018. 261 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 262 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 263 Transport Layer Security (TLS) and Datagram Transport 264 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 265 June 2014, . 267 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 268 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 269 . 271 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 272 DOI 10.17487/RFC7626, August 2015, 273 . 275 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 276 D. Wessels, "DNS Transport over TCP - Implementation 277 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 278 . 280 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 281 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 282 . 284 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 285 Better Connectivity Using Concurrency", RFC 8305, 286 DOI 10.17487/RFC8305, December 2017, 287 . 289 [tdns] Liang, Z., Wessels, D., Zi, H., Heidemann, J., Mankin, A., 290 and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve 291 Privacy and Security; USC/ISI Technical Report ISI-TR- 292 706", August 2014, 293 . 295 6.3. URIs 297 [1] https://github.com/bortzmeyer/ietf-dprive-step-2 299 Appendix A. Acknowledgments 301 Thanks to Bill Woodcock for a detailed review. 303 Appendix B. Alternatives 305 A number of other possible solutions to this problem may be found in 306 in [I-D.bortzmeyer-dprive-step-2]. 308 Author's Address 310 Stephane Bortzmeyer 311 AFNIC 312 1, rue Stephenson 313 Montigny-le-Bretonneux 78180 314 France 316 Phone: +33 1 39 30 83 46 317 Email: bortzmeyer+ietf@nic.fr 318 URI: http://www.afnic.fr/