Internet-Draft B. Wellington, O. Gudmundsson
DNSSEC Working Group TISLabs
<draft-ietf-dnssec-secfail-00.txt> August 1998
Intermediate Security Failures in DNSSEC
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�
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�
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]