idnits 2.17.1 draft-bretelle-dprive-dot-for-insecure-delegations-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 abstract seems to contain references ([RFC7858], [RFC6698]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 27, 2018) is 2038 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) == Unused Reference: 'RFC7250' is defined on line 272, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 4956 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bretelle 3 Internet-Draft Facebook 4 Intended status: Standards Track September 27, 2018 5 Expires: March 31, 2019 7 DNS-over-TLS for insecure delegations 8 draft-bretelle-dprive-dot-for-insecure-delegations-00 10 Abstract 12 This document describes an alternate mechanism to DANE ([RFC6698]) in 13 order to authenticate a DNS-over-TLS (DoT [RFC7858]) authoritative 14 server by not making DNSSEC a hard requirement, making DoT server 15 authentication available for insecure delegations. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 31, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Authenticating an insecure delegation . . . . . . . . . . . . 3 54 3.1. Public Key Infranstructure (PKIX) . . . . . . . . . . . . 3 55 3.2. Simple Public-Key Infrastructure (SPKI) . . . . . . . . . 3 56 3.3. Authenticating from the parent . . . . . . . . . . . . . 4 57 3.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. DSPKI Resource Record . . . . . . . . . . . . . . . . . . . . 5 59 4.1. DSPKI RDATA Format . . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 63 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 This document describes an alternate mechanism to [RFC6698] as 69 described in [I-D.bortzmeyer-dprive-resolver-to-auth] Section 2 70 extending the authentication of DoT [RFC7858] to insecure delegations 71 and therefore enabling the onboarding of DoT authoritative servers 72 without the requirement for the authorities to support DNSSEC 73 ([RFC4033], [RFC4034], and [RFC4035]). To do so, this document 74 introduce the Delegation SPKI (DSPKI) resource record, its purpose, 75 usage and format. 77 2. Terminology 79 A server that supports DNS-over-TLS is called a "DoT server" to 80 differentiate it from a "DNS Server" (one that provides DNS service 81 over any other protocol), likewise, a client that supports this 82 protocol is called a "DoT client" 84 A secure delegation ([RFC4956] Section 2) is a signed name containing 85 a delegation (NS RRset), and a signed DS RRset, signifying a 86 delegation to a signed zone. 88 An insecure delegation ([RFC4956] Section 2) is a signed name 89 containing a delegation (NS RRset), but lacking a DS RRset, 90 signifying a delegation to an unsigned subzone. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 3. Authenticating an insecure delegation 100 To authenticate a DoT server of a secure delegation, it is possible 101 to use the TLSA resource record [RFC6698] of the nameserver as 102 decribed in [I-D.bortzmeyer-dprive-resolver-to-auth] Section 2, while 103 this method is valid, the absence of support of DNSSEC for such 104 delegations precludes the onboarding and discovery of nameservers 105 serving those zones as DoT servers. 107 Without the use of DNSSEC, a delegation is not able to authenticate 108 itself as the chain of trust cannot be followed, however other 109 mechanisms exist to have a server authenticate itself, such as Public 110 Key Infrastructure (PKIX [RFC6125]) , SPKI, which have their own pros 111 and cons. 113 3.1. Public Key Infranstructure (PKIX) 115 It would be possible to authenticate the nameservers of the insecure 116 delegation using PKIX, relying on an existing trust model and trust 117 anchors. 119 While simple, a single trusted CA that breaks said trust (voluntarily 120 or involuntarily), can issue certificate for any domains, allowing an 121 attacker to potentially impersonate both the application and the DoT 122 server. 124 Another issue that rises is that the DoT servers may use an identity 125 which belong to the same origin as application servers, which could 126 permit personal information (such as cookies) to be leaked to the DoT 127 servers. 129 3.2. Simple Public-Key Infrastructure (SPKI) 131 SPKI on the other hand does not have the same issues than PKIX, the 132 certificates can be generated by the authority itself, adding a 133 separation of privileges between the PKIX infrastructure and the DNS 134 one. 136 The problem is now on how to advertise/distribute the delegation's 137 public key. 139 This is in essence what TLSA records solve, but with the use of 140 DNSSEC enabled and functional for the queried zone. For insecure 141 delegations, simply advertising the public key would be subject to 142 interception and mangling. 144 3.3. Authenticating from the parent 146 While a delegation is not secured, the DNS core infrastructure 147 already support DNSSEC, meaning that if the owner of an insecure 148 delegation could set the public key to authenticate the DoT servers 149 against, such key could be authenticated using DNSSEC at the parent 150 level, which would then permit trusting the DoT servers providing 151 their certificate validates against the ( then validated) public key 152 provided by the parent. 154 From this stage, the "formerly" insecure delegation can be 155 authenticated, and therefore considered secure, allowing delegating 156 to other zones which can be authenticated by either DNSSEC or TLS. 158 In order to provide its public key to the DoT clients, an insecure 159 would set the DSPKI RRset at the parent with the content of its 160 extracted SPKI, which the parent then sign. 162 A DoT client which is about to talk with a DoT server can obtain and 163 validate the DSPKI RRset from the parent and authenticate the DoT 164 server, without needing the DoT server to serve a secure delegation. 166 3.3.1. Example 168 example.com is an insecure delegation from .com which has set the 169 DSPKI RRset. 171 A DoT client looking for records under example.com will learn from 172 .com that example.com is delegated to 174 example.com 172800 NS ns1.example.com 175 example.com 172800 NS ns2.example.com 176 example.com 86400 DSPKI h0KPxSKAPTEGXnvOPPA/5HUJZjHl4Hu9eg/eYMTPJcc= 177 ns1.example.com 172800 AAAA 2001:db8:abcd:12:1:2:3:4 178 ns2.example.com 172800 AAAA 2001:db8:abcd:ab:1:2:3:4 180 with the accompanying signature. 182 The DSPKI RRset signals that the nameservers are able to support DNS- 183 over-TLS and the DoT client can authenticate them using the provided 184 public key, 186 If subzone.example.com is a delegation from example.com, example.com 187 can provide the DSPKI RRSet of the delegation. While example.com is 188 not a secured delegation, because it has been authenticated using 189 TLS, it is also able to be part of the chain of trust and provide 190 either a DS or DSPKI RRset for subzone.example.com 192 4. DSPKI Resource Record 194 There may be 0 or more DSPKI served by the parent of the delegation. 195 0 would mean that DSPKI is not supported, therefore the DoT client 196 could try other alternatives. 1 or multiple public keys can be 197 distributed to let the DoT client validate multiple public keys, 198 which can be useful while doing certificate rotation or when willing 199 to provide different secret keys to different providers that may 200 serve the delegated zone. 202 4.1. DSPKI RDATA Format 204 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 205 / PUBKEY / 206 / / 207 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 209 Where PUBKEY: A base64 encoded string of the sha256sum of the public 210 key, as generated by: ~~~~ openssl x509 -in cert.pem -pubkey -noout | 211 openssl pkey -pubin -outform der | \ openssl dgst -sha256 -binary | 212 openssl enc -base64 ~~~~ 214 *FIXME*: consider * format that can evolve over time, e.g 1 byte 215 specifying hashing algorithm. * no need for base64, raw bytes are 216 fine. * alternate URI to support DoT (host, port, spki), DoH (host, 217 port, URL template), DNS-over-QUIC... would rather be an ALTNS type 218 of record * CDSPKI a la CDS, CDNSKEY 220 5. Security Considerations 222 TODO Security 224 6. IANA Considerations 226 TODO: This document requires IANA actions (new RR type). 228 7. Normative References 230 [I-D.bortzmeyer-dprive-resolver-to-auth] 231 Bortzmeyer, S., "Encryption and authentication of the DNS 232 resolver-to-authoritative communication", draft- 233 bortzmeyer-dprive-resolver-to-auth-01 (work in progress), 234 March 2018. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, 238 DOI 10.17487/RFC2119, March 1997, 239 . 241 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 242 Rose, "DNS Security Introduction and Requirements", 243 RFC 4033, DOI 10.17487/RFC4033, March 2005, 244 . 246 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 247 Rose, "Resource Records for the DNS Security Extensions", 248 RFC 4034, DOI 10.17487/RFC4034, March 2005, 249 . 251 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 252 Rose, "Protocol Modifications for the DNS Security 253 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 254 . 256 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security 257 (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July 258 2007, . 260 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 261 Verification of Domain-Based Application Service Identity 262 within Internet Public Key Infrastructure Using X.509 263 (PKIX) Certificates in the Context of Transport Layer 264 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 265 2011, . 267 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 268 of Named Entities (DANE) Transport Layer Security (TLS) 269 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 270 2012, . 272 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 273 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 274 Transport Layer Security (TLS) and Datagram Transport 275 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 276 June 2014, . 278 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 279 and P. Hoffman, "Specification for DNS over Transport 280 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 281 2016, . 283 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 284 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 285 May 2017, . 287 Acknowledgments 289 TODO acknowledge. 291 Author's Address 293 Emmanuel Bretelle 294 Facebook 296 Email: chantra@fb.com