bind/doc/expired/draft-ietf-dnssec-secfail-00.txt

Internet-Draft                             B. Wellington, O. Gudmundsson
DNSSEC Working Group                                             TISLabs
<draft-ietf-dnssec-secfail-00.txt>                           August 1998



                 Intermediate Security Failures in DNSSEC
                    <draft-ietf-dnssec-secfail-00.txt>


  Status of this Memo

     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its areas,
     and its working groups.  Note that other groups may also distribute
     working documents as Internet-Drafts.

     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."

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
     West Coast).

     Distribution of this memo is unlimited.



  Abstract

     This document identifies the situations where a signature
     verification fails in a recursive security aware DNS server, and
     how DNS servers should handle these cases, and the errors that
     should be reported to DNS resolvers.  This document proposes a new
     error to be returned by DNSSEC capable servers.

     A DNSSEC server acting as a recursive server MUST validate the
     signatures on RRsets in a response it passes on; this draft
     addresses the case when the data it receives fails signature











Wellington, Gudmundsson           Expires February 1999         [Page 1]


Internet-Draft            dnssec-secfail-00.txt              August 1998


     verification.  The end resolver must be notified of this occurence
     in such a way that it will not confuse it with another error.



  1. Description

     A DNS [RFC1034, RFC1035] transaction is defined by a query/response
     pair.  The resolver (client) sends a query to a name server.  The
     name server will respond if it contains the necessary information,
     or forward the request to an authoritative server.  The response
     consists of the answer to the query, as well as authority records
     showing that the response came from a valid source, and additional
     records.

     DNSSEC [RFC2065, SECEXT2] adds security to the DNS protocol.  Each
     RRset (set of DNS records with the same name/class/type) is
     digitally signed, and the signature is verified by any server or
     resolver who receives it.  The receiver must therefore have a valid
     key for verifying that data, as specified by a name/footprint pair.
     A key's validity is determined by recursively verifying that it was
     signed by a valid key; this recursion ends when a trusted key is
     reached.  Trusted keys must be obtained out of band, for example
     through manual configuration.

     Consider a recursive name server (R) that forwards a query to
     another server (S).  R receives an response from S, and attempts to
     verify the included RRsets using a key that it trusts.  Note that
     this key may either be implicitly trusted or authenticated.  The
     signature verification fails for one or more RRsets in the answer
     or authority section.  The name server must communicate this error
     in its response.  To do this, a new return code (RCODE) will be
     used, denoted SECFAIL (value TBD).

     When a resolver receives a DNS response with an RCODE of SECFAIL,
     that one of the following is true:
        1) server S has sent invalid data to server R.
        2) the data has been corrupted (possibly maliciously) between R and S.
        3) server R has preconfigured S's key incorrectly.
        4) There is more than one KEY with the same footprint and algorithm
           for that name, and server R contains one different from the one used
           by S to sign the data.  This should not happen.

     None of the current RCODE values sufficiently describe the case
     where the data exists, but cannot be successfully retrieved and/or
     transmitted.  It is the responsibility of both R and the resolver
     to attempt to identify the source of the problem.





Wellington, Gudmundsson           Expires February 1999         [Page 2]


Internet-Draft            dnssec-secfail-00.txt              August 1998


  2. Proposal

     When the recursive name server (R) fails to verify a signed RRset
     in the answer or authority section of a response that it receives,
     it sets the RCODE of the response to SECFAIL before forwarding the
     response to the entity that originated the query.  There are
     several possible modifications that could be made to the data by R:
        1) all records could be passed unchanged
        2) all records could be dropped
        3) only the records that failed verification could be dropped
        4) the SIGs of all records that failed verification could be dropped
     A solution to this problem has not yet been decided.

     If R receives a response with SECFAIL set, it does no processing on
     the response, simply forwarding it if necessary.  An intelligent
     resolver MAY use additional queries to determine which of the
     RRsets was invalid.  The ERR record [ERR] or EDNS [EDNS] could also
     be used to provide a more fine-grained description of the error.

     When R fails to verify an RRset, it can determine whether or not
     the key used has successfully verified other data (a flag or
     timestamp could be stored along with the key).  If it has, then the
     key has not been misconfigured, and the error is due to data
     corruption (possibly malicious) or a data error on the
     authoritative server (S).  R cannot further quantify the problem.
     If the key has never successfully verified data, then the problem
     may be a misconfigured key, or it could be due to malicious
     corruption or a very unreliable network.  In any case, this should
     be logged, and the maintainer of R should determine (out of band)
     whether the preconfigured key is erroneous.  R MAY elect to retry
     the query; this would succeed if the error was due to transient
     network problems or a partial attack.  Unless a retransmission
     yields success, R should always send a response with SECFAIL set.



  3. Limitations

     If the path between a resolver and an authoritative server is
     several hops, there is no way to determine at which recursive
     server the SECFAIL error occurred.  The data will be passed through
     successive servers unchanged.

     There is no way to distinguish a server continuously reporting
     invalid data from an active attack.  For instance, if a server has
     an preconfigured key that is invalid, all queries using that key
     will fail.  An attack could easily simulate this behavior.  There
     is no way to split SECFAIL into more specific errors, since the




Wellington, Gudmundsson           Expires February 1999         [Page 3]


Internet-Draft            dnssec-secfail-00.txt              August 1998


     cause of the error cannot always be determined.



  4. Security Considerations

     Unless transaction signatures of some form are used [RFC2065,
     TSIG], the RCODE field of a DNS response is not protected, so the
     SECFAIL RCODE could be added or stripped by an attacker.



  5. References


[EDNS]     P. Vixie, "Extensions to DNS (EDNS)", Internet
           Draft <draft-ietf-dnsind-edns-02.txt>, March 1998


[ERR]      R. Watson, O. Gudmundsson, "Error Record (ERR)
           for DNS" Internet Draft <draft-ietf-dnsind-dns-
           error-00.txt>, March 1998


[RFC1034]  P. Mockapetris, "Domain Names - Concepts and
           Facilities", RFC 1034, ISI, November 1987.


[RFC1035]  P. Mockapetris, "Domain Names - Implementation
           and Specification", RFC 1034, ISI, November 1987.


[RFC2065]  D. Eastlake, C. Kaufman, "Domain Name System
           Security Extensions", RFC 2065, January 1997.


[SECEXT2]  D. Eastlake, "Domain Name System Security Exten<65>
           sions", Internet Draft <draft-ietf-dnssec-
           secext2-05.txt>, April 1998.


[TSIG]     P. Vixie, O. Gudmundsson, D. Eastlake, "Secret
           Key Transaction Signatures for DNS (TSIG)" Inter<65>
           net Draft <draft-ietf-dnsind-tsig-05.txt>, June
           1998.







Wellington, Gudmundsson           Expires February 1999         [Page 4]


Internet-Draft      dnssec-secfail-00.txt        August 1998


6. Author address

   Brian Wellington, Olafur Gudmundsson
   TIS Labs at Network Associates
   3060 Washington Road
   Glenwood, MD 21738
   +1 301 854 6889
   bwelling@tis.com, ogud@tis.com












































Wellington, Gudmundsson           Expires February 1999         [Page 5]