idnits 2.17.1 draft-haikuo-ckds-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 27 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 6, 2012) is 4342 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 137, but not defined -- Duplicate reference: RFC5011, mentioned in 'RFC4641', was also mentioned in 'RFC5011'. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Haikuo. Zhang 3 Internet-Draft Likun. Zhang 4 Intended status: Informational CNNIC 5 Expires: December 8, 2012 June 6, 2012 7 Compromised-key Digest Signature (CKDS) Introduction and Requirement 8 draft-haikuo-ckds-01 10 Abstract 12 DNS Security Extensions (DNSSEC) is widely deployed at TLD and other 13 important domain names currently. DNSSEC is an effective method to 14 provide security protection for end users in the network. DNSSEC 15 needs a lot of operations to maintain the chain of trust, like DNSKEY 16 rollover operations periodically. But the chain of trust could be 17 broken if the operator of domain replaces the old key immediately in 18 a emergency rollover operation when the key is compromised. The 19 break will make the domain and his sub-domains invisible in a short 20 time if the data in the cache of resolver is right, on the contrary, 21 the fake RR in the cache of resolver may be "valid" if the resolver 22 is under the attack from hackers. This document introduces the 23 compromised-key digest signature (CKDS) resource record to mitigate 24 the impact of invalidation which is due to emergency rollover from 25 the authoritative name server. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 8, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. CKDS Resource Record . . . . . . . . . . . . . . . . . . . 4 64 3. Services Extension . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Service of CKDS . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Backward Compatibility . . . . . . . . . . . . . . . . . . 6 67 4. Authoritative Name server Considerations . . . . . . . . . . . 7 68 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 8 69 6. Emergency rollover with CKDS . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 DNS Security Extensions (DNSSEC) is described detailedly in a set of 78 RFC documents, they are [RFC4033] [RFC4034] [RFC4035] [RFC4641] 79 [RFC5011] [RFC5155] and so on. Two kinds of keys have been 80 introduced into signed zone file to help resolvers generate a chain 81 of trust [RFC4641]. The chain of trust is comprised of some digest 82 signature (DS) resource records, Key signing Key (KSK) resource 83 records, Zone signing key (ZSK) resource records and resource record 84 signatures (RRsig). 86 If the chain of trust is intact for the queried domain name, the 87 secure-aware resolver will set the AD flag in the response message to 88 end users. If the data is altered illegally in authoritative name 89 server, or the data is polluted by data spoofing at the cache of 90 resolver side, the secure-aware resolver will mark the response data 91 "bogus", and then the end user will receive a "server Fail" message. 92 If the domain name is critical for the Internet security, DNSSEC can 93 prevent the end user from being cheated by the illegal data from DNS. 95 Each level of domain names will roll over the DNSKEYs in a certain 96 period or when the Key was compromised if they support DNSSEC at 97 authoritative name server side. For instance KSK could roll over 98 with double-signature algorithm, ZSK could roll over with pre-publish 99 or some other algorithm. 101 However, the resolver could not explicitly distinguish the 102 compromised KSK from the KSKs which are not compromised but will be 103 replaced in the rolling-over process in the current mechanism of 104 DNSSEC. If the resolver can identify which KSK is compromised, the 105 resolver could clean up the related data (e.g. the RRsigs which were 106 signed by the compromised KSK and all of his sub domain data which 107 was verified from the compromised KSK) in the cache as soon as 108 possible to reduce the losses. If the KSK is in the regular rolling 109 over process and is not compromised, the resolver could only update 110 the KSK and his RRsig in the cache. The emergency rolling-over for 111 KSK may lead to more losses at the administrators than hackers if 112 resolver could not identify which DNSKEY is compromised or which one 113 is not. 115 The compromised-key digest signature (CKDS) is introduced to handle 116 this problem above. This type of resource record can be used to 117 distinguish the compromised-key from the other KSKs which are roll 118 over regularly, and help the secure-aware resolver do "the right 119 things" to reduce the losses. 121 2. Terms 123 This section defines one important term for this document. 125 2.1. CKDS Resource Record 127 Compromised-key digest signature (CKDS) is a kind of Resource record 128 similar to DS RR. CKDS and DS are both stored at the parent zone, 129 but the CKDS points at the DNSKEY which has been compromised in the 130 sub domain. If the CKDS RRset exists at the parent zone, this means 131 the DNSKEY which the CKDS points at has been compromised in the zone. 132 The CKDS RRset should be submitted from the administrator of sub 133 domain, and be stored and signed at the parent domain at the zone 134 cut. The RRsig of CKDS in the parent domain could be used to do the 135 verification for the CKDS at the secure-aware resolver. 137 The Type value for the CKDS RR is [TBD]. 139 The format of CKDS looks like DS RR. The CKDS RDATA wire format is 140 as the followed: 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Key Tag | Algorithm | Digest Type | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 / / 147 / Digest / 148 / / 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 The Key Tag Field and the method to compute the key tag in the CKDS 152 are as the same as the DS [RFC4034]. The algorithm number in the 153 RDATA is identical to the algorithm number which is used to make 154 RRsig for the DNSKEY. The Digest Type Field is identical the 155 algorithm of constructing the digest. The Digest Field is calculated 156 as the same as the Digest Field of DS resource record [RFC4034]: 157 Digest = digest_algorithm(DNSKEY owner name | DNSKEY RDATA); 159 "|" means concatenation, and DNSKEY RDATA = Flags|protocol|Algorithm| 160 Public Key 162 It means that the RDATA in the CKDS is as the same as the one in DS 163 if they all point at the same DNSKEY and use the same digest type. 165 3. Services Extension 167 DNSSEC provides a mechanism to maintain an intact chain of trust to 168 verify the response data, find out the polluted data and return the 169 corresponding result to the end users. DNSKEY and this DS Resource 170 record which is stored at the parent domain zone file combine the 171 parent domain and child domain in the chain of trust; the DNSKEY and 172 the RRsig of the RRset in a domain zone file are linked together in 173 chain of trust to verify the RRset. The private portion of Key pair 174 for KSK will sign ZSK resource records, and the public portion of key 175 pair for KSK will be published to validate the ZSK at the resolver 176 side. The private portion of ZSK will sign the other resource record 177 sets (RRsets) at the zone file, and resolver will validate the other 178 RRsets at the zone file by the public portion of ZSK which is 179 validated by the KSK. The digest signature (DS) of the public 180 portion for the KSK will be send to his parent zone file, and the 181 child-domain KSK could be identified with the DS which is stored in 182 the parent side. The resolver should define some trust anchors as 183 the start of the chain of trust. 185 The secure-aware resolver may return "bogus" response message for the 186 DNSSEC query from end user if the chain of trust breaks because of 187 administrator's irregular operation in the Authoritative name server. 188 The phenomenon for the end user is as the same as the data which is 189 polluted by hacker's attack. The broken of trust chain from the 190 upper domain would make more domains invisible, and it may be 191 severely fatal for some important domain name because it will stop 192 the service from the Internet temporarily. 194 3.1. Service of CKDS 196 The administrator of sub-domain should submit a new DS RR which 197 pointed at a new DNSKEY and the CKDS which pointed at the old 198 compromised DNSKEY when he found the old private key compromised. 199 The secure-aware resolver should use other DNSKEY and other DS except 200 the one which the CKDS points at to verify the RRs in the response 201 message. 203 If the CKDS and his RRsig can be verified, all the data (including 204 the sub-domain-related data ) which is related to the compromised 205 DNSKEY should be removed from the cache of resolver. The removed 206 data contains the compromised DNSKEY, the RRsig which is signed by 207 the DNSKEY, and the sub domain data. Then the related data should be 208 queried again. The data in the cache should be flush once during the 209 time of TTL of CKDS. 211 If the other DNSKEY which is not pointed by CKDSs and his related DS 212 exist, it means there is another chain of trust to verify the 213 response data, then the resolver should mark the data "secure" if the 214 other chain of trust is intact. If there are other chains of trust, 215 and all of them could not verify the domain RRsets, the resolver 216 should return "bogus". 218 If there is not any chain of trust else, that means all of DNSKEYs 219 are pointed at by CKDS resource records in the parent domain and 220 there is no available DNSKEY, and then mark "insecure" to the data. 222 3.2. Backward Compatibility 224 The CKDS is extending the current DNSSEC protocols. If CKDS does not 225 exist in the zone file, there is no difference from the current 226 DNSSEC. If the CKDS exists in the zone file, it is compatible to the 227 current DNSSEC when the chain of trust is intact. 229 When the CKDS exists in the parent domain and the CKDS is verified in 230 the resolver side, the resolver should disable the DNSKEY which this 231 CKDS pointed at and the related DS RR. 233 If the CKDS RR could not be verified by the current DNSSEC protocol, 234 the CKDS should be disabled in the resolver side. 236 4. Authoritative Name server Considerations 238 If the CKDS RR was inserted into the zone, it should be signed to 239 create his RR signature. The name server should add CKDS RR and his 240 RRsig in the additional section in the response message if the 241 resolver or end user queries any RR of the domain. 243 There is no difference else to response the query from the name 244 server side. 246 5. Resolver Considerations 248 If got the CKDS RR, the resolver should verify the CKDS using the 249 RRsig of the CKDS and the verified DNSKEY which is used to sign the 250 CKDS at the parent side. If the CKDS is valid, then the resolver 251 should remove all the data about the domain (including the data of 252 his sub-domains) which CKDS pointed at from the cache, except the 253 CKDS. At last, the resolver should make a lookup to the 254 authoritative name server for getting new data. The DS which point 255 at the compromised-key should be disable in the verification process. 257 The resolver should use other DS else and DNSKEY to verify the data 258 from name server. If the chain of trust is intact by using the other 259 DS and DNSKEY, the resolver should mark the response data "secure". 260 If the other DS exists, but all of them verify the relative data 261 failed, the resolver should return "bogus". If no other DS exists in 262 the authoritative name server, the resolver should mark the data 263 "insecure". 265 6. Emergency rollover with CKDS 267 When administrator found his DNSKEY was compromised, he should append 268 a new KSK to the zone of his domain, and then submit a CKDS which 269 points at the compromised key and a new DS which points at the new 270 KSK to this parent domain zone file. 272 It is after the compromised data is cleaned up in the cache of all of 273 resolvers (a TTL of the old DS RR later) that the compromised DNSKEY 274 should be revoked, and then the CKDS and the DS which pointed the 275 compromised key can be removed in the authoritative name server in a 276 short future. The KSK emergency rollover process is followed: 278 ---------------------------------------------------------------------------- 279 initial new-DS new-DNSKEY DNSKEY-revocation DS/DNSKEY-removal 280 ---------------------------------------------------------------------------- 281 Parent side: 282 SOA0 SOA1 ---------------------------> SOA2 283 RRSIGpar(SOA0) RRSIGpar(SOA1) ---------------------------> RRSIGpar(SOA2) 284 DS1 DS1 ---------------------------> DS2 285 DS2 286 RRSIGpar(DS) RRSIGpar(DS) ---------------------------> RRSIGpar(DS) 287 CKDS 288 RRSIGpar(CKDS) 290 Child side: 291 SOA0 --------> SOA1 SOA2 SOA3 292 RRSIG1(SOA0) --------> RRSIG1(SOA1) RRSIG2(SOA2) RRSIG2(SOA3) 293 --------> RRSIG2(SOA1) 294 DNSKEY1 --------> DNSKEY1 DNSKEY1-revoked 295 --------> DNSKEY2 DNSKEY2 DNSKEY2 296 RRSIG1 (DNSKEY) --------> RRSIG1(DNSKEY) RRSIG2 (DNSKEY) RRSIG2(DNSKEY) 297 --------> RRSIG2(DNSKEY) RRSIG1-REVOKE(DNSKEY) 298 ---------------------------------------------------------------------------- 300 The "new-DS" step and "new-DNSKEY" step above can be done at the same 301 time in the above KSK emergency rollover process. 303 This emergency rollover with CKDS can make sure the chain of trust is 304 intact in the resolver side. The chain of trust is showed in the 305 following form. 307 --------------------------------------------------------------------------- 308 | Cache data in the resolver | Chain of trust | 309 -------------------------------------------------------------------------- 310 | Old DS record | compromised KSK which | intact | 311 | | is not revoked | | 312 -------------------------------------------------------------------------- 313 |New DS record, old|New KSK and compromised| intact | 314 |DS record and the |KSK which is not | | 315 | CKDS |revoked | | 316 -------------------------------------------------------------------------- 317 | Old DS record |New KSK and compromised| intact | 318 | |KSK which is not | | 319 | |revoked | | 320 -------------------------------------------------------------------------- 321 |New DS record, old|compromised KSK which |Inexistent case, | 322 |DS record and CKDS|is not revoked |because resolver should flush | 323 | | |the old data in the cache when| 324 | | |it got CKDS | 325 --------------------------------------------------------------------------- 326 7. Security Considerations 328 The TTL of CKDS should have a limit at the resolver side. If the 329 DNSKEY is compromised, and then hackers should create some CKDS RRs 330 for his sub domain with smaller TTL, then the resolver will refresh 331 the cache more frequently if there is no the lower limit setting at 332 the resolver side. 334 It is only once that the data in the cache should be refreshed in the 335 TTL of CKDS, and the TTL of CKDS has a minimum at the resolver side. 337 This method could not remove all the related data in the cache of 338 resolver immediately, because the resolver could not do a lookup 339 until the DS which pointed at the compromised key expires at the 340 cache. But the CKDS could protect the "right" data from being 341 verified failed, and it could push the resolver to refresh the data 342 more quickly in the cache in time in the emergency rolling over 343 process. 345 The CKDS is useless for the trust anchor whose key pair was 346 compromised at the resolver side. 348 8. Acknowledgements 350 The author sincerely acknowledges the assistance and help from the 351 following ones of CNNIC: Wenming Wang, Zhuquan Li and other 352 colleagues who paid attention to this draft. 354 The author also wants to thank Shane Kerr who reviewed this draft and 355 gave profound and valuable feedback. 357 9. References 359 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 360 Rose, "DNS Security Introduction and Requirements", 361 RFC 4033, March 2005. 363 [RFC4034] Arends, R., Larson, M., Massey, D., and S. Rose, "Resource 364 Records for the DNS Security Extensions", RFC 4034, 365 March 2005. 367 [RFC4035] Arends, R., Larson, M., Massey, D., and S. Rose, "Protocol 368 Modifications for the DNS Security Extensions", RFC 4035, 369 March 2005. 371 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 372 Trust Anchors", RFC 5011, September 2007. 374 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 375 Security (DNSSEC) Hashed Authenticated Denial of 376 Existence", RFC 5155, March 2008. 378 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 379 RFC 5011, September 2006. 381 Authors' Addresses 383 Haikuo Zhang 384 China Internet Network Information Center 385 4 South 4th Street,Zhongguancun,Haidian District 386 Beijing, China 100190 388 Phone: +86 10 5881 3163 389 Email: zhanghaikuo@cnnic.cn 391 Likun Zhang 392 China Internet Network Information Center 393 4 South 4th Street,Zhongguancun,Haidian District 394 Beijing, China 100190 396 Fax: +86 10 5881 3250 397 Email: zhanglikun@cnnic.cn