Network Working Group D. Zhang Internet-Draft Huawei Intended status: Experimental July 22, 2014 Expires: January 23, 2015 Certificate Transparency for Domain Name System Security Extensions draft-zhang-ct-dnssec-trans-00 Abstract In draft-ietf-trans-rfc6962-bis, a solution is proposed for publicly logging the existence of Transport Layer Security (TLS) certificates using Merkle Hash Trees. This document tries to use this idea in DNSSEC and publicly logging the existence of keys used in securing DNS resource records. Requirements Language 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 [RFC2119]. 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 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 January 23, 2015. Copyright Notice Copyright (c) 2014 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 Zhang Expires January 23, 2015 [Page 1]
Internet-Draft CT-DNSSEC July 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Cryptographic Components of Certificate Transparency . . . . 3 3. Log Format and Operation . . . . . . . . . . . . . . . . . . 3 3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 3 4. Including the Signed Certificate Timestamp into DNS Security Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. SCT RR . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.1. The Key Tag Field . . . . . . . . . . . . . . . . . . 4 4.1.2. The Algorithm Field . . . . . . . . . . . . . . . . . 5 4.1.3. The Digest Type Field . . . . . . . . . . . . . . . . 5 4.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 5 4.1.5. The SCT Field . . . . . . . . . . . . . . . . . . . . 5 4.2. Operations . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6.1. Logging other types of RRs . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction [I-D.ietf-trans-rfc6962-bis] specifies a Certificate Transparency (CT) mechanism to disclosing TLS certificates into public logs so as to benefit the public to monitor the operations in issuing certificates. The logs do not prevent mis-issuing behavior, but the provided public audibility can increase the possibility in detecting certain mis-behaviors of issuers. The logs are constructed with Merkle Hash Trees to ensure the append-only property, and thus enable anyone to verify the correctness of each log and to monitor when new certificates are added to it. Note that CT is a common mechanism although [I-D.ietf-trans-rfc6962-bis] only describe its usage in publishing TLS server certificates issued by public certificate authorities (CAs). This document discusses the application of CT to publicly logging the public keys used by DNSSEC. DNSSEC distributes public keys to provide origin authentication and integrity protection for DNS resource records. In order to prove the validity of keys used for Zhang Expires January 23, 2015 [Page 2]
Internet-Draft CT-DNSSEC July 2014 signing DNS data, DNSSEC uses DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets to form authentication chains for the signed data, with each link in the chains vouching for the next. If an authentication chain can be eventually connected to the a trsuted public key, the client can then ensure the key for signing the data is valid. The application of CT to publish the existence of (DNSKEY) RRsets and (DS) RRsets can benefit the detection of misissurance of DNSSEC keys. For instance, if the owner of foo.example.com finds that its parent zone (example.com) publish a DS RR for its zone which however does not point to any legal zone signing keys or key signing keys, the owner can claim that a mississuance event occures. This work re-use some text in [I-D.ietf-trans-rfc6962-bis]. 2. Cryptographic Components of Certificate Transparency The introduce of cryptographic components of CT is in Section 2 of [I-D.ietf-trans-rfc6962-bis]. When applying CT for NDSSEC, a log is a single, ever-growing, append-only Merkle Tree of DNSKEY and DS RRs. 3. Log Format and Operation When generating a new DNSKEY RR or a DS RR (i.e., during the publication of a KSK or a zone authentication key), a zone owner will publish the RR to the CT logs. Because a key will not be trusted by clients unless logged, it is expected that a zone owner will usually deliver the RRs (keys) for audit purposes. Identical to what is specified in [I-D.ietf-trans-rfc6962-bis],when a valid DNSKEY RR or a valid DS RR is submitted to a log, the log MUST immediately return a Signed Certificate Timestamp (SCT). The SCT is the log's promise to incorporate the RR in the Merkle Tree within a fixed amount of time known as the Maximum Merge Delay (MMD). If the log has previously seen the certificate, it MAY return the same SCT as it returned before. DNS servers MUST provide an SCT from one or more logs to the client within a SCT RR. DNS clients MUST NOT trust a key that does not have a valid SCT. 3.1. Log Entries A zone owner can submit a DNSKEY or DS RR to any log before publishing the RR. In order to enable attribution of each logged RR to its issuer, the log SHALL publish a list of acceptable zone signing public keys (or hashes of public keys) of root zones or islands of security. Each submitted RR MUST be accompanied by all additional RRs (DNSKEY RRs, DS RRs, and RRSIG RRs) which construct an Zhang Expires January 23, 2015 [Page 3]
Internet-Draft CT-DNSSEC July 2014 authentication chain to an accepted root public key. Note that the NSEC RR is not provided since the existence of this type of RR indicates the broken of an authentication chain. A typical authentication chain is Public Key->[DS->(DNSKEY)*->DNSKEY]*->RRset, where "*" denotes zero or more subchains. (DNSKEY)* indicates that DNSSEC permits additional layers of DNSKEY RRs signing other DNSKEY RRs within a zone. Each DNSKEY/DS RR in the chain is authenticated by a RRSIG RR. In practice, a RRSIG RR may be used to sign a DS/DNSKEY RRset rather than a single RR. In this case, not only the DS/DNSKEY RR on the authentication chain but also other records in the RRset SHOULD be provided to the log the verification purpose. Otherwise, the log may have to consult DNS again in order to verify the authentication chains. 4. Including the Signed Certificate Timestamp into DNS Security Extensions 4.1. SCT RR The SCT associated with a DNSKEY/ DS RR is stored within a STC RR. The type number for the DS record is TBD1. The DS resource record is class independent. The DS RR has no special TTL requirements. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | Algorithm | Digest Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / STC / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.1. The Key Tag Field The Key Tag field lists the key tag of the DNSKEY RR referred to by the SCT record, in network byte order. Appendix B of [RFC4034] describes how to compute a Key Tag. Zhang Expires January 23, 2015 [Page 4]
Internet-Draft CT-DNSSEC July 2014 4.1.2. The Algorithm Field The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the SCT record. Appendix A.1 of [RFC4034] lists the algorithm number types. 4.1.3. The Digest Type Field The Digest Type field identifies the algorithm used to construct the digest used to identify the DNSKEY RR that the SCT RR refers to. Appendix A.2 of [RFC4034] lists the possible digest algorithm types. 4.1.4. The Digest Field The method of calculating digest is identical to what is specified in Section 5.1.4 of [RFC4034] 4.1.5. The SCT Field This field contains the SCT got from the log. 4.2. Operations After introducing the SCT RR, the verification procedures of DNS data specified in DNSSEC[RFC4305] do not change a lot. However, the correctness of CTS needs to be assessed during checking the validity of a NDSKEY/DS RR. A NDSKEY/DS RR needs to be associated with a CTS RR which contains a valid CTS and signed with a proper public key. Otherwise, the NDSKEY/DS RR will not be used to construct the authentication chain. The signatures of NDSKEY/DS RR and its CTS RR should be stored in different RRSIG RR respectively. In addition, a DNS server will sends CTS RRs and the associated RRSIG RRs to a resolver only when it indicates the support of CT in the request. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations Zhang Expires January 23, 2015 [Page 5]
Internet-Draft CT-DNSSEC July 2014 6.1. Logging other types of RRs The above section tries to propose a solution to disclose keys for DNSSEC in logs for the public to audit. However, it may be valuable to also log the RRs specified in [RFC1035]. For instance, assume there is an attacker which has compromised the zone authentication key and is able to perform the MITM attack between a resolver and the DNS server of the zone. It is possible for an attacker to transfer a forged RR which is signed with the compromised key. The current solution cannot benefit the detection of this attack in this scenario. However, if the RR is also required to be uploaded to public logs, the condition is changed. If the attacker does not publish the RR to a log, it cannot get the SCT. When the attacker tries to publish the RR to the log, the owner of the zone may detect the problem even if the attacker can provide keys to convince the log to accept the RR. 7. Acknowledgements 8. Normative References [I-D.ietf-trans-rfc6962-bis] Laurie, B., Langley, A., Kasper, E., and R. Stradling, "Certificate Transparency", draft-ietf-trans- rfc6962-bis-04 (work in progress), July 2014. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005. Author's Address Dacheng Zhang Huawei Email: zhangdacheng@huawei.com Zhang Expires January 23, 2015 [Page 6]