Network Working Group P. Hoffman Internet-Draft M. Larson Updates: 4034, 4035 (if approved) ICANN Intended status: Standards Track June 28, 2017 Expires: December 30, 2017 Session-baseed Authentication for DNS: DNSSEC-S draft-hoffman-dnssec-s-00 Abstract DNSSEC as defined in RFCs 4033, 4034, and 4035 is based on authenticated messages. That design has allowed DNSSEC to be deployed at the upper levels of the DNS tree, but operational issues with message-based authentication has caused lower levels fo the DNS tree to mostly forego DNSSEC. This document extends DNSSEC with a second type of authentication, based on session authentication from TLS, that is easier to deploy by some (but certainly not all) authoritative DNS servers. The goal is to have many more zones be DNSSEC-enabled. Note that this document does _not_ replace current DNSSEC. A validating resolver needs to implement all of traditional DNSSEC, and might also implement the protocol defined here. A server might protect the contents of DNS zones for which it is authoritative with traditional DNSSEC, with the protocol defined here, or both. The protocol defined here is only useful for some authoritative servers, and is explicitly not useful for others. *** Notice for -00 *** This -00 draft is meant to engender discussion, particularly to find out if there is a good use case for this proposal. This draft is definitely not considered ready for consideration in an IETF WG. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Hoffman & Larson Expires December 30, 2017 [Page 1] Internet-Draft DNSSEC-S June 2017 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 30, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction As stated in [RFC4033], "The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System". The protocol described in [RFC4033], [RFC4034], and [RFC4035] provide those services by adding new resource records and specifying how to cryptographically validate the contents of those records. In this document, DNSSEC as defined in [RFC4033], [RFC4034], [RFC4035] and all RFCs that update those three is called "DNSSEC-M". The designation "-M" means "message": those RFCs define secure message-based authentication for DNS messages. This document defines a second type of DNSSEC that can be used alongside DNSSEC-M. This second type uses secure session-based authentication using TLS. It is called "DNSSEC-S", where "-S" means "session". In short, DNSSEC-S allows the validating resolver to authenticate the origin of the DNS data because it comes directly from the authoritative server during a TLS session; the TLS session also provides data integrity. DNSSEC-S clients and servers MUST use TLS 1.3 [I-D.ietf-tls-tls13]. The protocol described in this document provides a mechanism could encourage many more organizations, particularly large organizations that already run secure web services, to enable DNSSEC on their zones. Hoffman & Larson Expires December 30, 2017 [Page 2] Internet-Draft DNSSEC-S June 2017 1.1. Use Cases Deploying DNSSEC-M has proven successful in some environments, but not in others. At the time this document is published, the root of the DNS tree is secured with DNSSEC-M, as are many of the TLDs in the root. However, only a few major content providers have signed their zones with DNSSEC-M. When asked why they don't sign their zones, these content providers give various reasons, but one major reason stands out. The software that is used to sign zones for DNSSEC-M is often described as "complicated" and "fragile". If a zone is not properly signed before it is published by the authoritative server, parts or all of the zone may become unavailable to recursive resolvers that perform DNSSEC-M validation. Further, the signing software must be run periodically and the results must be correct; otherwise, the zone becomes unavailable and may stay that way for days even after the problem is discovered. Content providers say that the risk of their zone becoming unavailable due to the above problems with DNSSEC-M (as well as other issues) is not worth the positive attributes of DNSSEC-M, and therefore leave their zones unsigned. If a system can definitively eliminate this risk while introducing only much smaller risks, some content providers might consider authenticating their zones with DNSSEC. DNSSEC-S proposes to be such a system. 1.2. Use Cases Not Considered Here DNSSEC-S uses TLS for session security, and TLS also provides encryption of sessions. However, the encrypted aspect of DNSSEC-S sessions is explicitly not considered a use case for DNSSEC-S. DNSSEC-S is not appropriate for all authoritative servers, so the encryption that comes as part of DNSSEC-S should only be considered a useful side-benefit, not a primary use case. The DPRIVE Working Group in the IETF is currently considering mechanisms to encrypt communications with authoritative servers. The security of DNSSEC-S relies on keeping the TLS private key secret. Because of this, DNSSEC-S is not appropriate for DNSSEC- protected zones where the nameservers are run by multiple organizations that have different abilities to protect a private key. As an obvious example, the DNS root is currently served by a dozen different organizations. Because it is impossible to serve the current DNS using just DNSSEC-S, this document mandates that Hoffman & Larson Expires December 30, 2017 [Page 3] Internet-Draft DNSSEC-S June 2017 validating resolvers MUST support validating with DNSSEC-M if they also support validating with DNSSEC-S. 1.3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, BCP 14 [RFC2119] and indicate requirement levels for compliant CBOR implementations. This document creates two new terms, "DNSSEC-M" and "DNSSEC-S". See Section 1 for their definition. It also creates associated terms, "DS hash set" in Section 2.3 and "certificate hash set" in Section 2.5. A great deal of other DNSSEC-related terminology can be found in [I-D.ietf-dnsop-terminology-bis]. 2. Protocol Description 2.1. Overview A DNS client that wants authenticated answers to queries (such as a Security-Aware Recursive Name Server, a Security-Aware Resolver, or a Security-Aware Stub Resolver) can detect that an authoritative server is using DNSSEC-S when it gets the DS records for that authoritative server from the parent zone. If one or more of those DS records have a digest type of DS-DIGEST-TBD, then the client can assume that the authoritative server speaks DNS over TLS as defined in this document, and that the TLS session can be authenticated with the contents of the DS record. After a TLS session is established, the DNS client and the server speak the normal DNS protocol (using the two-octet length extension for TCP) described in [RFC1035], except that the messages go in the TLS connection, not over UDP or TCP. The DNS client treats all authoritative responses from the server as authenticated because they are received in the TLS session. DNSSEC-S does not have the problems listed for DNSSEC-M listed in Section 1.1. There is no DNS-specific cryptography in DNSSEC-S; instead, it relies on TLS cryptography which is already well understood. There is no need to sign anything in a zone or to maintain the zone signing keys. Hoffman & Larson Expires December 30, 2017 [Page 4] Internet-Draft DNSSEC-S June 2017 2.2. Service Discovery and Authentication Through a New DS Type A DNSSEC-S client discovers that an authoritative server supports DNSSEC-S by querying the authoritative server's parent for the DS record set, and noting if any of the DS records are in the format given here. There is a DNSSEC-S DS record in the parent for each TLS certificate that the authoritative server might present when serving DNSSEC-S. The DS record in the parent zone for DNSSEC-S has the same format as other DS records, but the values in some of the fields are different. For DNSSEC-S, the values MUST be: o Key Tag - 0 o Algorithm - The signing algorithm of the TLS certificate o Digest Type - DS-DIGEST-TBD o Digest - The SHA-256 [SHA256] hash of the authenticating public key in the TLS certificate The display format is unchanged from Section 5.3 of [RFC4034]. 2.3. Client Preparation Before Establishing a TLS Connection The client validates the DS resource record set in the parent for a zone; if the resource record set does not validate, the client MUST NOT use DNSSEC-S to authenticate values in the zone. The client creates a data structure called the "DS hash set". Each member of the data structure consists of a hash value obtained from the DS records that have Digest Type DS-DIGEST-TBD. DS records with Digest Type other than DS-DIGEST-TBD MUST NOT be used to create the DS hash set. If the DS hash set is empty, the client MUST NOT attempt to establish a TLS connection. 2.4. Establishing the TLS Session The client chooses a record from the DS hash set and starts a TLS session on port 443 with the server at one of the IP addresses from the record. Both client and server MUST use TLS 1.3 [I-D.ietf-tls-tls13]. *** Hoffman & Larson Expires December 30, 2017 [Page 5] Internet-Draft DNSSEC-S June 2017 There are two proposals for how to connect to the TLS server: on port 443 using ALPN [RFC7301] and ALPN identifier ALPN-TBD, or on port PORT-TBD (a new port). Both proposals have the same cryptographic properties, and almost identical properties for middleboxes. One or the other needs to be chosen during the discussion of this protocol. *** Depending on the choice made, one of the following statements will be made in the protocol. o The client MUST identify the session with ALPN using ALPN-TBD as an identifier to establish the TLS session. o The client MUST use port PORT-TBD to establish the TLS session. The registration for one or the other appear in Section 6. 2.5. Authenticating the TLS Session The client receives the TLS Certificates message from the server. Note that the Certificate message might contain one or more raw public keys (described in [RFC7250]. For each certificate in the Certificates message, the client hashes the public key in the certificate with SHA-256 and adds it to a data structure called the "certificate hash set". The client then compares the the first element from the DS hash set to the elements in the certificate hash set. If there is a match, the certificate associated with that hash is considered authenticated for TLS. If there is no match, the client compares each of the remaining elements from the DS hash set, searching for a match. If there is no match for any element in the DS hash set in the certificate hash set, the client MUST terminate the connection with an authentication failure as described in [I-D.ietf-tls-tls13]. In this case, the client MUST NOT use DNSSEC-S with this server for this session, and SHOULD NOT try again to use DNSSEC-S with that server until the signature on the DS resource record set has expired. 2.6. Continuing the Authenticated Session After a TLS session is established, the DNS client and the server speak the normal DNS protocol (using the two-octet length extension for TCP) described in [RFC1035], except that the messages go in the TLS connection, not over UDP or TCP. The DNS client treats all authoritative responses from the server as authenticated because they are received in the TLS session. Hoffman & Larson Expires December 30, 2017 [Page 6] Internet-Draft DNSSEC-S June 2017 3. Updates to RFC 4033, 4034, and 4035 *** This section will list specific textual updates to the base DNSSEC-M RFCs to allow for DNSSEC-S. The section might get long; if so, it will be broken into sub-sections for easier commenting. This section is a placeholder for later drafts if this work is adopted. *** o Any authoritative answer from an authoritative server is considered validated if it was obtained with DNSSEC-S. [RFC4035] Section 5 (and maybe 4?). Non-authoritative answers are not considered validated. This will need a careful list of restrictions (Answer section, AA bit set, ...). o A DS record with Digest Type DS-DIGEST-TBD MUST NOT be used for chaining with DNSKEY records. [RFC4034] Section 5. o There are probably other updates. 4. Additional Considerations 4.1. Effect of DNSSEC-S on Resolvers that Only Validate with DNSSEC-M DNSSEC-S is designed to not affect resolvers that only validate with DNSSEC-M. The choice of using DS-DIGEST-TBD in the DS record in the parent will cause a resolver that only knows about DNSSEC-M to think that the child zone is unsigned. Section 5.2 of [RFC4035] says that the following must hold: "The Algorithm and Key Tag in the DS RR match the Algorithm field and the key tag of a DNSKEY RR in the child zone's apex DNSKEY RRset, and, when the DNSKEY RR's owner name and RDATA are hashed using the digest algorithm specified in the DS RR's Digest Type field, the resulting digest value matches the Digest field of the DS RR." A validator that only knows DNSSEC-M will not know how to hash "using the digest algorithm specified in the DS RR's Digest Type field" because it will not know the algorithm for DS-DIGEST-TBD. 4.2. Simultaneous Use of Both DNSSEC-M and DNSSEC-S An authoritative server that uses DNSSEC-S for authentication can also use DNSSEC-M if it wishes. That is, such a server can still answer queries with the DO bit set just as it would have if the queries came over UDP or TCP instead of over TLS. In order to do this, the authoritative server would need at least two DS records in its parent's zone, one for DNSSEC-M and one for DNSSEC-S. Hoffman & Larson Expires December 30, 2017 [Page 7] Internet-Draft DNSSEC-S June 2017 Similarly, a DNS client that is using DNSSEC-S can still request DNSSEC-M records (using the DO bit) and process them as it would if those records were received over UDP or TCP (or out of band). A DNS client may successfully establishes a DNSSEC-S session and receive DNSSEC-M responses that do not validate; the result of such a situation is explicitly undefined in this document. 4.3. Standby Keys An authoritative server can deploy standby keys whose private keys are not in production. To do this, they simply add NS records whose DNSSEC NS Label is the hash of the not-yet-operational public key, and the A or AAAA records for that name point to the same servers as the operational NS records. This scheme will make validators that use DNSSEC-S to be slightly slower because they need to perform one extra decoding per standby key, and possibly one extra SHA-256 hash execution per comparison with certificates from the TLS server. 4.4. DoS Attacks on DNSSEC-S All TLS servers are susceptible to CPU-exhaustion attacks from attackers who can generate traffic that requires the server to do asymmetric computations. Zones that use DNSSEC-S are as susceptible to these denial-of-service attacks as web servers that use HTTPS and mail servers that use SMTPS. TLS 1.3 will be less susceptible to such attacks than earlier versions of TLS, but some attacks are still possible. Note that DNSSEC-M with online signing of DNSSEC records are also susceptible to DoS attacks. This area has not been heavily studied, but it is possible that DNSSEC-S servers will be less susceptible to CPU exhaustion attacks than DNSSEC-M servers that use online signing. 5. Security Considerations *** This section will clearly be much longer before the document is finished. Proposed additions are welcome. *** The security of DNSSEC-S is completely dependent on the ability of DNSSEC-S clients to correctly match the public keys in the TLS certificate messages with the values in the DNSSEC-S NS Labels. A DNSSEC-S client that mis-implements the rules in this protocol is capable of being fooled into validating answers that it should not. An authoritative server that supports both DNSSEC-S and DNSSEC-M, and sends DNSSEC-M records that cause the authoritative answers to not Hoffman & Larson Expires December 30, 2017 [Page 8] Internet-Draft DNSSEC-S June 2017 validate in DNSSEC-M, will likely have nondeterministic results when queried; see Section 4.2. DNSSEC-S is susceptible to denial-of-service attacks that DNSSEC-M using offline signing is not; see Section 4.4. 6. IANA Considerations *** If ALPN is chosen, a template for registering ALPN-TBD will go here. However, if a new port is chosen, a template for registering port PORT-TBD will go here. Only one of these two registrations will appear here. *** *** The template for registering DS-DIGEST-TBD will go here. *** --back 7. References 7.1. Normative References [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-20 (work in progress), April 2017. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . Hoffman & Larson Expires December 30, 2017 [Page 9] Internet-Draft DNSSEC-S June 2017 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [SHA256] National Institute of Standards and Technology, "Secure Hash Standard (SHS), FIPS 180-4", August 2015, . 7.2. Informative References [I-D.ietf-dnsop-terminology-bis] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", draft-ietf-dnsop-terminology-bis-05 (work in progress), March 2017. Authors' Addresses Paul Hoffman ICANN Email: paul.hoffman@icann.org Matt Larson ICANN Email: matt.larson@icann.org Hoffman & Larson Expires December 30, 2017 [Page 10]