Internet DRAFT - draft-weak-trust-anchor

draft-weak-trust-anchor







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]