idnits 2.17.1 draft-bortzmeyer-dprive-step-2-03.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. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 22, 2016) is 2712 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 398 == Outdated reference: A later version (-11) exists of draft-ietf-dprive-dtls-and-tls-profiles-07 -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 == Outdated reference: A later version (-07) exists of draft-ietf-tls-dnssec-chain-extension-01 == Outdated reference: A later version (-15) exists of draft-ietf-dprive-dnsodtls-12 Summary: 1 error (**), 0 flaws (~~), 6 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 November 22, 2016 5 Expires: May 26, 2017 7 Next step for DPRIVE: resolver-to-auth link 8 draft-bortzmeyer-dprive-step-2-03 10 Abstract 12 This document examines the possible future work for the DPRIVE (DNS 13 privacy) working group, specially in securing the resolver-to- 14 authoritative name server link with TLS under DNS. 16 It is not intended to be published as a RFC. 18 REMOVE BEFORE PUBLICATION: this document should be discussed in the 19 IETF DPRIVE group, through its mailing list. The source of the 20 document, as well as a list of open issues, is currently kept at 21 Github [1]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 26, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and background . . . . . . . . . . . . . . . . . 2 58 2. TLS or not TLS . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Possible solutions . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Encode key in name . . . . . . . . . . . . . . . . . . . 4 61 3.2. Key in DNS . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.4. "reverse" DNS . . . . . . . . . . . . . . . . . . . . . . 5 64 3.5. CGA . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.6. Lax security . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . 7 73 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction and background 78 To improve the privacy of the DNS user ([RFC7626]), the standard 79 solution is to encrypt the requests with TLS ([RFC7858]). Just 80 encrypting, without authenticating the remote server, leaves the 81 user's privacy vulnerable to active man-in-the-middle attacks. 82 [RFC7858] and [I-D.ietf-dprive-dtls-and-tls-profiles] describe how to 83 authenticate the DNS resolver, in the stub-to-resolver link. We have 84 currently no standard way to authenticate the authoritative name 85 server, in the resolver-to-auth link. 87 The two cases are quite different: a stub resolver has only a few 88 resolvers, and there is typically a pre-existing relationship. But a 89 resolver speaks to many authoritative name servers, without any prior 90 relationship. This means that, for instance, having a static key for 91 the resolver makes sense while it would be clearly unrealistic for 92 the authoritative server. 94 Another difference is that resolvers are typically known by IP 95 address (obtained by DHCP or manual configuration) while 96 authoritative name servers are known by name (obtained from zone 97 delegation). This makes things easier for techniques similar to 98 DANE: the manager of the ns1.example.net name server can always add a 99 TLSA record under example.net while she may have problems modifying 100 the zone under in-addr.arpa or ip6.arpa. 102 Note that, despite the fact that resolvers are in general configured 103 by IP address, [I-D.ietf-dprive-dtls-and-tls-profiles] does not use 104 it. It describes several techniques to get the domain name of the 105 resolver, and authenticates using this name. 107 (On the other hand, the resolver knows also the IP address of the 108 authoritative server, so it can authenticate based on this, the 109 fourth and fifth solutions in Section 3.) 111 A third difference between the stub-to-resolver and resolver-to-auth 112 links is that, in the second case, it is more difficult to report 113 authentication problems to the end-user. (For better or for worse, 114 the DNS is not end-to-end.) 116 The original charter of the DPRIVE working group, in force at the 117 time of this draft, says "The primary focus of this Working Group is 118 to develop mechanisms that provide confidentiality between DNS 119 Clients and Iterative Resolvers" and adds "but it may also later 120 consider mechanisms that provide confidentiality between Iterative 121 Resolvers and Authoritative Servers". This document is here for this 122 second step, "between Iterative Resolvers and Authoritative Servers". 123 It will probably require a rechartering of the group. 125 2. TLS or not TLS 127 At first glance, the obvious protocol choice for encrypting the 128 resolver-to-auth link is to use DNS over TLS or DTLS ([RFC7858], 129 [I-D.ietf-dprive-dnsodtls]): 131 Already standardised 133 Relies on a well-know security protocol (and inventing a new 134 security protocol is quite dangerous) 136 On the other hand, the DNS has some special properties. While a stub 137 resolver talks to only a few few resolvers (and therefore can afford 138 a few TCP+TLS connections), a resolver may hesitate in front of the 139 task of managing hundreds of connections to remote authoritative 140 servers. Some may think that a specially-designed protocol like 141 [I-D.krecicki-dprive-dnsenc] is better. 143 If we choose TLS, we may require a minimum version of 1.3. TLS 1.3 144 [I-D.ietf-tls-tls13] will probably be standardised before this 145 document, and, specially combined with TCP Fast Open [RFC7413], it 146 promises a minimum latency when contacting a new server. 148 3. Possible solutions 150 We can express the problem this way: if we want to use TLS-over-DNS 151 to secure the link between the resolver and the authoritative server, 152 it would be important to have a standard way to authenticate the 153 authoritative server. Basically, the client will get the public key 154 of the server in the TLS session, how will it know that this key is 155 the right one? 157 Here is a comprehensive list of the six possible solutions to this 158 problem. First, the two where the key (or a hash of it) is available 159 somewhere else than in the TLS session. 161 3.1. Encode key in name 163 We could encode the key in the authoritative server name (as in 164 DNScurve [dnscurve] [I-D.dempsky-dnscurve]). Here is an example of a 165 domain using DNScurve: the names of the authoritative name servers 166 are a Base-32 encoded form of the server's Curve25519 public key. 168 % dig +short NS yp.to 169 uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to. 170 uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to. 171 uz5uu2c7j228ujjccp3ustnfmr4pgcg5ylvt16kmd0qzw7bbjgd5xq.ns.yp.to. 173 Securely transmitting the key would therefore be a by-product of 174 delegation. Among the limits of this solution, the length of these 175 names limit the number of possible name servers, if we want to keep 176 the delegation short. Also, it requires a cryptographic algorithm 177 where keys are short (which means no RSA). 179 If we want to add cryptographic agility to this solution, we will 180 need a few bytes before the key itself, to indicate, for instance, 181 the algorithm it uses. It will reduce the possible key size even 182 more. 184 3.2. Key in DNS 186 We could publish keys in the DNS, secured with DNSSEC (as in DANE 187 [RFC6698]). This raises an interesting bootstrap problem: we need 188 the key to get information privately with the DNS but we need the DNS 189 to do so. A possible solution is to have an "unsecure" mode to 190 retrieve the initial key material. The algorithm could be: 192 (0)The resolver remembers the keys of the authoritative name 193 servers (in the same way it remembers the lowest RTT among a NS 194 RRset), 196 (1)When the resolver needs to talk to a server (say 197 ns1.example.net) for which it does not know the key, it does a 198 TLSA request for _853._tcp.ns1.example.net, 200 (2)If the resolution of this request requires to talk to the very 201 server we search the key for, the resolver connects to this server 202 with TLS to port 853, does not authenticate, and sends the query. 203 This step offers no authentication ("opportunistic"?). 205 (See also [I-D.ietf-dprive-dtls-and-tls-profiles], section 9.2.) The 206 real algorithm will need to be more complicated since there are 207 several servers per zone. A resolver may use the knowledge of TLS 208 authentication it has to choose an authoritative name server among a 209 NS RRset. 211 Another solution is for the authoritative name server to use 212 [I-D.ietf-tls-dnssec-chain-extension] to send all the necessary 213 DNSSEC records over TLS. 215 3.3. PKIX 217 We could use the X.509 security model [RFC5280]). The certificates 218 for authoritative name servers would be signed by regular CAs, with 219 the name of the server in the Subject Alternative Name (or may be its 220 IP address in this field, but, as far as the author knows, few CAs 221 issue certificates for IP addresses). 223 One of the problems is that resolvers will probably have different 224 sets of trusted CA so an authoritative name server will not know in 225 advance what percentage of the resolvers may authenticate it. 227 Of course, this technique would not work if the server used raw 228 public keys ([RFC7250]. 230 3.4. "reverse" DNS 232 The resolver could start from the IP address of the authoritative 233 name server, and get a key from the name in the in-addr.arpa or 234 ip6.arpa zone. For instance, if the authoritative server will be 235 queried at 2001:db8:42:cafe::1:53, the request will be done for 3.5.0 236 .0.1.0.0.0.0.0.0.0.0.0.0.0.e.f.a.c.2.4.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 238 There is also a boostrapping problem here too, but since there are 239 only five RIR that manage the reverse DNS some sort of hard-coded or 240 semi-hard-coded setup might be possible. 242 Unfortunately the operators for the space are often different from 243 the operators of the DNS, so this is often not a reasonable solution 244 administratively. 246 3.5. CGA 248 Another solution starting from the IP address of the authoritative 249 name server would be to use CGA ([RFC3972]). The IPv6 address 250 encodes the public key in the lower 64-bits of the address. So we 251 could use the IPv6 address as the public key of the servers. 253 This only works for IPv6, doesn't have (much) cryptographic agility, 254 and raises serious layering violation issues. 256 3.6. Lax security 258 Finally, we could simply not check the keys at all, accepting 259 anything. This would break privacy promises, when there is an active 260 attacker, able to pose as the authoritative name server. But it is 261 still better, privacy-wise, than the current situation where DNS 262 requests are sent in clear text. 264 4. Miscellaneous 266 A resolver may use a combination of these solutions. For instance, 267 trying PKIX authentication (it does not require an extra lookup, 268 except may be OCSP), if it fails, search a TLSA record, if there is 269 none, depending on the resolver's policy, accept anyway. Clearly, 270 trying all six solutions is unrealistic so some guidance on how to 271 combine them will be necessary. 273 Trying the various solutions in sequence may seriously increase the 274 latency, specially if there are timeouts involved. Using parallel 275 attemps ("happy eyeballs", [RFC6555]) seem therefore crucial. 277 All these solutions can be improved by things like automatic key 278 pinning ([RFC6797]). 280 An authoritative name server cannot know if the resolver authentified 281 it, and how. In the future, it may be interesting to have a EDNS 282 option to signal a successful authentication, or a failure, but this 283 is out of scope currently. 285 If it is a concern that the same authoritative name servers are used 286 for ordinary DNS and for encrypted DNS, there are several solutions. 287 We may use front-end systems dispatching requests to port 53 and 853 288 to different servers. Or we may introduce a new delegation RR type, 289 PNS (for Privacy Name Server), located only in the child zone (to 290 avoid depending on a change of the provisioning software in the 291 parent). 293 5. IANA Considerations 295 There is currently nothing to do for IANA. The future chosen 296 solution may require some IANA action, such as a registry. 298 6. Security Considerations 300 For the time being, refer to each subsection under Section 3 to have 301 an analysis of its security. 303 A general problem with all (or most?) encryption protocols will be 304 the state to be kept in the server. It may make some denial-of- 305 service attacks easier, of the protocol is not properly designed. 307 7. Acknowledgments 309 Shane Kerr for the ideas on authentication by IP address. 311 8. References 313 8.1. Normative References 315 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 316 and P. Hoffman, "Specification for DNS over Transport 317 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 318 2016, . 320 [I-D.ietf-dprive-dtls-and-tls-profiles] 321 Dickinson, S., Gillmor, D., and T. Reddy, "Authentication 322 and (D)TLS Profile for DNS-over-(D)TLS", draft-ietf- 323 dprive-dtls-and-tls-profiles-07 (work in progress), 324 October 2016. 326 8.2. Informative References 328 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 329 RFC 3972, DOI 10.17487/RFC3972, March 2005, 330 . 332 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 333 Housley, R., and W. Polk, "Internet X.509 Public Key 334 Infrastructure Certificate and Certificate Revocation List 335 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 336 . 338 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 339 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 340 2012, . 342 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 343 of Named Entities (DANE) Transport Layer Security (TLS) 344 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 345 2012, . 347 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 348 Transport Security (HSTS)", RFC 6797, 349 DOI 10.17487/RFC6797, November 2012, 350 . 352 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 353 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 354 Transport Layer Security (TLS) and Datagram Transport 355 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 356 June 2014, . 358 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 359 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 360 . 362 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 363 DOI 10.17487/RFC7626, August 2015, 364 . 366 [I-D.dempsky-dnscurve] 367 Dempsky, M., "DNSCurve: Link-Level Security for the Domain 368 Name System", draft-dempsky-dnscurve-01 (work in 369 progress), February 2010. 371 [I-D.krecicki-dprive-dnsenc] 372 Krecicki, W., "Stateless DNS Encryption", draft-krecicki- 373 dprive-dnsenc-01 (work in progress), October 2015. 375 [I-D.ietf-tls-tls13] 376 Rescorla, E., "The Transport Layer Security (TLS) Protocol 377 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 378 October 2016. 380 [I-D.ietf-tls-dnssec-chain-extension] 381 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 382 Record and DNSSEC Authentication Chain Extension for TLS", 383 draft-ietf-tls-dnssec-chain-extension-01 (work in 384 progress), July 2016. 386 [I-D.ietf-dprive-dnsodtls] 387 Reddy, T., Wing, D., and P. Patil, "Specification for DNS 388 over Datagram Transport Layer Security (DTLS)", draft- 389 ietf-dprive-dnsodtls-12 (work in progress), September 390 2016. 392 [dnscurve] 393 Bernstein, D., "DNSCurve: Usable security for DNS", June 394 2009, . 396 8.3. URIs 398 [1] https://github.com/bortzmeyer/ietf-dprive-step-2 400 Author's Address 402 Stephane Bortzmeyer 403 AFNIC 404 1, rue Stephenson 405 Montigny-le-Bretonneux 78180 406 France 408 Phone: +33 1 39 30 83 46 409 Email: bortzmeyer+ietf@nic.fr 410 URI: http://www.afnic.fr/