idnits 2.17.1 draft-bortzmeyer-dprive-step-2-02.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 (August 23, 2016) is 2804 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 320 == Outdated reference: A later version (-11) exists of draft-ietf-dprive-dtls-and-tls-profiles-03 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) == Outdated reference: A later version (-07) exists of draft-ietf-tls-dnssec-chain-extension-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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 August 23, 2016 5 Expires: February 24, 2017 7 Next step for DPRIVE: resolver-to-auth link 8 draft-bortzmeyer-dprive-step-2-02 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 February 24, 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. Possible solutions . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Encode key in name . . . . . . . . . . . . . . . . . . . 3 60 2.2. Key in DNS . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.4. "reverse" DNS . . . . . . . . . . . . . . . . . . . . . . 5 63 2.5. CGA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.6. Lax security . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 7.2. Informative References . . . . . . . . . . . . . . . . . 6 72 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction and background 77 To improve the privacy of the DNS user ([RFC7626]), the standard 78 solution is to encrypt the requests with TLS ([RFC7858]). Just 79 encrypting, without authenticating the remote server, leaves the 80 user's privacy vulnerable to active man-in-the-middle attacks. 81 [RFC7858] and [I-D.ietf-dprive-dtls-and-tls-profiles] describe how to 82 authenticate the DNS resolver, in the stub-to-resolver link. We have 83 currently no standard way to authenticate the authoritative name 84 server, in the resolver-to-auth link. 86 The two cases are quite different: a stub resolver has only a few 87 resolvers, and there is typically a pre-existing relationship. But a 88 resolver speaks to many authoritative name servers, without any prior 89 relationship. This means that, for instance, having a static key for 90 the resolver makes sense while it would be clearly unrealistic for 91 the authoritative server. 93 Another difference is that resolvers are typically known by IP 94 address (obtained by DHCP or manual configuration) while 95 authoritative name servers are known by name (obtained from zone 96 delegation). This makes things easier for techniques similar to 97 DANE: the manager of the ns1.example.net name server can always add a 98 TLSA record under example.net while she may have problems modifying 99 the zone under in-addr.arpa or ip6.arpa. 101 (On the other hand, the resolver knows also the IP address of the 102 authoritative server, so it can authenticate based on this, the 103 fourth and fifth solutions in Section 2.) 105 The original charter of the DPRIVE working group, in force at the 106 time of this draft, says "The primary focus of this Working Group is 107 to develop mechanisms that provide confidentiality between DNS 108 Clients and Iterative Resolvers" and adds "but it may also later 109 consider mechanisms that provide confidentiality between Iterative 110 Resolvers and Authoritative Servers". This document is here for this 111 second step, "between Iterative Resolvers and Authoritative Servers". 112 It will probably require a rechartering of the group. 114 2. Possible solutions 116 We can express the problem this way: if we want to use TLS-over-DNS 117 to secure the link between the resolver and the authoritative server, 118 it would be important to have a standard way to authenticate the 119 authoritative server. Basically, the client will get the public key 120 of the server in the TLS session, how will it know that this key is 121 the right one? 123 Here is a comprehensive list of the six possible solutions to this 124 problem. First, the two where the key (or a hash of it) is available 125 somewhere else than in the TLS session. 127 2.1. Encode key in name 129 We could encode the key in the authoritative server name (as in 130 DNScurve [dnscurve] [I-D.dempsky-dnscurve]). Here is an example of a 131 domain using DNScurve: the names of the authoritative name servers 132 are a Base-32 encoded form of the server's Curve25519 public key. 134 % dig +short NS yp.to 135 uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to. 136 uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to. 137 uz5uu2c7j228ujjccp3ustnfmr4pgcg5ylvt16kmd0qzw7bbjgd5xq.ns.yp.to. 139 Securely transmitting the key would therefore be a by-product of 140 delegation. Among the limits of this solution, the length of these 141 names limit the number of possible name servers, if we want to keep 142 the delegation short. Also, it requires a cryptographic algorithm 143 where keys are short (which means no RSA). 145 2.2. Key in DNS 147 We could publish keys in the DNS, secured with DNSSEC (as in DANE 148 [RFC6698]). This raises an interesting bootstrap problem: we need 149 the key to get information privately with the DNS but we need the DNS 150 to do so. A possible solution is to have an "unsecure" mode to 151 retrieve the initial key material. The algorithm could be: 153 (0)The resolver remembers the keys of the authoritative name 154 servers (in the same way it remembers the lowest RTT among a NS 155 RRset), 157 (1)When the resolver needs to talk to a server (say 158 ns1.example.net) for which it does not know the key, it does a 159 TLSA request for _853._tcp.ns1.example.net, 161 (2)If the resolution of this request requires to talk to the very 162 server we search the key for, the resolver connects to this server 163 with TLS to port 853, does not authenticate, and sends the query. 164 This step offers no authentication ("opportunistic"?). 166 (See also [I-D.ietf-dprive-dtls-and-tls-profiles], section 9.2.) The 167 real algorithm will need to be more complicated since there are 168 several servers per zone. A resolver may use the knowledge of TLS 169 authentication it has to choose an authoritative name server among a 170 NS RRset. 172 Another solution is for the authoritative name server to use 173 [I-D.ietf-tls-dnssec-chain-extension] to send all the necessary 174 DNSSEC records over TLS. 176 2.3. PKIX 178 We could use the X.509 security model [RFC5280]). The certificates 179 for authoritative name servers would be signed by regular CAs, with 180 the name of the server in the Subject Alternative Name (or may be its 181 IP address in this field, but, as far as the author knows, few CAs 182 issue certificats for IP addresses). 184 One of the problems is that resolvers will probably have different 185 sets of trusted CA so an authoritative name server will not know in 186 advance what percentage of the resolvers may authenticate it. 188 Of course, this technique would not work if the server used raw 189 public keys ([RFC7250]. 191 2.4. "reverse" DNS 193 The resolver could start from the IP address of the authoritative 194 name server, and get a key from the name in the in-addr.arpa or 195 ip6.arpa zone. For instance, if the authoritative server will be 196 queried at 2001:db8:42:cafe::1:53, the request will be done for 3.5.0 197 .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. 199 There is also a boostrapping problem here too, but since there are 200 only five RIR that manage the reverse DNS some sort of hard-coded or 201 semi-hard-coded setup might be possible. 203 Unfortunately the operators for the space are often different from 204 the operators of the DNS, so this is often not a reasonable solution 205 administratively. 207 2.5. CGA 209 Another solution starting from the IP address of the authoritative 210 name server would be to use CGA ([RFC3972]). The IPv6 address 211 encodes the public key in the lower 64-bits of the address. So we 212 could use the IPv6 address as the public key of the servers. 214 This only works for IPv6, doesn't have (much) cryptographic agility, 215 and raises serious layering violation issues. 217 2.6. Lax security 219 Finally, we could simply not check the keys at all, accepting 220 anything. This would break privacy promises, when there is an active 221 attacker, able to pose as the authoritative name server. But it is 222 still better, privacy-wise, than the current situation where DNS 223 requests are sent in clear text. 225 3. Miscellaneous 227 A resolver may use a combination of these solutions. For instance, 228 trying PKIX authentication (it does not require an extra lookup, 229 except may be OCSP), if it fails, search a TLSA record, if there is 230 none, depending on the resolver's policy, accept anyway. Clearly, 231 trying all six solutions is unrealistic so some guidance on how to 232 combine them will be necessary. 234 All these solutions can be improved by things like automatic key 235 pinning ([RFC6797]). 237 An authoritative name server cannot know if the resolver authentified 238 it, and how. In the future, it may be interesting to have a EDNS 239 option to signal a successful authentication, or a failure, but this 240 is out of scope currently. 242 4. IANA Considerations 244 There is currently nothing to do for IANA. The future chosen 245 solution may require some IANA action, such as a registry. 247 5. Security Considerations 249 For the time being, refer to each subsection under Section 2 to have 250 an analysis of its security. 252 6. Acknowledgments 254 Shane Kerr for the ideas on authentication by IP address. 256 7. References 258 7.1. Normative References 260 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 261 and P. Hoffman, "Specification for DNS over Transport 262 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 263 2016, . 265 [I-D.ietf-dprive-dtls-and-tls-profiles] 266 Dickinson, S., Gillmor, D., and T. Reddy, "Authentication 267 and (D)TLS Profile for DNS-over-(D)TLS", draft-ietf- 268 dprive-dtls-and-tls-profiles-03 (work in progress), July 269 2016. 271 7.2. Informative References 273 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 274 RFC 3972, DOI 10.17487/RFC3972, March 2005, 275 . 277 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 278 Housley, R., and W. Polk, "Internet X.509 Public Key 279 Infrastructure Certificate and Certificate Revocation List 280 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 281 . 283 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 284 of Named Entities (DANE) Transport Layer Security (TLS) 285 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 286 2012, . 288 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 289 Transport Security (HSTS)", RFC 6797, 290 DOI 10.17487/RFC6797, November 2012, 291 . 293 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 294 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 295 Transport Layer Security (TLS) and Datagram Transport 296 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 297 June 2014, . 299 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 300 DOI 10.17487/RFC7626, August 2015, 301 . 303 [I-D.dempsky-dnscurve] 304 Dempsky, M., "DNSCurve: Link-Level Security for the Domain 305 Name System", draft-dempsky-dnscurve-01 (work in 306 progress), February 2010. 308 [I-D.ietf-tls-dnssec-chain-extension] 309 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 310 Record and DNSSEC Authentication Chain Extension for TLS", 311 draft-ietf-tls-dnssec-chain-extension-01 (work in 312 progress), July 2016. 314 [dnscurve] 315 Bernstein, D., "DNSCurve: Usable security for DNS", June 316 2009, . 318 7.3. URIs 320 [1] https://github.com/bortzmeyer/ietf-dprive-step-2 322 Author's Address 324 Stephane Bortzmeyer 325 AFNIC 326 1, rue Stephenson 327 Montigny-le-Bretonneux 78180 328 France 330 Phone: +33 1 39 30 83 46 331 Email: bortzmeyer+ietf@nic.fr 332 URI: http://www.afnic.fr/