Network Working Group Haikuo. Zhang Internet-Draft Likun. Zhang Intended status: Informational CNNIC Expires: December 8, 2012 June 6, 2012 Compromised-key Digest Signature (CKDS) Introduction and Requirement draft-haikuo-ckds-01 Abstract DNS Security Extensions (DNSSEC) is widely deployed at TLD and other important domain names currently. DNSSEC is an effective method to provide security protection for end users in the network. DNSSEC needs a lot of operations to maintain the chain of trust, like DNSKEY rollover operations periodically. But the chain of trust could be broken if the operator of domain replaces the old key immediately in a emergency rollover operation when the key is compromised. The break will make the domain and his sub-domains invisible in a short time if the data in the cache of resolver is right, on the contrary, the fake RR in the cache of resolver may be "valid" if the resolver is under the attack from hackers. This document introduces the compromised-key digest signature (CKDS) resource record to mitigate the impact of invalidation which is due to emergency rollover from the authoritative name server. 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 December 8, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang & Zhang Expires December 8, 2012 [Page 1] Internet-Draft CKDS June 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. CKDS Resource Record . . . . . . . . . . . . . . . . . . . 4 3. Services Extension . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Service of CKDS . . . . . . . . . . . . . . . . . . . . . 5 3.2. Backward Compatibility . . . . . . . . . . . . . . . . . . 6 4. Authoritative Name server Considerations . . . . . . . . . . . 7 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 8 6. Emergency rollover with CKDS . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Zhang & Zhang Expires December 8, 2012 [Page 2] Internet-Draft CKDS June 2012 1. Introduction DNS Security Extensions (DNSSEC) is described detailedly in a set of RFC documents, they are [RFC4033] [RFC4034] [RFC4035] [RFC4641] [RFC5011] [RFC5155] and so on. Two kinds of keys have been introduced into signed zone file to help resolvers generate a chain of trust [RFC4641]. The chain of trust is comprised of some digest signature (DS) resource records, Key signing Key (KSK) resource records, Zone signing key (ZSK) resource records and resource record signatures (RRsig). If the chain of trust is intact for the queried domain name, the secure-aware resolver will set the AD flag in the response message to end users. If the data is altered illegally in authoritative name server, or the data is polluted by data spoofing at the cache of resolver side, the secure-aware resolver will mark the response data "bogus", and then the end user will receive a "server Fail" message. If the domain name is critical for the Internet security, DNSSEC can prevent the end user from being cheated by the illegal data from DNS. Each level of domain names will roll over the DNSKEYs in a certain period or when the Key was compromised if they support DNSSEC at authoritative name server side. For instance KSK could roll over with double-signature algorithm, ZSK could roll over with pre-publish or some other algorithm. However, the resolver could not explicitly distinguish the compromised KSK from the KSKs which are not compromised but will be replaced in the rolling-over process in the current mechanism of DNSSEC. If the resolver can identify which KSK is compromised, the resolver could clean up the related data (e.g. the RRsigs which were signed by the compromised KSK and all of his sub domain data which was verified from the compromised KSK) in the cache as soon as possible to reduce the losses. If the KSK is in the regular rolling over process and is not compromised, the resolver could only update the KSK and his RRsig in the cache. The emergency rolling-over for KSK may lead to more losses at the administrators than hackers if resolver could not identify which DNSKEY is compromised or which one is not. The compromised-key digest signature (CKDS) is introduced to handle this problem above. This type of resource record can be used to distinguish the compromised-key from the other KSKs which are roll over regularly, and help the secure-aware resolver do "the right things" to reduce the losses. Zhang & Zhang Expires December 8, 2012 [Page 3] Internet-Draft CKDS June 2012 2. Terms This section defines one important term for this document. 2.1. CKDS Resource Record Compromised-key digest signature (CKDS) is a kind of Resource record similar to DS RR. CKDS and DS are both stored at the parent zone, but the CKDS points at the DNSKEY which has been compromised in the sub domain. If the CKDS RRset exists at the parent zone, this means the DNSKEY which the CKDS points at has been compromised in the zone. The CKDS RRset should be submitted from the administrator of sub domain, and be stored and signed at the parent domain at the zone cut. The RRsig of CKDS in the parent domain could be used to do the verification for the CKDS at the secure-aware resolver. The Type value for the CKDS RR is [TBD]. The format of CKDS looks like DS RR. The CKDS RDATA wire format is as the followed: 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 / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Key Tag Field and the method to compute the key tag in the CKDS are as the same as the DS [RFC4034]. The algorithm number in the RDATA is identical to the algorithm number which is used to make RRsig for the DNSKEY. The Digest Type Field is identical the algorithm of constructing the digest. The Digest Field is calculated as the same as the Digest Field of DS resource record [RFC4034]: Digest = digest_algorithm(DNSKEY owner name | DNSKEY RDATA); "|" means concatenation, and DNSKEY RDATA = Flags|protocol|Algorithm| Public Key It means that the RDATA in the CKDS is as the same as the one in DS if they all point at the same DNSKEY and use the same digest type. Zhang & Zhang Expires December 8, 2012 [Page 4] Internet-Draft CKDS June 2012 3. Services Extension DNSSEC provides a mechanism to maintain an intact chain of trust to verify the response data, find out the polluted data and return the corresponding result to the end users. DNSKEY and this DS Resource record which is stored at the parent domain zone file combine the parent domain and child domain in the chain of trust; the DNSKEY and the RRsig of the RRset in a domain zone file are linked together in chain of trust to verify the RRset. The private portion of Key pair for KSK will sign ZSK resource records, and the public portion of key pair for KSK will be published to validate the ZSK at the resolver side. The private portion of ZSK will sign the other resource record sets (RRsets) at the zone file, and resolver will validate the other RRsets at the zone file by the public portion of ZSK which is validated by the KSK. The digest signature (DS) of the public portion for the KSK will be send to his parent zone file, and the child-domain KSK could be identified with the DS which is stored in the parent side. The resolver should define some trust anchors as the start of the chain of trust. The secure-aware resolver may return "bogus" response message for the DNSSEC query from end user if the chain of trust breaks because of administrator's irregular operation in the Authoritative name server. The phenomenon for the end user is as the same as the data which is polluted by hacker's attack. The broken of trust chain from the upper domain would make more domains invisible, and it may be severely fatal for some important domain name because it will stop the service from the Internet temporarily. 3.1. Service of CKDS The administrator of sub-domain should submit a new DS RR which pointed at a new DNSKEY and the CKDS which pointed at the old compromised DNSKEY when he found the old private key compromised. The secure-aware resolver should use other DNSKEY and other DS except the one which the CKDS points at to verify the RRs in the response message. If the CKDS and his RRsig can be verified, all the data (including the sub-domain-related data ) which is related to the compromised DNSKEY should be removed from the cache of resolver. The removed data contains the compromised DNSKEY, the RRsig which is signed by the DNSKEY, and the sub domain data. Then the related data should be queried again. The data in the cache should be flush once during the time of TTL of CKDS. If the other DNSKEY which is not pointed by CKDSs and his related DS exist, it means there is another chain of trust to verify the Zhang & Zhang Expires December 8, 2012 [Page 5] Internet-Draft CKDS June 2012 response data, then the resolver should mark the data "secure" if the other chain of trust is intact. If there are other chains of trust, and all of them could not verify the domain RRsets, the resolver should return "bogus". If there is not any chain of trust else, that means all of DNSKEYs are pointed at by CKDS resource records in the parent domain and there is no available DNSKEY, and then mark "insecure" to the data. 3.2. Backward Compatibility The CKDS is extending the current DNSSEC protocols. If CKDS does not exist in the zone file, there is no difference from the current DNSSEC. If the CKDS exists in the zone file, it is compatible to the current DNSSEC when the chain of trust is intact. When the CKDS exists in the parent domain and the CKDS is verified in the resolver side, the resolver should disable the DNSKEY which this CKDS pointed at and the related DS RR. If the CKDS RR could not be verified by the current DNSSEC protocol, the CKDS should be disabled in the resolver side. Zhang & Zhang Expires December 8, 2012 [Page 6] Internet-Draft CKDS June 2012 4. Authoritative Name server Considerations If the CKDS RR was inserted into the zone, it should be signed to create his RR signature. The name server should add CKDS RR and his RRsig in the additional section in the response message if the resolver or end user queries any RR of the domain. There is no difference else to response the query from the name server side. Zhang & Zhang Expires December 8, 2012 [Page 7] Internet-Draft CKDS June 2012 5. Resolver Considerations If got the CKDS RR, the resolver should verify the CKDS using the RRsig of the CKDS and the verified DNSKEY which is used to sign the CKDS at the parent side. If the CKDS is valid, then the resolver should remove all the data about the domain (including the data of his sub-domains) which CKDS pointed at from the cache, except the CKDS. At last, the resolver should make a lookup to the authoritative name server for getting new data. The DS which point at the compromised-key should be disable in the verification process. The resolver should use other DS else and DNSKEY to verify the data from name server. If the chain of trust is intact by using the other DS and DNSKEY, the resolver should mark the response data "secure". If the other DS exists, but all of them verify the relative data failed, the resolver should return "bogus". If no other DS exists in the authoritative name server, the resolver should mark the data "insecure". Zhang & Zhang Expires December 8, 2012 [Page 8] Internet-Draft CKDS June 2012 6. Emergency rollover with CKDS When administrator found his DNSKEY was compromised, he should append a new KSK to the zone of his domain, and then submit a CKDS which points at the compromised key and a new DS which points at the new KSK to this parent domain zone file. It is after the compromised data is cleaned up in the cache of all of resolvers (a TTL of the old DS RR later) that the compromised DNSKEY should be revoked, and then the CKDS and the DS which pointed the compromised key can be removed in the authoritative name server in a short future. The KSK emergency rollover process is followed: ---------------------------------------------------------------------------- initial new-DS new-DNSKEY DNSKEY-revocation DS/DNSKEY-removal ---------------------------------------------------------------------------- Parent side: SOA0 SOA1 ---------------------------> SOA2 RRSIGpar(SOA0) RRSIGpar(SOA1) ---------------------------> RRSIGpar(SOA2) DS1 DS1 ---------------------------> DS2 DS2 RRSIGpar(DS) RRSIGpar(DS) ---------------------------> RRSIGpar(DS) CKDS RRSIGpar(CKDS) Child side: SOA0 --------> SOA1 SOA2 SOA3 RRSIG1(SOA0) --------> RRSIG1(SOA1) RRSIG2(SOA2) RRSIG2(SOA3) --------> RRSIG2(SOA1) DNSKEY1 --------> DNSKEY1 DNSKEY1-revoked --------> DNSKEY2 DNSKEY2 DNSKEY2 RRSIG1 (DNSKEY) --------> RRSIG1(DNSKEY) RRSIG2 (DNSKEY) RRSIG2(DNSKEY) --------> RRSIG2(DNSKEY) RRSIG1-REVOKE(DNSKEY) ---------------------------------------------------------------------------- The "new-DS" step and "new-DNSKEY" step above can be done at the same time in the above KSK emergency rollover process. This emergency rollover with CKDS can make sure the chain of trust is intact in the resolver side. The chain of trust is showed in the following form. Zhang & Zhang Expires December 8, 2012 [Page 9] Internet-Draft CKDS June 2012 --------------------------------------------------------------------------- | Cache data in the resolver | Chain of trust | -------------------------------------------------------------------------- | Old DS record | compromised KSK which | intact | | | is not revoked | | -------------------------------------------------------------------------- |New DS record, old|New KSK and compromised| intact | |DS record and the |KSK which is not | | | CKDS |revoked | | -------------------------------------------------------------------------- | Old DS record |New KSK and compromised| intact | | |KSK which is not | | | |revoked | | -------------------------------------------------------------------------- |New DS record, old|compromised KSK which |Inexistent case, | |DS record and CKDS|is not revoked |because resolver should flush | | | |the old data in the cache when| | | |it got CKDS | --------------------------------------------------------------------------- Zhang & Zhang Expires December 8, 2012 [Page 10] Internet-Draft CKDS June 2012 7. Security Considerations The TTL of CKDS should have a limit at the resolver side. If the DNSKEY is compromised, and then hackers should create some CKDS RRs for his sub domain with smaller TTL, then the resolver will refresh the cache more frequently if there is no the lower limit setting at the resolver side. It is only once that the data in the cache should be refreshed in the TTL of CKDS, and the TTL of CKDS has a minimum at the resolver side. This method could not remove all the related data in the cache of resolver immediately, because the resolver could not do a lookup until the DS which pointed at the compromised key expires at the cache. But the CKDS could protect the "right" data from being verified failed, and it could push the resolver to refresh the data more quickly in the cache in time in the emergency rolling over process. The CKDS is useless for the trust anchor whose key pair was compromised at the resolver side. Zhang & Zhang Expires December 8, 2012 [Page 11] Internet-Draft CKDS June 2012 8. Acknowledgements The author sincerely acknowledges the assistance and help from the following ones of CNNIC: Wenming Wang, Zhuquan Li and other colleagues who paid attention to this draft. The author also wants to thank Shane Kerr who reviewed this draft and gave profound and valuable feedback. Zhang & Zhang Expires December 8, 2012 [Page 12] Internet-Draft CKDS June 2012 9. References [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 5011, September 2006. Zhang & Zhang Expires December 8, 2012 [Page 13] Internet-Draft CKDS June 2012 Authors' Addresses Haikuo Zhang China Internet Network Information Center 4 South 4th Street,Zhongguancun,Haidian District Beijing, China 100190 Phone: +86 10 5881 3163 Email: zhanghaikuo@cnnic.cn Likun Zhang China Internet Network Information Center 4 South 4th Street,Zhongguancun,Haidian District Beijing, China 100190 Fax: +86 10 5881 3250 Email: zhanglikun@cnnic.cn Zhang & Zhang Expires December 8, 2012 [Page 14]