idnits 2.17.1 draft-bretelle-dprive-dot-for-insecure-delegations-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** 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 (March 11, 2019) is 1873 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 298, 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: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 March 11, 2019 5 Expires: September 12, 2019 7 DNS-over-TLS for insecure delegations 8 draft-bretelle-dprive-dot-for-insecure-delegations-01 10 Abstract 12 This document describes an alternative mechanism to DANE ([RFC6698]) 13 in 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 September 12, 2019. 34 Copyright Notice 36 Copyright (c) 2019 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 Infrastructure (PKIX) . . . . . . . . . . . . 3 55 3.2. Subject Public Key Info (SPKI) . . . . . . . . . . . . . 3 56 3.3. Authenticating from the parent . . . . . . . . . . . . . 4 57 3.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. DSPKI Resource Record . . . . . . . . . . . . . . . . . . . . 4 59 4.1. The DSPKI Resource Record . . . . . . . . . . . . . . . . 5 60 4.1.1. DSPKI RDATA Wire Format . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 This document describes an alternative mechanism to DANE ([RFC6698]) 70 as described in [I-D.bortzmeyer-dprive-resolver-to-auth] Section 2 71 extending the authentication of DNS over Transport Layer Security 72 (DoT) [RFC7858] to insecure delegations and therefore enabling the 73 onboarding of DoT authoritative servers without the requirement for 74 the authorities to support DNSSEC ([RFC4033], [RFC4034], and 75 [RFC4035]). To do so, this document introduce the Delegation Subject 76 Public Key Info (DSPKI) resource record, its purpose, usage and 77 format. 79 2. Terminology 81 A server that supports DNS-over-TLS is called a "DoT server" to 82 differentiate it from a "DNS Server" (one that provides DNS service 83 over any other protocol), likewise, a client that supports this 84 protocol is called a "DoT client" 86 A secure delegation ([RFC4956] Section 2) is a signed name containing 87 a delegation (NS RRset), and a signed DS RRset, signifying a 88 delegation to a signed zone. 90 An insecure delegation ([RFC4956] Section 2) is a signed name 91 containing a delegation (NS RRset), but lacking a DS RRset, 92 signifying a delegation to an unsigned subzone. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 3. Authenticating an insecure delegation 102 To authenticate a DoT server of a secure delegation, it is possible 103 to use the TLSA resource record [RFC6698] of the nameserver as 104 decribed in [I-D.bortzmeyer-dprive-resolver-to-auth] Section 2, while 105 this method is valid, the absence of support of DNSSEC for such 106 delegations precludes the onboarding and discovery of nameservers 107 serving those zones as DoT servers. 109 Without the use of DNSSEC, a delegation is not able to authenticate 110 itself as the chain of trust cannot be followed, however other 111 mechanisms exist to have a server authenticate itself, such as Public 112 Key Infrastructure (PKIX [RFC6125]) , SPKI, which have their own pros 113 and cons. 115 3.1. Public Key Infrastructure (PKIX) 117 It would be possible to authenticate the name servers of the insecure 118 delegation using PKIX, relying on an existing trust model and trust 119 anchors. 121 While simple, a single trusted Certificate Authority (CA) that breaks 122 said trust (voluntarily or involuntarily), can issue certificate for 123 any domains, allowing an attacker to potentially impersonate both the 124 application and the DoT server. 126 Another issue that rises is that the DoT servers may use an identity 127 which belong to the same origin as application servers, which could 128 permit personal information (such as cookies) to be leaked to the DoT 129 servers. 131 3.2. Subject Public Key Info (SPKI) 133 The zone owner generates his own certificate and distribute the SPKI 134 fingerprint into the DNS. 136 This is in essence what, amongst other things, TLSA records solve but 137 with the requirement for DNSSEC to be enabled and functional for the 138 queried zone. For insecure delegations, simply advertising the SPKI 139 fingerprint would be trivial to intercept, disable, and modify. 141 3.3. Authenticating from the parent 143 While a delegation is not secured, the DNS core infrastructure 144 already support, for the most part, DNSSEC, meaning that if the owner 145 of an insecure delegation could set the SPKI fingerprint in a 146 resource record (RR) at the parent, such fingerprint could be signed 147 and validated by the DoT client. The DoT client can then establish a 148 TLS connection to the zone name servers and authenticate the DoT 149 server against the fingerprint acquired earlier from the parent zone. 151 3.3.1. Example 153 example.com is an insecure delegation from .com which has set the 154 DSPKI RRset. 156 A DoT client looking for records under example.com will learn from 157 .com that example.com is delegated to 159 example.com IN 172800 NS ns1.example.com 160 example.com IN 172800 NS ns2.example.com 161 # sha256 162 example.com IN DSPKI ( 163 1 4e44f900cdeb8c769f4df97e23f8fc81 164 4ac4bf45a3d9dc265a2ed925171f0b71 ) 165 # sha512 166 example.com IN DSPKI ( 167 2 ab40ed300fd220d8c72a600069f9ceb1 168 f9fd7c003117e4ef34b228da1c9d76a0 169 500be99e82a0c01e7f80930a46ad28b8 170 ed3d5ed2df34d822b5f56c99f45889ef 171 ) 172 ns1.example.com IN 172800 AAAA 2001:db8:abcd:12:1:2:3:4 173 ns2.example.com IN 172800 AAAA 2001:db8:abcd:ab:1:2:3:4 175 with the accompanying signature. 177 The DSPKI RRset signals that the nameservers are able to support DNS- 178 over-TLS. The DoT client can then establish a TLS connection to the 179 DoT server and authenticate them by ensuring that the SPKI matches 180 the one learned from the parent zone. 182 4. DSPKI Resource Record 184 There may be 0 or more DSPKI served by the parent of the delegation. 185 0 means that DSPKI is not supported, therefore the DoT client could 186 try other alternatives. 1 or multiple public keys can be distributed 187 to let the DoT client validate multiple public keys, which can be 188 useful while doing certificate rotation or when willing to provide 189 different secret keys to different providers that may serve the 190 delegated zone. 192 4.1. The DSPKI Resource Record 194 The DSPKI resource record (RR) is used to associate a DoT server 195 public key (SPKI) with the zone it is serving. 197 4.1.1. DSPKI RDATA Wire Format 199 The RDATA of the DSPKI RR consists of a one-octet matching type 200 field, and the DER-encoded binary structure of the 201 SubjectPublicKeyInfo field as defined in [RFC5280]. 203 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | matching type | DER-encoded SPKI field / 207 +-+-+-+-+-+-+-+-+ / 208 / / 209 / / 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 4.1.1.1. The Matching Type Field 214 A one-octet value, called "matching type", specifies how the SPKI is 215 presented. The types defined in this document are: 217 o 0 - Exact match on SPKI 219 o 1 - SHA-256 hash of SPKI 221 o 2 - SHA-512 hash of SPKI 223 Where the SPKI can be extracted as follow: 225 openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform der 227 and the SHA-256 as: 229 openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform der | \ 230 openssl dgst -sha256 -binary 232 *FIXME*: consider 234 o alternate URI to support DoT (host, port, spki), DoH (host, port, 235 URL template), DNS-over-QUIC... would rather be an ALTNS type of 236 record 238 o CDSPKI a la CDS, CDNSKEY 240 5. Security Considerations 242 TODO Security 244 6. IANA Considerations 246 TODO: This document requires IANA actions (new RR type). 248 7. Normative References 250 [I-D.bortzmeyer-dprive-resolver-to-auth] 251 Bortzmeyer, S., "Encryption and authentication of the DNS 252 resolver-to-authoritative communication", draft- 253 bortzmeyer-dprive-resolver-to-auth-01 (work in progress), 254 March 2018. 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, 258 DOI 10.17487/RFC2119, March 1997, 259 . 261 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 262 Rose, "DNS Security Introduction and Requirements", 263 RFC 4033, DOI 10.17487/RFC4033, March 2005, 264 . 266 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 267 Rose, "Resource Records for the DNS Security Extensions", 268 RFC 4034, DOI 10.17487/RFC4034, March 2005, 269 . 271 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 272 Rose, "Protocol Modifications for the DNS Security 273 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 274 . 276 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security 277 (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July 278 2007, . 280 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 281 Housley, R., and W. Polk, "Internet X.509 Public Key 282 Infrastructure Certificate and Certificate Revocation List 283 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 284 . 286 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 287 Verification of Domain-Based Application Service Identity 288 within Internet Public Key Infrastructure Using X.509 289 (PKIX) Certificates in the Context of Transport Layer 290 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 291 2011, . 293 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 294 of Named Entities (DANE) Transport Layer Security (TLS) 295 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 296 2012, . 298 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 299 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 300 Transport Layer Security (TLS) and Datagram Transport 301 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 302 June 2014, . 304 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 305 and P. Hoffman, "Specification for DNS over Transport 306 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 307 2016, . 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 Acknowledgments 315 TODO acknowledge. 317 Author's Address 319 Emmanuel Bretelle 320 Facebook 322 Email: chantra@fb.com