idnits 2.17.1 draft-zhang-ct-dnssec-trans-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 59 has weird spacing: '...ponents of Ce...' -- The document date (July 22, 2014) is 3565 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-04 ** Obsolete normative reference: RFC 4305 (Obsoleted by RFC 4835) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Zhang 3 Internet-Draft Huawei 4 Intended status: Experimental July 22, 2014 5 Expires: January 23, 2015 7 Certificate Transparency for Domain Name System Security Extensions 8 draft-zhang-ct-dnssec-trans-00 10 Abstract 12 In draft-ietf-trans-rfc6962-bis, a solution is proposed for publicly 13 logging the existence of Transport Layer Security (TLS) certificates 14 using Merkle Hash Trees. This document tries to use this idea in 15 DNSSEC and publicly logging the existence of keys used in securing 16 DNS resource records. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 23, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Cryptographic Components of Certificate Transparency . . . . 3 60 3. Log Format and Operation . . . . . . . . . . . . . . . . . . 3 61 3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Including the Signed Certificate Timestamp into DNS Security 63 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. SCT RR . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1.1. The Key Tag Field . . . . . . . . . . . . . . . . . . 4 66 4.1.2. The Algorithm Field . . . . . . . . . . . . . . . . . 5 67 4.1.3. The Digest Type Field . . . . . . . . . . . . . . . . 5 68 4.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 5 69 4.1.5. The SCT Field . . . . . . . . . . . . . . . . . . . . 5 70 4.2. Operations . . . . . . . . . . . . . . . . . . . . . . . 5 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 6.1. Logging other types of RRs . . . . . . . . . . . . . . . 6 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 75 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 [I-D.ietf-trans-rfc6962-bis] specifies a Certificate Transparency 81 (CT) mechanism to disclosing TLS certificates into public logs so as 82 to benefit the public to monitor the operations in issuing 83 certificates. The logs do not prevent mis-issuing behavior, but the 84 provided public audibility can increase the possibility in detecting 85 certain mis-behaviors of issuers. The logs are constructed with 86 Merkle Hash Trees to ensure the append-only property, and thus enable 87 anyone to verify the correctness of each log and to monitor when new 88 certificates are added to it. Note that CT is a common mechanism 89 although [I-D.ietf-trans-rfc6962-bis] only describe its usage in 90 publishing TLS server certificates issued by public certificate 91 authorities (CAs). 93 This document discusses the application of CT to publicly logging the 94 public keys used by DNSSEC. DNSSEC distributes public keys to 95 provide origin authentication and integrity protection for DNS 96 resource records. In order to prove the validity of keys used for 97 signing DNS data, DNSSEC uses DNS public key (DNSKEY) RRsets and 98 Delegation Signer (DS) RRsets to form authentication chains for the 99 signed data, with each link in the chains vouching for the next. If 100 an authentication chain can be eventually connected to the a trsuted 101 public key, the client can then ensure the key for signing the data 102 is valid. 104 The application of CT to publish the existence of (DNSKEY) RRsets and 105 (DS) RRsets can benefit the detection of misissurance of DNSSEC keys. 106 For instance, if the owner of foo.example.com finds that its parent 107 zone (example.com) publish a DS RR for its zone which however does 108 not point to any legal zone signing keys or key signing keys, the 109 owner can claim that a mississuance event occures. 111 This work re-use some text in [I-D.ietf-trans-rfc6962-bis]. 113 2. Cryptographic Components of Certificate Transparency 115 The introduce of cryptographic components of CT is in Section 2 of 116 [I-D.ietf-trans-rfc6962-bis]. When applying CT for NDSSEC, a log is 117 a single, ever-growing, append-only Merkle Tree of DNSKEY and DS RRs. 119 3. Log Format and Operation 121 When generating a new DNSKEY RR or a DS RR (i.e., during the 122 publication of a KSK or a zone authentication key), a zone owner will 123 publish the RR to the CT logs. Because a key will not be trusted by 124 clients unless logged, it is expected that a zone owner will usually 125 deliver the RRs (keys) for audit purposes. 127 Identical to what is specified in [I-D.ietf-trans-rfc6962-bis],when a 128 valid DNSKEY RR or a valid DS RR is submitted to a log, the log MUST 129 immediately return a Signed Certificate Timestamp (SCT). The SCT is 130 the log's promise to incorporate the RR in the Merkle Tree within a 131 fixed amount of time known as the Maximum Merge Delay (MMD). If the 132 log has previously seen the certificate, it MAY return the same SCT 133 as it returned before. DNS servers MUST provide an SCT from one or 134 more logs to the client within a SCT RR. DNS clients MUST NOT trust 135 a key that does not have a valid SCT. 137 3.1. Log Entries 139 A zone owner can submit a DNSKEY or DS RR to any log before 140 publishing the RR. In order to enable attribution of each logged RR 141 to its issuer, the log SHALL publish a list of acceptable zone 142 signing public keys (or hashes of public keys) of root zones or 143 islands of security. Each submitted RR MUST be accompanied by all 144 additional RRs (DNSKEY RRs, DS RRs, and RRSIG RRs) which construct an 145 authentication chain to an accepted root public key. Note that the 146 NSEC RR is not provided since the existence of this type of RR 147 indicates the broken of an authentication chain. 149 A typical authentication chain is Public 150 Key->[DS->(DNSKEY)*->DNSKEY]*->RRset, where "*" denotes zero or more 151 subchains. (DNSKEY)* indicates that DNSSEC permits additional layers 152 of DNSKEY RRs signing other DNSKEY RRs within a zone. Each DNSKEY/DS 153 RR in the chain is authenticated by a RRSIG RR. In practice, a RRSIG 154 RR may be used to sign a DS/DNSKEY RRset rather than a single RR. In 155 this case, not only the DS/DNSKEY RR on the authentication chain but 156 also other records in the RRset SHOULD be provided to the log the 157 verification purpose. Otherwise, the log may have to consult DNS 158 again in order to verify the authentication chains. 160 4. Including the Signed Certificate Timestamp into DNS Security 161 Extensions 163 4.1. SCT RR 165 The SCT associated with a DNSKEY/ DS RR is stored within a STC RR. 167 The type number for the DS record is TBD1. 169 The DS resource record is class independent. 171 The DS RR has no special TTL requirements. 173 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Key Tag | Algorithm | Digest Type | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 / / 179 / Digest / 180 / / 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 / / 183 / STC / 184 / / 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 4.1.1. The Key Tag Field 189 The Key Tag field lists the key tag of the DNSKEY RR referred to by 190 the SCT record, in network byte order. Appendix B of [RFC4034] 191 describes how to compute a Key Tag. 193 4.1.2. The Algorithm Field 195 The Algorithm field lists the algorithm number of the DNSKEY RR 196 referred to by the SCT record. Appendix A.1 of [RFC4034] lists the 197 algorithm number types. 199 4.1.3. The Digest Type Field 201 The Digest Type field identifies the algorithm used to construct the 202 digest used to identify the DNSKEY RR that the SCT RR refers to. 203 Appendix A.2 of [RFC4034] lists the possible digest algorithm types. 205 4.1.4. The Digest Field 207 The method of calculating digest is identical to what is specified in 208 Section 5.1.4 of [RFC4034] 210 4.1.5. The SCT Field 212 This field contains the SCT got from the log. 214 4.2. Operations 216 After introducing the SCT RR, the verification procedures of DNS data 217 specified in DNSSEC[RFC4305] do not change a lot. However, the 218 correctness of CTS needs to be assessed during checking the validity 219 of a NDSKEY/DS RR. 221 A NDSKEY/DS RR needs to be associated with a CTS RR which contains a 222 valid CTS and signed with a proper public key. Otherwise, the 223 NDSKEY/DS RR will not be used to construct the authentication chain. 224 The signatures of NDSKEY/DS RR and its CTS RR should be stored in 225 different RRSIG RR respectively. In addition, a DNS server will 226 sends CTS RRs and the associated RRSIG RRs to a resolver only when it 227 indicates the support of CT in the request. 229 5. IANA Considerations 231 This document makes no request of IANA. 233 Note to RFC Editor: this section may be removed on publication as an 234 RFC. 236 6. Security Considerations 237 6.1. Logging other types of RRs 239 The above section tries to propose a solution to disclose keys for 240 DNSSEC in logs for the public to audit. However, it may be valuable 241 to also log the RRs specified in [RFC1035]. For instance, assume 242 there is an attacker which has compromised the zone authentication 243 key and is able to perform the MITM attack between a resolver and the 244 DNS server of the zone. It is possible for an attacker to transfer a 245 forged RR which is signed with the compromised key. The current 246 solution cannot benefit the detection of this attack in this 247 scenario. However, if the RR is also required to be uploaded to 248 public logs, the condition is changed. If the attacker does not 249 publish the RR to a log, it cannot get the SCT. When the attacker 250 tries to publish the RR to the log, the owner of the zone may detect 251 the problem even if the attacker can provide keys to convince the log 252 to accept the RR. 254 7. Acknowledgements 256 8. Normative References 258 [I-D.ietf-trans-rfc6962-bis] 259 Laurie, B., Langley, A., Kasper, E., and R. Stradling, 260 "Certificate Transparency", draft-ietf-trans- 261 rfc6962-bis-04 (work in progress), July 2014. 263 [RFC1035] Mockapetris, P., "Domain names - implementation and 264 specification", STD 13, RFC 1035, November 1987. 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 270 Rose, "Resource Records for the DNS Security Extensions", 271 RFC 4034, March 2005. 273 [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation 274 Requirements for Encapsulating Security Payload (ESP) and 275 Authentication Header (AH)", RFC 4305, December 2005. 277 Author's Address 279 Dacheng Zhang 280 Huawei 282 Email: zhangdacheng@huawei.com