idnits 2.17.1 draft-hoffman-dnssec-s-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 draft header indicates that this document updates RFC4034, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4035, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4034, updated by this document, for RFC5378 checks: 2002-02-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 28, 2017) is 2492 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) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA256' == Outdated reference: A later version (-14) exists of draft-ietf-dnsop-terminology-bis-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft M. Larson 4 Updates: 4034, 4035 (if approved) ICANN 5 Intended status: Standards Track June 28, 2017 6 Expires: December 30, 2017 8 Session-baseed Authentication for DNS: DNSSEC-S 9 draft-hoffman-dnssec-s-00 11 Abstract 13 DNSSEC as defined in RFCs 4033, 4034, and 4035 is based on 14 authenticated messages. That design has allowed DNSSEC to be 15 deployed at the upper levels of the DNS tree, but operational issues 16 with message-based authentication has caused lower levels fo the DNS 17 tree to mostly forego DNSSEC. This document extends DNSSEC with a 18 second type of authentication, based on session authentication from 19 TLS, that is easier to deploy by some (but certainly not all) 20 authoritative DNS servers. The goal is to have many more zones be 21 DNSSEC-enabled. 23 Note that this document does _not_ replace current DNSSEC. A 24 validating resolver needs to implement all of traditional DNSSEC, and 25 might also implement the protocol defined here. A server might 26 protect the contents of DNS zones for which it is authoritative with 27 traditional DNSSEC, with the protocol defined here, or both. The 28 protocol defined here is only useful for some authoritative servers, 29 and is explicitly not useful for others. 31 *** Notice for -00 *** 33 This -00 draft is meant to engender discussion, particularly to find 34 out if there is a good use case for this proposal. This draft is 35 definitely not considered ready for consideration in an IETF WG. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 30, 2017. 54 Copyright Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 1. Introduction 71 As stated in [RFC4033], "The Domain Name System Security Extensions 72 (DNSSEC) add data origin authentication and data integrity to the 73 Domain Name System". The protocol described in [RFC4033], [RFC4034], 74 and [RFC4035] provide those services by adding new resource records 75 and specifying how to cryptographically validate the contents of 76 those records. In this document, DNSSEC as defined in [RFC4033], 77 [RFC4034], [RFC4035] and all RFCs that update those three is called 78 "DNSSEC-M". The designation "-M" means "message": those RFCs define 79 secure message-based authentication for DNS messages. 81 This document defines a second type of DNSSEC that can be used 82 alongside DNSSEC-M. This second type uses secure session-based 83 authentication using TLS. It is called "DNSSEC-S", where "-S" means 84 "session". In short, DNSSEC-S allows the validating resolver to 85 authenticate the origin of the DNS data because it comes directly 86 from the authoritative server during a TLS session; the TLS session 87 also provides data integrity. DNSSEC-S clients and servers MUST use 88 TLS 1.3 [I-D.ietf-tls-tls13]. 90 The protocol described in this document provides a mechanism could 91 encourage many more organizations, particularly large organizations 92 that already run secure web services, to enable DNSSEC on their 93 zones. 95 1.1. Use Cases 97 Deploying DNSSEC-M has proven successful in some environments, but 98 not in others. At the time this document is published, the root of 99 the DNS tree is secured with DNSSEC-M, as are many of the TLDs in the 100 root. However, only a few major content providers have signed their 101 zones with DNSSEC-M. 103 When asked why they don't sign their zones, these content providers 104 give various reasons, but one major reason stands out. The software 105 that is used to sign zones for DNSSEC-M is often described as 106 "complicated" and "fragile". If a zone is not properly signed before 107 it is published by the authoritative server, parts or all of the zone 108 may become unavailable to recursive resolvers that perform DNSSEC-M 109 validation. Further, the signing software must be run periodically 110 and the results must be correct; otherwise, the zone becomes 111 unavailable and may stay that way for days even after the problem is 112 discovered. 114 Content providers say that the risk of their zone becoming 115 unavailable due to the above problems with DNSSEC-M (as well as other 116 issues) is not worth the positive attributes of DNSSEC-M, and 117 therefore leave their zones unsigned. 119 If a system can definitively eliminate this risk while introducing 120 only much smaller risks, some content providers might consider 121 authenticating their zones with DNSSEC. DNSSEC-S proposes to be such 122 a system. 124 1.2. Use Cases Not Considered Here 126 DNSSEC-S uses TLS for session security, and TLS also provides 127 encryption of sessions. However, the encrypted aspect of DNSSEC-S 128 sessions is explicitly not considered a use case for DNSSEC-S. 129 DNSSEC-S is not appropriate for all authoritative servers, so the 130 encryption that comes as part of DNSSEC-S should only be considered a 131 useful side-benefit, not a primary use case. The DPRIVE Working 132 Group in the IETF is currently considering mechanisms to encrypt 133 communications with authoritative servers. 135 The security of DNSSEC-S relies on keeping the TLS private key 136 secret. Because of this, DNSSEC-S is not appropriate for DNSSEC- 137 protected zones where the nameservers are run by multiple 138 organizations that have different abilities to protect a private key. 139 As an obvious example, the DNS root is currently served by a dozen 140 different organizations. Because it is impossible to serve the 141 current DNS using just DNSSEC-S, this document mandates that 142 validating resolvers MUST support validating with DNSSEC-M if they 143 also support validating with DNSSEC-S. 145 1.3. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119, BCP 14 150 [RFC2119] and indicate requirement levels for compliant CBOR 151 implementations. 153 This document creates two new terms, "DNSSEC-M" and "DNSSEC-S". See 154 Section 1 for their definition. It also creates associated terms, 155 "DS hash set" in Section 2.3 and "certificate hash set" in 156 Section 2.5. 158 A great deal of other DNSSEC-related terminology can be found in 159 [I-D.ietf-dnsop-terminology-bis]. 161 2. Protocol Description 163 2.1. Overview 165 A DNS client that wants authenticated answers to queries (such as a 166 Security-Aware Recursive Name Server, a Security-Aware Resolver, or a 167 Security-Aware Stub Resolver) can detect that an authoritative server 168 is using DNSSEC-S when it gets the DS records for that authoritative 169 server from the parent zone. If one or more of those DS records have 170 a digest type of DS-DIGEST-TBD, then the client can assume that the 171 authoritative server speaks DNS over TLS as defined in this document, 172 and that the TLS session can be authenticated with the contents of 173 the DS record. 175 After a TLS session is established, the DNS client and the server 176 speak the normal DNS protocol (using the two-octet length extension 177 for TCP) described in [RFC1035], except that the messages go in the 178 TLS connection, not over UDP or TCP. The DNS client treats all 179 authoritative responses from the server as authenticated because they 180 are received in the TLS session. 182 DNSSEC-S does not have the problems listed for DNSSEC-M listed in 183 Section 1.1. There is no DNS-specific cryptography in DNSSEC-S; 184 instead, it relies on TLS cryptography which is already well 185 understood. There is no need to sign anything in a zone or to 186 maintain the zone signing keys. 188 2.2. Service Discovery and Authentication Through a New DS Type 190 A DNSSEC-S client discovers that an authoritative server supports 191 DNSSEC-S by querying the authoritative server's parent for the DS 192 record set, and noting if any of the DS records are in the format 193 given here. There is a DNSSEC-S DS record in the parent for each TLS 194 certificate that the authoritative server might present when serving 195 DNSSEC-S. 197 The DS record in the parent zone for DNSSEC-S has the same format as 198 other DS records, but the values in some of the fields are different. 199 For DNSSEC-S, the values MUST be: 201 o Key Tag - 0 203 o Algorithm - The signing algorithm of the TLS certificate 205 o Digest Type - DS-DIGEST-TBD 207 o Digest - The SHA-256 [SHA256] hash of the authenticating public 208 key in the TLS certificate 210 The display format is unchanged from Section 5.3 of [RFC4034]. 212 2.3. Client Preparation Before Establishing a TLS Connection 214 The client validates the DS resource record set in the parent for a 215 zone; if the resource record set does not validate, the client MUST 216 NOT use DNSSEC-S to authenticate values in the zone. 218 The client creates a data structure called the "DS hash set". Each 219 member of the data structure consists of a hash value obtained from 220 the DS records that have Digest Type DS-DIGEST-TBD. DS records with 221 Digest Type other than DS-DIGEST-TBD MUST NOT be used to create the 222 DS hash set. 224 If the DS hash set is empty, the client MUST NOT attempt to establish 225 a TLS connection. 227 2.4. Establishing the TLS Session 229 The client chooses a record from the DS hash set and starts a TLS 230 session on port 443 with the server at one of the IP addresses from 231 the record. Both client and server MUST use TLS 1.3 232 [I-D.ietf-tls-tls13]. 234 *** 235 There are two proposals for how to connect to the TLS server: on port 236 443 using ALPN [RFC7301] and ALPN identifier ALPN-TBD, or on port 237 PORT-TBD (a new port). Both proposals have the same cryptographic 238 properties, and almost identical properties for middleboxes. One or 239 the other needs to be chosen during the discussion of this protocol. 241 *** 243 Depending on the choice made, one of the following statements will be 244 made in the protocol. 246 o The client MUST identify the session with ALPN using ALPN-TBD as 247 an identifier to establish the TLS session. 249 o The client MUST use port PORT-TBD to establish the TLS session. 251 The registration for one or the other appear in Section 6. 253 2.5. Authenticating the TLS Session 255 The client receives the TLS Certificates message from the server. 256 Note that the Certificate message might contain one or more raw 257 public keys (described in [RFC7250]. For each certificate in the 258 Certificates message, the client hashes the public key in the 259 certificate with SHA-256 and adds it to a data structure called the 260 "certificate hash set". 262 The client then compares the the first element from the DS hash set 263 to the elements in the certificate hash set. If there is a match, 264 the certificate associated with that hash is considered authenticated 265 for TLS. If there is no match, the client compares each of the 266 remaining elements from the DS hash set, searching for a match. 268 If there is no match for any element in the DS hash set in the 269 certificate hash set, the client MUST terminate the connection with 270 an authentication failure as described in [I-D.ietf-tls-tls13]. In 271 this case, the client MUST NOT use DNSSEC-S with this server for this 272 session, and SHOULD NOT try again to use DNSSEC-S with that server 273 until the signature on the DS resource record set has expired. 275 2.6. Continuing the Authenticated Session 277 After a TLS session is established, the DNS client and the server 278 speak the normal DNS protocol (using the two-octet length extension 279 for TCP) described in [RFC1035], except that the messages go in the 280 TLS connection, not over UDP or TCP. The DNS client treats all 281 authoritative responses from the server as authenticated because they 282 are received in the TLS session. 284 3. Updates to RFC 4033, 4034, and 4035 286 *** This section will list specific textual updates to the base 287 DNSSEC-M RFCs to allow for DNSSEC-S. The section might get long; if 288 so, it will be broken into sub-sections for easier commenting. This 289 section is a placeholder for later drafts if this work is adopted. 290 *** 292 o Any authoritative answer from an authoritative server is 293 considered validated if it was obtained with DNSSEC-S. [RFC4035] 294 Section 5 (and maybe 4?). Non-authoritative answers are not 295 considered validated. This will need a careful list of 296 restrictions (Answer section, AA bit set, ...). 298 o A DS record with Digest Type DS-DIGEST-TBD MUST NOT be used for 299 chaining with DNSKEY records. [RFC4034] Section 5. 301 o There are probably other updates. 303 4. Additional Considerations 305 4.1. Effect of DNSSEC-S on Resolvers that Only Validate with DNSSEC-M 307 DNSSEC-S is designed to not affect resolvers that only validate with 308 DNSSEC-M. The choice of using DS-DIGEST-TBD in the DS record in the 309 parent will cause a resolver that only knows about DNSSEC-M to think 310 that the child zone is unsigned. Section 5.2 of [RFC4035] says that 311 the following must hold: 313 "The Algorithm and Key Tag in the DS RR match the Algorithm field and 314 the key tag of a DNSKEY RR in the child zone's apex DNSKEY RRset, 315 and, when the DNSKEY RR's owner name and RDATA are hashed using the 316 digest algorithm specified in the DS RR's Digest Type field, the 317 resulting digest value matches the Digest field of the DS RR." 319 A validator that only knows DNSSEC-M will not know how to hash "using 320 the digest algorithm specified in the DS RR's Digest Type field" 321 because it will not know the algorithm for DS-DIGEST-TBD. 323 4.2. Simultaneous Use of Both DNSSEC-M and DNSSEC-S 325 An authoritative server that uses DNSSEC-S for authentication can 326 also use DNSSEC-M if it wishes. That is, such a server can still 327 answer queries with the DO bit set just as it would have if the 328 queries came over UDP or TCP instead of over TLS. In order to do 329 this, the authoritative server would need at least two DS records in 330 its parent's zone, one for DNSSEC-M and one for DNSSEC-S. 332 Similarly, a DNS client that is using DNSSEC-S can still request 333 DNSSEC-M records (using the DO bit) and process them as it would if 334 those records were received over UDP or TCP (or out of band). A DNS 335 client may successfully establishes a DNSSEC-S session and receive 336 DNSSEC-M responses that do not validate; the result of such a 337 situation is explicitly undefined in this document. 339 4.3. Standby Keys 341 An authoritative server can deploy standby keys whose private keys 342 are not in production. To do this, they simply add NS records whose 343 DNSSEC NS Label is the hash of the not-yet-operational public key, 344 and the A or AAAA records for that name point to the same servers as 345 the operational NS records. 347 This scheme will make validators that use DNSSEC-S to be slightly 348 slower because they need to perform one extra decoding per standby 349 key, and possibly one extra SHA-256 hash execution per comparison 350 with certificates from the TLS server. 352 4.4. DoS Attacks on DNSSEC-S 354 All TLS servers are susceptible to CPU-exhaustion attacks from 355 attackers who can generate traffic that requires the server to do 356 asymmetric computations. Zones that use DNSSEC-S are as susceptible 357 to these denial-of-service attacks as web servers that use HTTPS and 358 mail servers that use SMTPS. TLS 1.3 will be less susceptible to 359 such attacks than earlier versions of TLS, but some attacks are still 360 possible. 362 Note that DNSSEC-M with online signing of DNSSEC records are also 363 susceptible to DoS attacks. This area has not been heavily studied, 364 but it is possible that DNSSEC-S servers will be less susceptible to 365 CPU exhaustion attacks than DNSSEC-M servers that use online signing. 367 5. Security Considerations 369 *** This section will clearly be much longer before the document is 370 finished. Proposed additions are welcome. *** 372 The security of DNSSEC-S is completely dependent on the ability of 373 DNSSEC-S clients to correctly match the public keys in the TLS 374 certificate messages with the values in the DNSSEC-S NS Labels. A 375 DNSSEC-S client that mis-implements the rules in this protocol is 376 capable of being fooled into validating answers that it should not. 378 An authoritative server that supports both DNSSEC-S and DNSSEC-M, and 379 sends DNSSEC-M records that cause the authoritative answers to not 380 validate in DNSSEC-M, will likely have nondeterministic results when 381 queried; see Section 4.2. 383 DNSSEC-S is susceptible to denial-of-service attacks that DNSSEC-M 384 using offline signing is not; see Section 4.4. 386 6. IANA Considerations 388 *** If ALPN is chosen, a template for registering ALPN-TBD will go 389 here. However, if a new port is chosen, a template for registering 390 port PORT-TBD will go here. Only one of these two registrations will 391 appear here. *** 393 *** The template for registering DS-DIGEST-TBD will go here. *** 395 --back 397 7. References 399 7.1. Normative References 401 [I-D.ietf-tls-tls13] 402 Rescorla, E., "The Transport Layer Security (TLS) Protocol 403 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 404 April 2017. 406 [RFC1035] Mockapetris, P., "Domain names - implementation and 407 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 408 November 1987, . 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, 413 . 415 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 416 Rose, "DNS Security Introduction and Requirements", 417 RFC 4033, DOI 10.17487/RFC4033, March 2005, 418 . 420 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 421 Rose, "Resource Records for the DNS Security Extensions", 422 RFC 4034, DOI 10.17487/RFC4034, March 2005, 423 . 425 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 426 Rose, "Protocol Modifications for the DNS Security 427 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 428 . 430 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 431 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 432 Transport Layer Security (TLS) and Datagram Transport 433 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 434 June 2014, . 436 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 437 "Transport Layer Security (TLS) Application-Layer Protocol 438 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 439 July 2014, . 441 [SHA256] National Institute of Standards and Technology, "Secure 442 Hash Standard (SHS), FIPS 180-4", August 2015, 443 . 446 7.2. Informative References 448 [I-D.ietf-dnsop-terminology-bis] 449 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 450 Terminology", draft-ietf-dnsop-terminology-bis-05 (work in 451 progress), March 2017. 453 Authors' Addresses 455 Paul Hoffman 456 ICANN 458 Email: paul.hoffman@icann.org 460 Matt Larson 461 ICANN 463 Email: matt.larson@icann.org