Network Working Group Xiaodong. Lee, Ed. Internet-Draft Haikuo. Zhang, Ed. Intended status: Informational Nan. Wang, Ed. Expires: November 30, 2014 Peng. Zuo, Ed. Xiali. Yan, Ed. Ce. Luo, Ed. Hongtao. Li, Ed. cnnic May 29, 2014 Weak Trust Anchor Introduction draft-weak-trust-anchor-00 Abstract DNS Security Extensions (DNSSEC) is an effective method to provide security protection for resolvers and end users in the DNS protocols. But the DNSSEC is too aggressive for the DNS service in the poor network infrastructure, because the domain name will be invisible when large DNSSEC messages were dropped by some other network equipments, like the routers which have MTU problem or the old firewalls which do not support ENDS0. This document defines a new concept weak trust anchor which can be used on a security-aware resolver to get rid of the above problem. 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 November 30, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Lee, et al. Expires November 30, 2014 [Page 1] Internet-Draft Weak Trust Anchor Introduction May 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Authoritative Name server Considerations . . . . . . . . . . 3 4. Resolver Considerations . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 6 1. Introduction DNSSEC is described in a set of RFC documents, they are [RFC4033][RFC4034] [RFC4035] [RFC4641] [RFC5011] [RFC5155] and so on. DNSKEY has been introduced into signed zone file to help resolvers build a chain of trust. The chain of trust is comprised of some Delegation of Signing (DS) RRs, Key signing Key (KSK) RRs, Zone signing key (ZSK) RRs, traditional RRs(like AAAA RRs), related resource record signatures (RRsig),and so on [RFC4641].NSEC and NSEC3 RR can be used to prove non-existence of domain names in the zone [RFC5155]. The security-aware resolver will verify DNS packets in the recursive query process. If DNS packets are tampered by the man-in-the-middle attack, the resolver will return Servfail to end users. Trust anchor is used as starting point in the chain of trust at the security-aware resolver side. The size of a DNSSEC packet may be larger than 1500 bytes, and EDNS0 protocol has extended the size limitation of the regular DNS packet. But this kind of DNSSEC packets could be lost or dropped in the global network environment, because some routers in the transmission may have MTU problem or some old firewalls could not support ENDS0. Then some domains could be invisible for the end users who are using this security-aware resolver, and this case is out of control for Lee, et al. Expires November 30, 2014 [Page 2] Internet-Draft Weak Trust Anchor Introduction May 2014 ISPs, so this situation may block the DNSSEC deployment at resolver side. Weak trust anchor is introduced to handle this problem. 2. Terms MTU: Maximum Transmission Unit. It is the size of the largest data unit that the layer can pass onwards. Trust Anchor: DNSKEY RR or DS RR hash of a DNSKEY RR, and it is the starting point of the authentication chain in the DNSSEC verification. Described in [RFC4034]. Weak Trust Anchor: Almost same as Trust Anchor, except that Weak Trust Anchor is relatively moderate. The resolver which was configured with Trust Anchor should send DNSSEC queries to Authoritative name servers. It is possible that the DNSSEC message from authoritative name servers was blocked or dropped because of some old network apparatuses which are mentioned above. In this case, recursive name servers would return ServFail responses to stub resolvers due to verification failure. However, the security-aware resolver which is configured with Weak Trust Anchor should send non- DNSSEC queries again to Authoritative name servers to get non-DNSSEC responses when the DNSSEC packets were lost or dropped. If the security-aware resolver gets non-DNSSEC responses, the resolver will send the result to the end user as insecure DNS data. 3. Authoritative Name server Considerations Weak trust anchor is only configured at the resolver side, so it is useless to Authoritative name servers. 4. Resolver Considerations Typically, a security-aware resolver will do the DNSSEC validation in the process of a DNS query. This validation would fail if any DNS message was faked or the DNS packet was dropped in the transmission. With the implementation of DNSSEC, the DNS packet is growing larger and its size would probably exceed 1500 bytes. Although both security-aware resolvers and Authoritative name servers should support EDNS0 to receive and send large packets, the problem still exists because the packet loss possibly happens in some special area in the Internet. In this case, the DNSSEC validation will be failed because of the internet devices, and then the related domain names will be invisible for some end users because the DNSSEC validation failed. Lee, et al. Expires November 30, 2014 [Page 3] Internet-Draft Weak Trust Anchor Introduction May 2014 This document tries to solve this problem with weak trust anchor. If the security-aware resolver was configured with the weak trust anchor, it would do the DNSSEC verification as usual. It takes the responsibilities of recursive requests and the DNSSEC validation. After sending a request with DO bit set, there are three possibilities at the security-aware resolver side: o Receives a DNS packet with DNSSEC information o Receives a DNS packet without DNSSEC information o Receives nothing If the security-aware resolver was configured with weak trust anchor, the DNSSEC verification process is no different from the one with a normal trust anchor in the first two cases. The resolver will use this anchor to do the DNSSEC validation as the rule of [RFC4033][RFC4034] [RFC4035]. Things are different in the third case. If the resolver was configured with a weak trust anchor and got nothing after sending a request with DO bit set, then it should clear DO bit in the EDNS0 in the query message and query again to the authoritative name server. So it could receive a normal DNS message (with no DNSSEC information, if the previous packet loss was caused by large size) and continue its DNS query process, then return the result as an insecure message. The normal process is followed: +------+ +--------------+ +-------------+ | |----a DNS query-> |security-aware|DNSSEC query->|authoritative| |client| | | | name | | | | resolver |<-no packet- -| server | | |<- SERVFAIL answer| | | | +------+ +--------------+ +-------------+ normal process of dnssec query Figure 1 The process of a security- aware resolver with weak trust anchor is shown as below: Lee, et al. Expires November 30, 2014 [Page 4] Internet-Draft Weak Trust Anchor Introduction May 2014 +-------+ +--------------+ +------+ | |--- a DNS query->|security-aware| -DNSSEC query-> |auth | |client | |resolver with | < - - no packet |name | | | a DNS response |weak trust | -normal query-> |server| | |<--message which |anchor | <--a DNS packet-| | +-------+ cleared AD bit +--------------+ +------+ weak trust anchor process of dnssec query Figure 2 5. Security Considerations This document tries to solve the problem that DNSSEC validation may fail in some certain networks because of the packet loss. ISPs could use this protocol to transfer the DNS service to DNSSEC-enabled DNS service when they do not know the complicated network environment. If the DNS packet was tampered in the man-in-the-middle attack, the security-aware resolver will return servfail because of the DNSSEC verification failure in the weak trust anchor protocol. If DNSSEC packets are lost in the flight, the security-aware resolver can use non-DNSSEC process to query the authoritative name server again when it is configured with weak trust anchor, this technique can reduce the loss for the ISPs and end users. 6. Acknowledgments Thanks to jianjun and others who reviewed this draft and give some valuable feedback. 7. References 7.1. Normative 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., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. Lee, et al. Expires November 30, 2014 [Page 5] Internet-Draft Weak Trust Anchor Introduction May 2014 [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. 7.2. Informative References [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006. Authors' Addresses Xiaodong Lee (editor) cnnic EMail: xl@cnnic.cn Haikuo Zhang (editor) cnnic EMail: zhanghaikuo@cnnic.cn Nan Wang (editor) cnnic EMail: wangnan@cnnic.cn Peng Zuo (editor) cnnic EMail: zuopeng@cnnic.cn Xiali Yan (editor) cnnic EMail: yanxiali@cnnic.cn Ce Luo (editor) cnnic EMail: luoce@cnnic.cn Lee, et al. Expires November 30, 2014 [Page 6] Internet-Draft Weak Trust Anchor Introduction May 2014 Hongtao Li (editor) cnnic EMail: lihongtao@cnnic.cn Lee, et al. Expires November 30, 2014 [Page 7]