mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-09-01 06:55:30 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2005-09-02 01:33:00 +00:00
parent ff48eb4768
commit 1d24d9f5c9
12 changed files with 7332 additions and 2656 deletions
Download Patch File Download Diff File Expand all files Collapse all files

928
doc/draft/draft-ietf-dnsext-2929bis-01.txt Normal file
View File

@@ -0,0 +1,928 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories
Expires: February 2006 August 2005
Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
<draft-ietf-dnsext-2929bis-01.txt>
Status of This Document
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Distribution of this draft is unlimited. It is intended to become
the new BCP 42 obsoleting RFC 2929. Comments should be sent to the
DNS Working Group mailing list <namedroppers@ops.ietf.org>.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Internet Assigned Number Authority (IANA) parameter assignment
considerations are given for the allocation of Domain Name System
(DNS) classes, RR types, operation codes, error codes, RR header
bits, and AFSDB subtypes.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DNS IANA Considerations August 2005
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. DNS Query/Response Headers..............................3
2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................4
2.3 RCODE Assignment.......................................5
3. DNS Resource Records....................................6
3.1 RR TYPE IANA Considerations............................7
3.1.1 DNS TYPE Allocation Policy...........................8
3.1.2 Special Note on the OPT RR...........................9
3.1.3 The AFSDB RR Subtype Field...........................9
3.2 RR CLASS IANA Considerations...........................9
3.3 RR NAME Considerations................................11
4. Security Considerations................................11
Appendix: Changes from RFC 2929...........................12
Copyright and Disclaimer..................................13
Normative References......................................13
Informative References....................................14
Authors Addresses.........................................16
Expiration and File Name..................................16
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DNS IANA Considerations August 2005
1. Introduction
The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchically store "resource records"
(RRs) under domain names. DNS data is structured into CLASSes and
zones which can be independently maintained. See [RFC 1034, 1035,
2136, 2181, 4033] familiarity with which is assumed.
This document provides, either directly or by reference, general IANA
parameter assignment considerations applying across DNS query and
response headers and all RRs. There may be additional IANA
considerations that apply to only a particular RR type or
query/response opcode. See the specific RFC defining that RR type or
query/response opcode for such considerations if they have been
defined, except for AFSDB RR considerations [RFC 1183] which are
included herein. This RFC obsoletes [RFC 2929].
IANA currently maintains a web page of DNS parameters. See
<http://www.iana.org/numbers.htm>.
"IETF Standards Action", "IETF Consensus", "Specification Required",
and "Private Use" are as defined in [RFC 2434].
2. DNS Query/Response Headers
The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136, 2929]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so
they can be matched.
The QR bit indicates whether the header is for a query or a response.
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS IANA Considerations August 2005
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous given existing
implementation. Such meanings may only be assigned by an IETF
Standards Action.
The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
authority count (NSCOUNT), and additional information count (ARCOUNT)
express the number of records in each section for all opcodes except
Update. These fields have the same structure and data type for
Update but are instead the counts for the zone (ZOCOUNT),
prerequisite (PRCOUNT), update (UPCOUNT), and additional information
(ARCOUNT) sections.
2.1 One Spare Bit?
There have been ancient DNS implementations for which the Z bit being
on in a query meant that only a response from the primary server for
a zone is acceptable. It is believed that current DNS
implementations ignore this bit.
Assigning a meaning to the Z bit requires an IETF Standards Action.
2.2 Opcode Assignment
Currently DNS OpCodes are assigned as follows:
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query, Obsolete) [RFC 3425]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
New OpCode assignments require an IETF Standards Action as modified
by [RFC 4020].
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DNS IANA Considerations August 2005
2.3 RCODE Assignment
It would appear from the DNS header above that only four bits of
RCODE, or response/error code are available. However, RCODEs can
appear not only at the top level of a DNS response but also inside
OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
The OPT RR provides an eight bit extension resulting in a 12 bit
RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
Error codes appearing in the DNS header and in these three RR types
all refer to the same error code space with the single exception of
error code 16 which has a different meaning in the OPT RR from its
meaning in other contexts. See table below.
RCODE Name Description Reference
Decimal
Hexadecimal
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11 - 15 Available for assignment
16 BADVERS Bad OPT Version [RFC 2671]
16 BADSIG TSIG Signature Failure [RFC 2845]
17 BADKEY Key not recognized [RFC 2845]
18 BADTIME Signature out of time window [RFC 2845]
19 BADMODE Bad TKEY Mode [RPC 2930]
20 BADNAME Duplicate key name [RPF 2930]
21 BADALG Algorithm not supported [RPF 2930]
22 - 3,840
0x0016 - 0x0F00 Available for assignment
3,841 - 4,095
0x0F01 - 0x0FFF Private Use
4,096 - 65,534
0x1000 - 0xFFFE Available for assignment
65,535
0xFFFF Reserved, can only be allocated by an IETF
Standards Action.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS IANA Considerations August 2005
Since it is important that RCODEs be understood for interoperability,
assignment of new RCODE listed above as "available for assignment"
requires an IETF Consensus.
3. DNS Resource Records
All RRs have the same top level format shown in the figure below
taken from [RFC 1035]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this
resource record pertains. NAMEs are specific to a CLASS as described
in section 3.2. NAMEs consist of an ordered sequence of one or more
labels each of which has a label type [RFC 1035, 2671].
TYPE is a two octet unsigned integer containing one of the RR TYPE
codes. See section 3.1.
CLASS is a two octet unsigned integer containing one of the RR CLASS
codes. See section 3.2.
TTL is a four octet (32 bit) bit unsigned integer that specifies the
number of seconds that the resource record may be cached before the
source of the information should again be consulted. Zero is
interpreted to mean that the RR can only be used for the transaction
in progress.
RDLENGTH is an unsigned 16 bit integer that specifies the length in
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS IANA Considerations August 2005
octets of the RDATA field.
RDATA is a variable length string of octets that constitutes the
resource. The format of this information varies according to the TYPE
and in some cases the CLASS of the resource record.
3.1 RR TYPE IANA Considerations
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
and MetaTYPEs.
Data TYPEs are the primary means of storing data. QTYPES can only be
used in queries. Meta-TYPEs designate transient data associated with
an particular DNS message and in some cases can also be used in
queries. Thus far, data TYPEs have been assigned from 1 upwards plus
the block from 100 through 103 while Q and Meta Types have been
assigned from 255 downwards except for the OPT Meta-RR which is
assigned TYPE 41. There have been DNS implementations which made
caching decisions based on the top bit of the bottom byte of the RR
TYPE.
There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
[RFC 2845], and TKEY [RFC 2930].
There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
AXFR, and IXFR.
Considerations for the allocation of new RR TYPEs are as follows:
Decimal
Hexadecimal
0
0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
2535] and in other circumstances and must never be allocated
for ordinary use.
1 - 127
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
TYPEs by the DNS TYPE Allocation Policy as specified in
section 3.1.1.
128 - 255
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs by the DNS TYPE Allocation Policy as specified in
section 3.1.1.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DNS IANA Considerations August 2005
256 - 32,767
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
TYPE Allocation Policy as specified in section 3.1.1.
32,768 - 65,279
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
65,280 - 65534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
3.1.1 DNS TYPE Allocation Policy
Parameter values specified above as assigned based on DNS TYPE
Allocation Policy. That is, Expert Review with the additional
requirement that the review be based on a complete template as
specified below which has been posted for three weeks to the
namedroppers@ops.ietf.org mailing list.
Partial or draft templates may be posted with the intend of
soliciting feedback.
DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
Date:
Name and email of originator:
Pointer to internet-draft or other document giving a detailed
description of the protocol use of the new RR Type:
What need is the new RR TYPE intended to fix?
What existing RR TYPE(s) come closest to filling that need and why are
they unsatisfactory?
Does the proposed RR TYPR require special handling within the DNS
different from an Unknown RR TYPE?
Comments:
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT DNS IANA Considerations August 2005
3.1.2 Special Note on the OPT RR
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
primary purpose is to extend the effective field size of various DNS
fields including RCODE, label type, OpCode, flag bits, and RDATA
size. In particular, for resolvers and servers that recognize it, it
extends the RCODE field from 4 to 12 bits.
3.1.3 The AFSDB RR Subtype Field
The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
RDATA field structure as the MX RR but the 16 bit unsigned integer
field at the beginning of the RDATA is interpreted as a subtype as
follows:
Decimal
Hexadecimal
0
0x0000 - Allocation requires IETF Standards Action.
1
0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
2
0x0002 - DCE/NCA root cell directory node [RFC 1183].
3 - 65,279
0x0003 - 0xFEFF - Allocation by IETF Consensus.
65,280 - 65,534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, allocation requires IETF Standards Action.
3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the name space or root servers for one CLASS and
those for another CLASS. The same name can have completely different
meanings in different CLASSes; however, the label types are the same
and the null label is usable only as root in every CLASS. However,
as global networking and DNS have evolved, the IN, or Internet, CLASS
has dominated DNS use.
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT DNS IANA Considerations August 2005
There are two subcategories of DNS CLASSes: normal data containing
classes and QCLASSes that are only meaningful in queries or updates.
The current CLASS assignments and considerations for future
assignments are as follows:
Decimal
Hexadecimal
0
0x0000 - Reserved, assignment requires an IETF Standards Action.
1
0x0001 - Internet (IN).
2
0x0002 - Available for assignment by IETF Consensus as a data CLASS.
3
0x0003 - Chaos (CH) [Moon 1981].
4
0x0004 - Hesiod (HS) [Dyer 1987].
5 - 127
0x0005 - 0x007F - available for assignment by IETF Consensus for data
CLASSes only.
128 - 253
0x0080 - 0x00FD - available for assignment by IETF Consensus for
QCLASSes only.
254
0x00FE - QCLASS None [RFC 2136].
255
0x00FF - QCLASS Any [RFC 1035].
256 - 32,767
0x0100 - 0x7FFF - Assigned by IETF Consensus.
32,768 - 65,279
0x8000 - 0xFEFF - Assigned based on Specification Required as defined
in [RFC 2434].
65,280 - 65,534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
D. Eastlake 3rd [Page 10]
INTERNET-DRAFT DNS IANA Considerations August 2005
3.3 RR NAME Considerations
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
NAME is "ROOT" which is the zero length label. By definition, the
null or ROOT label can not be used for any other NAME purpose.
At the present time, there are two categories of label types, data
labels and compression labels. Compression labels are pointers to
data labels elsewhere within an RR or DNS message and are intended to
shorten the wire encoding of NAMEs. The two existing data label
types are sometimes referred to as Text and Binary. Text labels can,
in fact, include any octet value including zero value octets but most
current uses involve only [US-ASCII]. For retrieval, Text labels are
defined to treat ASCII upper and lower case letter codes as matching
[insensitive]. Binary labels are bit sequences [RFC 2673]. The
Binary label type is Experimental [RFC 3363].
IANA considerations for label types are given in [RFC 2671].
NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
1981] CLASSes are essentially for local use. The IN or Internet
CLASS is thus the only DNS CLASS in global use on the Internet at
this time.
A somewhat out-of-date description of name allocation in the IN Class
is given in [RFC 1591]. Some information on reserved top level
domain names is in BCP 32 [RFC 2606].
4. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 4033, 4034, 4035] for
secure DNS considerations.
D. Eastlake 3rd [Page 11]
INTERNET-DRAFT DNS IANA Considerations August 2005
Appendix: Changes from RFC 2929
RFC Editor: This Appendix should be deleted for publication.
Changes from RFC 2929 to this draft:
1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
Allocation Policy" and add the specification of that policy. Change
some remaining "IETF Standards Action" allocation requirements to say
"as modified by [RFC 4020]".
2. Updated various RFC references.
3. Mentioned that the Binary label type is now Experimental and
IQuery is Obsolete.
4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
IETF Standards Action required.
5. Add an IANA allocation policy for the AFSDB RR Subtype field.
6. Addition of reference to case insensitive draft.
D. Eastlake 3rd [Page 12]
INTERNET-DRAFT DNS IANA Considerations August 2005
Copyright and Disclaimer
Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Normative References
[RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
[RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
D. Eastlake 3rd [Page 13]
INTERNET-DRAFT DNS IANA Considerations August 2005
[RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", September 2000.
[RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
2002.
[RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York, 1968.
Informative References
[Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
Technical Plan - Name Service, April 1987,
[Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June
1981.
[RFC 1591] - Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
September 2000.
[RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", RFC 2606, June 1999.
[insensitive] - Eastlake, D., "Domain Name System (DNS) Case
D. Eastlake 3rd [Page 14]
INTERNET-DRAFT DNS IANA Considerations August 2005
Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
work in progress.
D. Eastlake 3rd [Page 15]
INTERNET-DRAFT DNS IANA Considerations August 2005
Authors Addresses
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-786-7554 (w)
email: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires February 2006.
Its file name is draft-ietf-dnsext-2929bis-01.txt.
D. Eastlake 3rd [Page 16]

1397
doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt Normal file
View File

File diff suppressed because it is too large Load Diff

616
doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt Normal file
View File

@@ -0,0 +1,616 @@
Network Working Group S. Weiler
Internet-Draft SPARTA, Inc
Updates: 4034, 4035 (if approved) May 23, 2005
Expires: November 24, 2005
Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document is a collection of minor technical clarifications to
the DNSSECbis document set. It is meant to serve as a resource to
implementors as well as an interim repository of possible DNSSECbis
errata.
Weiler Expires November 24, 2005 [Page 1]
Internet-Draft DNSSECbis Implementation Notes May 2005
Proposed additions in future versions
An index sorted by the section of DNSSECbis being clarified.
A list of proposed protocol changes being made in other documents,
such as NSEC3 and Epsilon. This document would not make those
changes, merely provide an index into the documents that are making
changes.
Changes between -00 and -01
Document significantly restructured.
Added section on QTYPE=ANY.
Changes between personal submission and first WG draft
Added Section 2.1 based on namedroppers discussions from March 9-10,
2005.
Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
Added the DNSSECbis RFC numbers.
Figured out the confusion in Section 4.1.
Weiler Expires November 24, 2005 [Page 2]
Internet-Draft DNSSECbis Implementation Notes May 2005
Table of Contents
1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
1.1 Structure of this Document . . . . . . . . . . . . . . . . 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4
2.1 Clarifications on Non-Existence Proofs . . . . . . . . . . 4
2.2 Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5
2.3 Validating Responses to an ANY Query . . . . . . . . . . . 5
3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
3.1 Unknown DS Message Digest Algorithms . . . . . . . . . . . 5
3.2 Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
3.3 Caution About Local Policy and Multiple RRSIGs . . . . . . 6
3.4 Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7
4.1 Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7
4.2 Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7
4.3 Errors in Examples . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Normative References . . . . . . . . . . . . . . . . . . . 8
7.2 Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 11
Weiler Expires November 24, 2005 [Page 3]
Internet-Draft DNSSECbis Implementation Notes May 2005
1. Introduction and Terminology
This document lists some minor clarifications and corrections to
DNSSECbis, as described in [1], [2], and [3].
It is intended to serve as a resource for implementors and as a
repository of items that need to be addressed when advancing the
DNSSECbis documents from Proposed Standard to Draft Standard.
In this version (-01 of the WG document), feedback is particularly
solicited on the structure of the document and whether the text in
the recently added sections is correct and sufficient.
Proposed substantive additions to this document should be sent to the
namedroppers mailing list as well as to the editor of this document.
The editor would greatly prefer text suitable for direct inclusion in
this document.
1.1 Structure of this Document
The clarifications to DNSSECbis are sorted according to the editor's
impression of their importance, starting with ones which could, if
ignored, lead to security and stability problems and progressing down
to clarifications that are likely to have little operational impact.
Mere typos and awkward phrasings are not addressed unless they could
lead to misinterpretation of the DNSSECbis documents.
1.2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
2. Significant Concerns
This section provides clarifications that, if overlooked, could lead
to security issues or major interoperability problems.
2.1 Clarifications on Non-Existence Proofs
RFC4035 Section 5.4 slightly underspecifies the algorithm for
checking non-existence proofs. In particular, the algorithm there
might incorrectly allow the NSEC from the parent side of a zone cut
to prove the non-existence of either other RRs at that name in the
child zone or other names in the child zone. It might also allow a
NSEC at the same name as a DNAME to prove the non-existence of names
beneath that DNAME.
Weiler Expires November 24, 2005 [Page 4]
Internet-Draft DNSSECbis Implementation Notes May 2005
A parent-side delegation NSEC (one with the NS bit set, but no SOA
bit set, and with a singer field that's shorter than the owner name)
must not be used to assume non-existence of any RRs below that zone
cut (both RRs at that ownername and at ownernames with more leading
labels, no matter their content). Similarly, an NSEC with the DNAME
bit set must not be used to assume the non-existence of any
descendant of that NSEC's owner name.
2.2 Empty Non-Terminal Proofs
To be written, based on Roy Arends' May 11th message to namedroppers.
2.3 Validating Responses to an ANY Query
RFC4035 does not address now to validate responses when QTYPE=*. As
described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
may include a subset of the RRsets at a given name -- it is not
necessary to include all RRsets at the QNAME in the response.
When validating a response to QTYPE=*, validate all received RRsets
that match QNAME and QCLASS. If any of those RRsets fail validation,
treat the answer as Bogus. If there are no RRsets matching QNAME and
QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
clarified in this document). To be clear, a validator must not
insist on receiving all records at the QNAME in response to QTYPE=*.
3. Interoperability Concerns
3.1 Unknown DS Message Digest Algorithms
Section 5.2 of RFC4035 includes rules for how to handle delegations
to zones that are signed with entirely unsupported algorithms, as
indicated by the algorithms shown in those zone's DS RRsets. It does
not explicitly address how to handle DS records that use unsupported
message digest algorithms. In brief, DS records using unknown or
unsupported message digest algorithms MUST be treated the same way as
DS records referring to DNSKEY RRs of unknown or unsupported
algorithms.
The existing text says:
If the validator does not support any of the algorithms listed
in an authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
Weiler Expires November 24, 2005 [Page 5]
Internet-Draft DNSSECbis Implementation Notes May 2005
To paraphrase the above, when determining the security status of a
zone, a validator discards (for this purpose only) any DS records
listing unknown or unsupported algorithms. If none are left, the
zone is treated as if it were unsigned.
Modified to consider DS message digest algorithms, a validator also
discards any DS records using unknown or unsupported message digest
algorithms.
3.2 Private Algorithms
As discussed above, section 5.2 of RFC4035 requires that validators
make decisions about the security status of zones based on the public
key algorithms shown in the DS records for those zones. In the case
of private algorithms, as described in RFC4034 Appendix A.1.1, the
eight-bit algorithm field in the DS RR is not conclusive about what
algorithm(s) is actually in use.
If no private algorithms appear in the DS set or if any supported
algorithm appears in the DS set, no special processing will be
needed. In the remaining cases, the security status of the zone
depends on whether or not the resolver supports any of the private
algorithms in use (provided that these DS records use supported hash
functions, as discussed in Section 3.1). In these cases, the
resolver MUST retrieve the corresponding DNSKEY for each private
algorithm DS record and examine the public key field to determine the
algorithm in use. The security-aware resolver MUST ensure that the
hash of the DNSKEY RR's owner name and RDATA matches the digest in
the DS RR. If they do not match, and no other DS establishes that
the zone is secure, the referral should be considered BAD data, as
discussed in RFC4035.
This clarification facilitates the broader use of private algorithms,
as suggested by [5].
3.3 Caution About Local Policy and Multiple RRSIGs
When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
suggests that "the local resolver security policy determines whether
the resolver also has to test these RRSIG RRs and how to resolve
conflicts if these RRSIG RRs lead to differing results." In most
cases, a resolver would be well advised to accept any valid RRSIG as
sufficient. If the first RRSIG tested fails validation, a resolver
would be well advised to try others, giving a successful validation
result if any can be validated and giving a failure only if all
RRSIGs fail validation.
If a resolver adopts a more restrictive policy, there's a danger that
Weiler Expires November 24, 2005 [Page 6]
Internet-Draft DNSSECbis Implementation Notes May 2005
properly-signed data might unnecessarily fail validation, perhaps
because of cache timing issues. Furthermore, certain zone management
techniques, like the Double Signature Zone-signing Key Rollover
method described in section 4.2.1.2 of [6] might not work reliably.
3.4 Key Tag Calculation
RFC4034 Appendix B.1 incorrectly defines the Key Tag field
calculation for algorithm 1. It correctly says that the Key Tag is
the most significant 16 of the least significant 24 bits of the
public key modulus. However, RFC4034 then goes on to incorrectly say
that this is 4th to last and 3rd to last octets of the public key
modulus. It is, in fact, the 3rd to last and 2nd to last octets.
4. Minor Corrections and Clarifications
4.1 Finding Zone Cuts
Appendix C.8 of RFC4035 discusses sending DS queries to the servers
for a parent zone. To do that, a resolver may first need to apply
special rules to discover what those servers are.
As explained in Section 3.1.4.1 of RFC4035, security-aware name
servers need to apply special processing rules to handle the DS RR,
and in some situations the resolver may also need to apply special
rules to locate the name servers for the parent zone if the resolver
does not already have the parent's NS RRset. Section 4.2 of RFC4035
specifies a mechanism for doing that.
4.2 Clarifications on DNSKEY Usage
Questions of the form "can I use a different DNSKEY for signing the
X" have occasionally arisen.
The short answer is "yes, absolutely". You can even use a different
DNSKEY for each RRset in a zone, subject only to practical limits on
the size of the DNSKEY RRset. However, be aware that there is no way
to tell resolvers what a particularly DNSKEY is supposed to be used
for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
authenticate any RRset in the zone. For example, if a weaker or less
trusted DNSKEY is being used to authenticate NSEC RRsets or all
dynamically updated records, that same DNSKEY can also be used to
sign any other RRsets from the zone.
Furthermore, note that the SEP bit setting has no effect on how a
DNSKEY may be used -- the validation process is specifically
prohibited from using that bit by RFC4034 section 2.1.2. It possible
to use a DNSKEY without the SEP bit set as the sole secure entry
Weiler Expires November 24, 2005 [Page 7]
Internet-Draft DNSSECbis Implementation Notes May 2005
point to the zone, yet use a DNSKEY with the SEP bit set to sign all
RRsets in the zone (other than the DNSKEY RRset). It's also possible
to use a single DNSKEY, with or without the SEP bit set, to sign the
entire zone, including the DNSKEY RRset itself.
4.3 Errors in Examples
The text in RFC4035 Section C.1 refers to the examples in B.1 as
"x.w.example.com" while B.1 uses "x.w.example". This is painfully
obvious in the second paragraph where it states that the RRSIG labels
field value of 3 indicates that the answer was not the result of
wildcard expansion. This is true for "x.w.example" but not for
"x.w.example.com", which of course has a label count of 4
(antithetically, a label count of 3 would imply the answer was the
result of a wildcard expansion).
The first paragraph of RFC4035 Section C.6 also has a minor error:
the reference to "a.z.w.w.example" should instead be "a.z.w.example",
as in the previous line.
5. IANA Considerations
This document specifies no IANA Actions.
6. Security Considerations
This document does not make fundamental changes to the DNSSEC
protocol, as it was generally understood when DNSSECbis was
published. It does, however, address some ambiguities and omissions
in those documents that, if not recognized and addressed in
implementations, could lead to security failures. In particular, the
validation algorithm clarifications in Section 2 are critical for
preserving the security properties DNSSEC offers. Furthermore,
failure to address some of the interoperability concerns in Section 3
could limit the ability to later change or expand DNSSEC, including
by adding new algorithms.
7. References
7.1 Normative References
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
Weiler Expires November 24, 2005 [Page 8]
Internet-Draft DNSSECbis Implementation Notes May 2005
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7.2 Informative References
[5] Blacka, D., "DNSSEC Experiments",
draft-blacka-dnssec-experiments-00 (work in progress),
December 2004.
[6] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practices-04 (work in
progress), May 2005.
Author's Address
Samuel Weiler
SPARTA, Inc
7075 Samuel Morse Drive
Columbia, Maryland 21046
US
Email: weiler@tislabs.com
Appendix A. Acknowledgments
The editor is extremely grateful to those who, in addition to finding
errors and omissions in the DNSSECbis document set, have provided
text suitable for inclusion in this document.
The lack of specificity about handling private algorithms, as
described in Section 3.2, and the lack of specificity in handling ANY
queries, as described in Section 2.3, were discovered by David
Blacka.
The error in algorithm 1 key tag calculation, as described in
Section 3.4, was found by Abhijit Hayatnagarkar. Donald Eastlake
contributed text for Section 3.4.
The bug relating to delegation NSEC RR's in Section 2.1 was found by
Roy Badami. Roy Arends found the related problem with DNAME.
The errors in the RFC4035 examples were found by Roy Arends, who also
contributed text for Section 4.3 of this document.
Weiler Expires November 24, 2005 [Page 9]
Internet-Draft DNSSECbis Implementation Notes May 2005
The editor would like to thank Olafur Gudmundsson and Scott Rose for
their substantive comments on the text of this document.
Weiler Expires November 24, 2005 [Page 10]
Internet-Draft DNSSECbis Implementation Notes May 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weiler Expires November 24, 2005 [Page 11]

560
doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt Normal file
View File

@@ -0,0 +1,560 @@
Network Working Group S. Weiler
Internet-Draft SPARTA, Inc
Updates: 4034, 4035 (if approved) J. Ihren
Expires: November 13, 2005 Autonomica AB
May 12, 2005
Minimally Covering NSEC Records and DNSSEC On-line Signing
draft-ietf-dnsext-dnssec-online-signing-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes how to construct DNSSEC NSEC resource records
that cover a smaller range of names than called for by RFC4034. By
generating and signing these records on demand, authoritative name
servers can effectively stop the disclosure of zone contents
otherwise made possible by walking the chain of NSEC records in a
signed zone.
Weiler & Ihren Expires November 13, 2005 [Page 1]
Internet-Draft NSEC Epsilon May 2005
Changes from weiler-01 to ietf-00
Inserted RFC numbers for 4033, 4034, and 4035.
Specified contents of bitmap field in synthesized NSEC RR's, pointing
out that this relaxes a constraint in 4035. Added 4035 to the
Updates header.
Changes from weiler-00 to weiler-01
Clarified that this updates RFC4034 by relaxing requirements on the
next name field.
Added examples covering wildcard names.
In the 'better functions' section, reiterated that perfect functions
aren't needed.
Added a reference to RFC 2119.
Weiler & Ihren Expires November 13, 2005 [Page 2]
Internet-Draft NSEC Epsilon May 2005
Table of Contents
1. Introduction and Terminology . . . . . . . . . . . . . . . . 4
2. Minimally Covering NSEC Records . . . . . . . . . . . . . . 4
3. Better Increment & Decrement Functions . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . 10
Weiler & Ihren Expires November 13, 2005 [Page 3]
Internet-Draft NSEC Epsilon May 2005
1. Introduction and Terminology
With DNSSEC [1], an NSEC record lists the next instantiated name in
its zone, proving that no names exist in the "span" between the
NSEC's owner name and the name in the "next name" field. In this
document, an NSEC record is said to "cover" the names between its
owner name and next name.
Through repeated queries that return NSEC records, it is possible to
retrieve all of the names in the zone, a process commonly called
"walking" the zone. Some zone owners have policies forbidding zone
transfers by arbitrary clients; this side-effect of the NSEC
architecture subverts those policies.
This document presents a way to prevent zone walking by constructing
NSEC records that cover fewer names. These records can make zone
walking take approximately as many queries as simply asking for all
possible names in a zone, making zone walking impractical. Some of
these records must be created and signed on demand, which requires
on-line private keys. Anyone contemplating use of this technique is
strongly encouraged to review the discussion of the risks of on-line
signing in Section 5.
The technique presented here may be useful to a zone owner that wants
to use DNSSEC, is concerned about exposure of its zone contents via
zone walking, and is willing to bear the costs of on-line signing.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
2. Minimally Covering NSEC Records
This mechanism involves changes to NSEC records for instantiated
names, which can still be generated and signed in advance, as well as
the on-demand generation and signing of new NSEC records whenever a
name must be proven not to exist.
In the 'next name' field of instantiated names' NSEC records, rather
than list the next instantiated name in the zone, list any name that
falls lexically after the NSEC's owner name and before the next
instantiated name in the zone, according to the ordering function in
RFC4034 [2] section 6.2. This relaxes the requirement in section
4.1.1 of RFC4034 that the 'next name' field contains the next owner
name in the zone. This change is expected to be fully compatible
with all existing DNSSEC validators. These NSEC records are returned
whenever proving something specifically about the owner name (e.g.
that no resource records of a given type appear at that name).
Weiler & Ihren Expires November 13, 2005 [Page 4]
Internet-Draft NSEC Epsilon May 2005
Whenever an NSEC record is needed to prove the non-existence of a
name, a new NSEC record is dynamically produced and signed. The new
NSEC record has an owner name lexically before the QNAME but
lexically following any existing name and a 'next name' lexically
following the QNAME but before any existing name.
The generated NSEC record's type bitmap SHOULD have the RRSIG and
NSEC bits set and SHOULD NOT have any other bits set. This relaxes
the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
names that did not exist before the zone wsa signed.
The functions to generate the lexically following and proceeding
names need not be perfect nor consistent, but the generated NSEC
records must not cover any existing names. Furthermore, this
technique works best when the generated NSEC records cover as few
names as possible.
An NSEC record denying the existence of a wildcard may be generated
in the same way. Since the NSEC record covering a non-existent
wildcard is likely to be used in response to many queries,
authoritative name servers using the techniques described here may
want to pregenerate or cache that record and its corresponding RRSIG.
For example, a query for an A record at the non-instantiated name
example.com might produce the following two NSEC records, the first
denying the existence of the name example.com and the second denying
the existence of a wildcard:
exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
).com 3600 IN NSEC +.com ( RRSIG NSEC )
Before answering a query with these records, an authoritative server
must test for the existence of names between these endpoints. If the
generated NSEC would cover existing names (e.g. exampldd.com or
*bizarre.example.com), a better increment or decrement function may
be used or the covered name closest to the QNAME could be used as the
NSEC owner name or next name, as appropriate. If an existing name is
used as the NSEC owner name, that name's real NSEC record MUST be
returned. Using the same example, assuming an exampldd.com
delegation exists, this record might be returned from the parent:
exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
Like every authoritative record in the zone, each generated NSEC
record MUST have corresponding RRSIGs generated using each algorithm
(but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
described in RFC4035 [3] section 2.2. To minimize the number of
Weiler & Ihren Expires November 13, 2005 [Page 5]
Internet-Draft NSEC Epsilon May 2005
signatures that must be generated, a zone may wish to limit the
number of algorithms in its DNSKEY RRset.
3. Better Increment & Decrement Functions
Section 6.2 of RFC4034 defines a strict ordering of DNS names.
Working backwards from that definition, it should be possible to
define increment and decrement functions that generate the
immediately following and preceding names, respectively. This
document does not define such functions. Instead, this section
presents functions that come reasonably close to the perfect ones.
As described above, an authoritative server should still ensure than
no generated NSEC covers any existing name.
To increment a name, add a leading label with a single null (zero-
value) octet.
To decrement a name, decrement the last character of the leftmost
label, then fill that label to a length of 63 octets with octets of
value 255. To decrement a null (zero-value) octet, remove the octet
-- if an empty label is left, remove the label. Defining this
function numerically: fill the left-most label to its maximum length
with zeros (numeric, not ASCII zeros) and subtract one.
In response to a query for the non-existent name foo.example.com,
these functions produce NSEC records of:
fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
The first of these NSEC RRs proves that no exact match for
foo.example.com exists, and the second proves that there is no
wildcard in example.com.
Both of these functions are imperfect: they don't take into account
constraints on number of labels in a name nor total length of a name.
As noted in the previous section, though, this technique does not
depend on the use of perfect increment or decrement functions: it is
sufficient to test whether any instantiated names fall into the span
Weiler & Ihren Expires November 13, 2005 [Page 6]
Internet-Draft NSEC Epsilon May 2005
covered by the generated NSEC and, if so, substitute those
instantiated owner names for the NSEC owner name or next name, as
appropriate.
4. IANA Considerations
Per RFC4041, IANA should think carefully about the protection of
their immortal souls.
5. Security Considerations
This approach requires on-demand generation of RRSIG records. This
creates several new vulnerabilities.
First, on-demand signing requires that a zone's authoritative servers
have access to its private keys. Storing private keys on well-known
internet-accessible servers may make them more vulnerable to
unintended disclosure.
Second, since generation of public key signatures tends to be
computationally demanding, the requirement for on-demand signing
makes authoritative servers vulnerable to a denial of service attack.
Lastly, if the increment and decrement functions are predictable, on-
demand signing may enable a chosen-plaintext attack on a zone's
private keys. Zones using this approach should attempt to use
cryptographic algorithms that are resistant to chosen-plaintext
attacks. It's worth noting that while DNSSEC has a "mandatory to
implement" algorithm, that is a requirement on resolvers and
validators -- there is no requirement that a zone be signed with any
given algorithm.
The success of using minimally covering NSEC record to prevent zone
walking depends greatly on the quality of the increment and decrement
functions chosen. An increment function that chooses a name
obviously derived from the next instantiated name may be easily
reverse engineered, destroying the value of this technique. An
increment function that always returns a name close to the next
instantiated name is likewise a poor choice. Good choices of
increment and decrement functions are the ones that produce the
immediately following and preceding names, respectively, though zone
administrators may wish to use less perfect functions that return
more human-friendly names than the functions described in Section 3
above.
Another obvious but misguided concern is the danger from synthesized
NSEC records being replayed. It's possible for an attacker to replay
an old but still validly signed NSEC record after a new name has been
Weiler & Ihren Expires November 13, 2005 [Page 7]
Internet-Draft NSEC Epsilon May 2005
added in the span covered by that NSEC, incorrectly proving that
there is no record at that name. This danger exists with DNSSEC as
defined in [-bis]. The techniques described here actually decrease
the danger, since the span covered by any NSEC record is smaller than
before. Choosing better increment and decrement functions will
further reduce this danger.
6. Normative References
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Samuel Weiler
SPARTA, Inc
7075 Samuel Morse Drive
Columbia, Maryland 21046
US
Email: weiler@tislabs.com
Johan Ihren
Autonomica AB
Bellmansgatan 30
Stockholm SE-118 47
Sweden
Email: johani@autonomica.se
Appendix A. Acknowledgments
Many individuals contributed to this design. They include, in
addition to the authors of this document, Olaf Kolkman, Ed Lewis,
Weiler & Ihren Expires November 13, 2005 [Page 8]
Internet-Draft NSEC Epsilon May 2005
Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
Jakob Schlyter, Bill Manning, and Joao Damas.
The key innovation of this document, namely that perfect increment
and decrement functions are not necessary, arose during a discussion
among the above-listed people at the RIPE49 meeting in September
2004.
Weiler & Ihren Expires November 13, 2005 [Page 9]
Internet-Draft NSEC Epsilon May 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weiler & Ihren Expires November 13, 2005 [Page 10]

145
doc/draft/draft-ietf-dnsext-interop3597-01.txt → doc/draft/draft-ietf-dnsext-interop3597-02.txt
View File

@@ -1,39 +1,39 @@
DNS Extensions Working Group J. Schlyter DNS Extensions Working Group J. Schlyter
Internet-Draft August 24, 2004 Internet-Draft May 19, 2005
Expires: February 22, 2005 Expires: November 20, 2005
RFC 3597 Interoperability Report RFC 3597 Interoperability Report
draft-ietf-dnsext-interop3597-01.txt draft-ietf-dnsext-interop3597-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3667. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 22, 2005. This Internet-Draft will expire on November 20, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
@@ -49,11 +49,9 @@ Abstract
Schlyter Expires November 20, 2005 [Page 1]
Internet-Draft RFC 3597 Interoperability Report May 2005
Schlyter Expires February 22, 2005 [Page 1]
Internet-Draft RFC 3597 Interoperability Report August 2004
Table of Contents Table of Contents
@@ -61,14 +59,14 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3
3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Authoritative Primary Name Server . . . . . . . . . . . . . . 3 3.1 Authoritative Primary Name Server . . . . . . . . . . . . 3
3.2 Authoritative Secondary Name Server . . . . . . . . . . . . . 3 3.2 Authoritative Secondary Name Server . . . . . . . . . . . 3
3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . . . 3 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . 4
3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . . . 3 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . 4
3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . . . 4 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . 4
4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Normative References . . . . . . . . . . . . . . . . . . . . . 4 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5 A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 6
@@ -107,26 +105,26 @@ Table of Contents
Schlyter Expires February 22, 2005 [Page 2] Schlyter Expires November 20, 2005 [Page 2]
Internet-Draft RFC 3597 Interoperability Report August 2004 Internet-Draft RFC 3597 Interoperability Report May 2005
1. Introduction 1. Introduction
This memo documents the result from the RFC 3597 (Handling of Unknown This memo documents the result from the RFC 3597 (Handling of Unknown
DNS Resource Record Types) interoperability testing. The test was DNS Resource Record Types) interoperability testing. The test was
performed during June and July 2004 by request of the IETF DNS performed during June and July 2004 by request of the IETF DNS
Extensions Working Group. Extensions Working Group.
2. Implementations 2. Implementations
The following is a list, in alphabetic order, of implementations for The following is a list, in alphabetic order, of implementations
compliance of RFC 3597: tested for compliance with RFC 3597:
DNSJava 1.6.4 DNSJava 1.6.4
ISC BIND 8.4.5rc4 ISC BIND 8.4.5
ISC BIND 9.3.0rc2 ISC BIND 9.3.0
NSD 2.1.1 NSD 2.1.1
Net::DNS 0.47 patchlevel 1 Net::DNS 0.47 patchlevel 1
Nominum ANS 2.2.1.0.d Nominum ANS 2.2.1.0.d
@@ -139,43 +137,51 @@ Internet-Draft RFC 3597 Interoperability Report August 2004
Stub Resolver (4) Stub Resolver (4)
DNSSEC Zone Signers (2) DNSSEC Zone Signers (2)
3. Tests All listed implementations are genetically different.
3.1 Authoritative Primary Name Server 3. Tests
The following tests was been performed to validate compliance with
RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression")
and 5 ("Text Representation").
3.1 Authoritative Primary Name Server
The test zone data (Appendix A) was loaded into the name server The test zone data (Appendix A) was loaded into the name server
implementation and the server was queried for the loaded information. implementation and the server was queried for the loaded information.
3.2 Authoritative Secondary Name Server 3.2 Authoritative Secondary Name Server
The test zone data (Appendix A) was transferred using AXFR from The test zone data (Appendix A) was transferred using AXFR from
another name server implementation and the server was queried for the another name server implementation and the server was queried for the
transferred information. transferred information.
3.3 Full Recursive Resolver
Schlyter Expires November 20, 2005 [Page 3]
Internet-Draft RFC 3597 Interoperability Report May 2005
3.3 Full Recursive Resolver
A recursive resolver was queried for resource records from a domain A recursive resolver was queried for resource records from a domain
with the test zone data (Appendix A). with the test zone data (Appendix A).
3.4 Stub Resolver 3.4 Stub Resolver
A stub resolver was used to query resource records from a domain with A stub resolver was used to query resource records from a domain with
Schlyter Expires February 22, 2005 [Page 3]
Internet-Draft RFC 3597 Interoperability Report August 2004
the test zone data (Appendix A). the test zone data (Appendix A).
3.5 DNSSEC Signer 3.5 DNSSEC Signer
A DNSSEC signer was used to sign a zone with test zone data (Appendix A DNSSEC signer was used to sign a zone with test zone data
A). (Appendix A).
4. Problems found 4. Problems found
Two implementations had problems with text presentation of zero Two implementations had problems with text presentation of zero
length RDATA. length RDATA.
@@ -185,14 +191,14 @@ Internet-Draft RFC 3597 Interoperability Report August 2004
Bug reports were filed for problems found. Bug reports were filed for problems found.
5. Summary 5. Summary
Unknown type codes works in the tested authoritative servers, Unknown type codes works in the tested authoritative servers,
recursive resolvers and stub clients. recursive resolvers and stub clients.
No changes are needed to advance RFC 3597 to draft standard. No changes are needed to advance RFC 3597 to draft standard.
Normative References 6. Normative References
[1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003. Types", RFC 3597, September 2003.
@@ -202,7 +208,7 @@ Author's Address
Jakob Schlyter Jakob Schlyter
EMail: jakob@rfc.se Email: jakob@rfc.se
@@ -211,20 +217,12 @@ Author's Address
Schlyter Expires November 20, 2005 [Page 4]
Internet-Draft RFC 3597 Interoperability Report May 2005
Appendix A. Test zone data
Schlyter Expires February 22, 2005 [Page 4]
Internet-Draft RFC 3597 Interoperability Report August 2004
Appendix A. Test zone data
; A-record encoded as TYPE1 ; A-record encoded as TYPE1
a TYPE1 \# 4 7f000001 a TYPE1 \# 4 7f000001
@@ -275,9 +273,9 @@ Appendix A. Test zone data
Schlyter Expires February 22, 2005 [Page 5] Schlyter Expires November 20, 2005 [Page 5]
Internet-Draft RFC 3597 Interoperability Report August 2004 Internet-Draft RFC 3597 Interoperability Report May 2005
Intellectual Property Statement Intellectual Property Statement
@@ -287,9 +285,9 @@ Intellectual Property Statement
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
@@ -301,7 +299,7 @@ Intellectual Property Statement
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
@@ -318,7 +316,7 @@ Disclaimer of Validity
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
@@ -331,5 +329,6 @@ Acknowledgment
Schlyter Expires February 22, 2005 [Page 6] Schlyter Expires November 20, 2005 [Page 6]

1013
doc/draft/draft-ietf-dnsext-mdns-41.txt → doc/draft/draft-ietf-dnsext-mdns-43.txt
View File

File diff suppressed because it is too large Load Diff

1009
doc/draft/draft-ietf-dnsext-nsec3-01.txt
View File

File diff suppressed because it is too large Load Diff

2072
doc/draft/draft-ietf-dnsext-nsec3-02.txt Normal file
View File

File diff suppressed because it is too large Load Diff

737
doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt → doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
View File

File diff suppressed because it is too large Load Diff

729
doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt
View File

@@ -1,729 +0,0 @@
Network Working Group M. StJohns
Internet-Draft Nominum, Inc.
Expires: April 14, 2005 October 14, 2004
Automated Updates of DNSSEC Trust Anchors
draft-ietf-dnsext-trustupdate-timers-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 14, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes a means for automated, authenticated and
authorized updating of DNSSEC "trust anchors". The method provides
protection against single key compromise of a key in the trust point
key set. Based on the trust established by the presence of a current
anchor, other anchors may be added at the same place in the
hierarchy, and, ultimately, supplant the existing anchor.
This mechanism, if adopted, will require changes to resolver
StJohns Expires April 14, 2005 [Page 1]
Internet-Draft trustanchor-update October 2004
management behavior (but not resolver resolution behavior), and the
addition of a single flag bit to the DNSKEY record.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6
3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8
5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9
5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
StJohns Expires April 14, 2005 [Page 2]
Internet-Draft trustanchor-update October 2004
1. Introduction
As part of the reality of fielding DNSSEC (Domain Name System
Security Extensions) [RFC2535][DSINTRO][DSPROT][DSREC], the community
has come to the realization that there will not be one signed name
space, but rather islands of signed name space each originating from
specific points (i.e. 'trust points') in the DNS tree. Each of
those islands will be identified by the trust point name, and
validated by at least one associated public key. For the purpose of
this document we'll call the association of that name and a
particular key a 'trust anchor'. A particular trust point can have
more than one key designated as a trust anchor.
For a DNSSEC-aware resolver to validate information in a DNSSEC
protected branch of the hierarchy, it must have knowledge of a trust
anchor applicable to that branch. It may also have more than one
trust anchor for any given trust point. Under current rules, a chain
of trust for DNSSEC-protected data that chains its way back to ANY
known trust anchor is considered 'secure'.
Because of the probable balkanization of the DNSSEC tree due to
signing voids at key locations, a resolver may need to know literally
thousands of trust anchors to perform its duties. (e.g. Consider an
unsigned ".COM".) Requiring the owner of the resolver to manually
manage this many relationships is problematic. It's even more
problematic when considering the eventual requirement for key
replacement/update for a given trust anchor. The mechanism described
herein won't help with the initial configuration of the trust anchors
in the resolvers, but should make trust point key
replacement/rollover more viable.
As mentioned above, this document describes a mechanism whereby a
resolver can update the trust anchors for a given trust point, mainly
without human intervention at the resolver. There are some corner
cases discussed (e.g. multiple key compromise) that may require
manual intervention, but they should be few and far between. This
document DOES NOT discuss the general problem of the initial
configuration of trust anchors for the resolver.
1.1 Compliance Nomenclature
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119].
1.2 Changes since -00
Resubmitted draft-stjohns-dnssec-trustupdate as a working group
StJohns Expires April 14, 2005 [Page 3]
Internet-Draft trustanchor-update October 2004
draft.
Added the concept of timer triggered resolver queries to refresh the
resolvers view of the trust anchor key RRSet.
2. Theory of Operation
The general concept of this mechanism is that existing trust anchors
can be used to authenticate new trust anchors at the same point in
the DNS hierarchy. When a new SEP key is added to a trust point
DNSKEY RRSet, and when that RRSet is validated by an existing trust
anchor, then the new key can be added to the set of trust anchors.
There are some issues with this approach which need to be mitigated.
For example, a compromise of one of the existing keys could allow an
attacker to add their own 'valid' data. This implies a need for a
method to revoke an existing key regardless of whether or not that
key is compromised. As another example assuming a single key
compromise, an attacker could add a new key and revoke all the other
old keys.
2.1 Revocation
Assume two trust anchor keys A and B. Assume that B has been
compromised. Without a specific revocation bit, B could invalidate A
simply by sending out a signed trust point key set which didn't
contain A. To fix this, we add a mechanism which requires knowledge
of the private key of a DNSKEY to revoke that DNSKEY.
A key is considered revoked when the resolver sees the key in a
self-signed RRSet and the key has the REVOKE bit set to '1'. Once
the resolver sees the REVOKE bit, it MUST NOT use this key as a trust
anchor or for any other purposes except validating the RRSIG over the
DNSKEY RRSet specifically for the purpose of validating the
revocation. Unlike the 'Add' operation below, revocation is
immediate and permanent upon receipt of a valid revocation at the
resolver.
N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
than one without the bit set. This affects the matching of a DNSKEY
to DS records in the parent, or the fingerprint stored at a resolver
used to configure a trust point. [msj3]
In the given example, the attacker could revoke B because it has
knowledge of B's private key, but could not revoke A.
StJohns Expires April 14, 2005 [Page 4]
Internet-Draft trustanchor-update October 2004
2.2 Add Hold-Down
Assume two trust point keys A and B. Assume that B has been
compromised. An attacker could generate and add a new trust anchor
key - C (by adding C to the DNSKEY RRSet and signing it with B), and
then invalidate the compromised key. This would result in the both
the attacker and owner being able to sign data in the zone and have
it accepted as valid by resolvers.
To mitigate, but not completely solve, this problem, we add a
hold-down time to the addition of the trust anchor. When the
resolver sees a new SEP key in a validated trust point DNSKEY RRSet,
the resolver starts an acceptance timer, and remembers all the keys
that validated the RRSet. If the resolver ever sees the DNSKEY RRSet
without the new key but validly signed, it stops the acceptance
process and resets the acceptance timer. If all of the keys which
were originally used to validate this key are revoked prior to the
timer expiring, the resolver stops the acceptance process and resets
the timer.
Once the timer expires, the new key will be added as a trust anchor
the next time the validated RRSet with the new key is seen at the
resolver. The resolver MUST NOT treat the new key as a trust anchor
until the hold down time expires AND it has retrieved and validated a
DNSKEY RRSet after the hold down time which contains the new key.
N.B.: Once the resolver has accepted a key as a trust anchor, the key
MUST be considered a valid trust anchor by that resolver until
explictly revoked as described above.
In the given example, the zone owner can recover from a compromise by
revoking B and adding a new key D and signing the DNSKEY RRSet with
both A and B.
The reason this does not completely solve the problem has to do with
the distributed nature of DNS. The resolver only knows what it sees.
A determined attacker who holds one compromised key could keep a
single resolver from realizing that key had been compromised by
intercepting 'real' data from the originating zone and substituting
their own (e.g. using the example, signed only by B). This is no
worse than the current situation assuming a compromised key.
2.3 Remove Hold-down
A new key which has been seen by the resolver, but hasn't reached
it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
zone owner. If the resolver sees a validated DNSKEY RRSet without
this key, it waits for the remove hold-down time and then, if the key
StJohns Expires April 14, 2005 [Page 5]
Internet-Draft trustanchor-update October 2004
hasn't reappeared, SHOULD discard any information about the key.
2.4 Active Refresh
A resolver which has been configured for automatic update of keys
from a particular trust point MUST query that trust point (e.g. do a
lookup for the DNSKEY RRSet and related RRSIG records) no less often
than the lesser of 15 days or half the original TTL for the DNSKEY
RRSet or half the RRSIG expiration interval. The expiration interval
is the amount of time from when the RRSIG was last retrieved until
the expiration time in the RRSIG.
If the query fails, the resolver MUST repeat the query until
satisfied no more often than once an hour and no less often than the
lesser of 1 day or 10% of the original TTL or 10% of the original
expiration interval.
2.5 Resolver Parameters
2.5.1 Add Hold-Down Time
The add hold-down time is 30 days or the expiration time of the TTL
of the first trust point DNSKEY RRSet which contained the key,
whichever is greater. This ensures that at least two validated
DNSKEY RRSets which contain the new key MUST be seen by the resolver
prior to the key's acceptance.
2.5.2 Remove Hold-Down Time
The remove hold-down time is 30 days.
2.5.3 Minimum Trust Anchors per Trust Point
A compliant resolver MUST be able to manage at least five SEP keys
per trust point.
3. Changes to DNSKEY RDATA Wire Format
Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
flag. If this bit is set to '1', AND the resolver sees an
RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
consider this key permanently invalid for all purposes except for
validing the revocation.
4. State Table
The most important thing to understand is the resolver's view of any
key at a trust point. The following state table describes that view
StJohns Expires April 14, 2005 [Page 6]
Internet-Draft trustanchor-update October 2004
at various points in the key's lifetime. The table is a normative
part of this specification. The initial state of the key is 'Start'.
The resolver's view of the state of the key changes as various events
occur.
[msj1] This is the state of a trust point key as seen from the
resolver. The column on the left indicates the current state. The
header at the top shows the next state. The intersection of the two
shows the event that will cause the state to transition from the
current state to the next.
NEXT STATE
--------------------------------------------------
FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
----------------------------------------------------------
Start | |NewKey | | | | |
----------------------------------------------------------
AddPend |KeyRem | |AddTime| | |
----------------------------------------------------------
Valid | | | |KeyRem |Revbit | |
----------------------------------------------------------
Missing | | |KeyPres| |Revbit | |
----------------------------------------------------------
Revoked | | | | | |RemTime|
----------------------------------------------------------
Removed | | | | | | |
----------------------------------------------------------
4.1 Events
NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
That key will become a new trust anchor for the named trust point
after its been present in the RRSet for at least 'add time'.
KeyPres The key has returned to the valid DNSKEY RRSet.
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
this key.
AddTime The key has been in every valid DNSKEY RRSet seen for at
least the 'add time'.
RemTime A revoked key has been missing from the trust point DNSKEY
RRSet for sufficient time to be removed from the trust set.
RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
"REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
signed by this key.
4.2 States
StJohns Expires April 14, 2005 [Page 7]
Internet-Draft trustanchor-update October 2004
Start The key doesn't yet exist as a trust anchor at the resolver.
It may or may not exist at the zone server, but hasn't yet been
seen at the resolver.
AddPend The key has been seen at the resolver, has its 'SEP' bit set,
and has been included in a validated DNSKEY RRSet. There is a
hold-down time for the key before it can be used as a trust
anchor.
Valid The key has been seen at the resolver and has been included in
all validated DNSKEY RRSets from the time it was first seen up
through the hold-down time. It is now valid for verifying RRSets
that arrive after the hold down time. Clarification: The DNSKEY
RRSet does not need to be continuously present at the resolver
(e.g. its TTL might expire). If the RRSet is seen, and is
validated (i.e. verifies against an existing trust anchor), this
key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
Missing This is an abnormal state. The key remains as a valid trust
point key, but was not seen at the resolver in the last validated
DNSKEY RRSet. This is an abnormal state because the zone operator
should be using the REVOKE bit prior to removal. [Discussion
item: Should a missing key be considered revoked after some
period of time?]
Revoked This is the state a key moves to once the resolver sees an
RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
this key with its REVOKE bit set to '1'. Once in this state, this
key MUST permanently be considered invalid as a trust anchor.
Removed After a fairly long hold-down time, information about this
key may be purged from the resolver. A key in the removed state
MUST NOT be considered a valid trust anchor.
5. Scenarios
The suggested model for operation is to have one active key and one
stand-by key at each trust point. The active key will be used to
sign the DNSKEY RRSet. The stand-by key will not normally sign this
RRSet, but the resolver will accept it as a trust anchor if/when it
sees the signature on the trust point DNSKEY RRSet.
Since the stand-by key is not in active signing use, the associated
private key may (and SHOULD) be provided with additional protections
not normally available to a key that must be used frequently. E.g.
locked in a safe, split among many parties, etc. Notionally, the
stand-by key should be less subject to compromise than an active key,
but that will be dependent on operational concerns not addressed
here.
5.1 Adding A Trust Anchor
Assume an existing trust anchor key 'A'.
StJohns Expires April 14, 2005 [Page 8]
Internet-Draft trustanchor-update October 2004
1. Generate a new key pair.
2. Create a DNSKEY record from the key pair and set the SEP and Zone
Key bits.
3. Add the DNSKEY to the RRSet.
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
'A'.
5. Wait a while.
5.2 Deleting a Trust Anchor
Assume existing trust anchors 'A' and 'B' and that you want to revoke
and delete 'A'.
1. Set the revolcation bit on key 'A'.
2. Sign the DNSKEY RRSet with both 'A' and 'B'.
'A' is now revoked. The operator SHOULD include the revoked 'A' in
the RRSet for at least the remove hold-down time, but then may remove
it from the DNSKEY RRSet.
5.3 Key Roll-Over
Assume existing keys A and B. 'A' is actively in use (i.e. has been
signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has
been in the DNSKEY RRSet and is a valid trust anchor, but wasn't
being used to sign the RRSet.)
1. Generate a new key pair 'C'.
2. Add 'C' to the DNSKEY RRSet.
3. Set the revocation bit on key 'A'.
4. Sign the RRSet with 'A' and 'B'.
'A' is now revoked, 'B' is now the active key, and 'C' will be the
stand-by key once the hold-down expires. The operator SHOULD include
the revoked 'A' in the RRSet for at least the remove hold-down time,
but may then remove it from the DNSKEY RRSet.
5.4 Active Key Compromised
This is the same as the mechanism for Key Roll-Over (Section 5.3)
above assuming 'A' is the active key.
5.5 Stand-by Key Compromised
Using the same assumptions and naming conventions as Key Roll-Over
(Section 5.3) above:
1. Generate a new key pair 'C'.
2. Add 'C' to the DNSKEY RRSet.
3. Set the revocation bit on key 'B'.
4. Sign the RRSet with 'A' and 'B'.
'B' is now revoked, 'A' remains the active key, and 'C' will be the
stand-by key once the hold-down expires. 'B' SHOULD continue to be
StJohns Expires April 14, 2005 [Page 9]
Internet-Draft trustanchor-update October 2004
included in the RRSet for the remove hold-down time.
6. Security Considerations
6.1 Key Ownership vs Acceptance Policy
The reader should note that, while the zone owner is responsible
creating and distributing keys, it's wholly the decision of the
resolver owner as to whether to accept such keys for the
authentication of the zone information. This implies the decision
update trust anchor keys based on trust for a current trust anchor
key is also the resolver owner's decision.
The resolver owner (and resolver implementers) MAY choose to permit
or prevent key status updates based on this mechanism for specific
trust points. If they choose to prevent the automated updates, they
will need to establish a mechanism for manual or other out-of-band
updates outside the scope of this document.
6.2 Multiple Key Compromise
This scheme permits recovery as long as at least one valid trust
anchor key remains uncompromised. E.g. if there are three keys, you
can recover if two of them are compromised. The zone owner should
determine their own level of comfort with respect to the number of
active valid trust anchors in a zone and should be prepared to
implement recovery procedures once they detect a compromise. A
manual or other out-of-band update of all resolvers will be required
if all trust anchor keys at a trust point are compromised.
6.3 Dynamic Updates
Allowing a resolver to update its trust anchor set based in-band key
information is potentially less secure than a manual process.
However, given the nature of the DNS, the number of resolvers that
would require update if a trust anchor key were compromised, and the
lack of a standard management framework for DNS, this approach is no
worse than the existing situation.
7 Normative References
[DSINTRO] Arends, R., "DNS Security Introduction and Requirements",
ID draft-ietf-dnsext-dnssec-intro-09.txt, October 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
sec-intro-13.txt>.
[DSPROT] Arends, R., "Protocol Modifications for the DNS Security
Extensions", ID draft-ietf-dnsext-dnssec-protocol-05.txt,
StJohns Expires April 14, 2005 [Page 10]
Internet-Draft trustanchor-update October 2004
October 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
sec-protocol-09.txt>.
[DSREC] Arends, R., "Resource Records for the DNS Security
Extensions", ID draft-ietf-dnsext-dnssec-records-07.txt,
October 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
sec-records-11.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
Editorial Comments
[msj1] msj: N.B. This table is preliminary and will be revised to
match implementation experience. For example, should there
be a state for "Add hold-down expired, but haven't seen the
new RRSet"?
[msj2] msj: To be assigned.
[msj3] msj: For discussion: What's the implementation guidance for
resolvers currently with respect to the non-assigned flag
bits? If they consider the flag bit when doing key matching
at the trust anchor, they won't be able to match.
Author's Address
Michael StJohns
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94063
USA
Phone: +1-301-528-4729
EMail: Mike.StJohns@nominum.com
URI: www.nominum.com
StJohns Expires April 14, 2005 [Page 11]
Internet-Draft trustanchor-update October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
StJohns Expires April 14, 2005 [Page 12]
Internet-Draft trustanchor-update October 2004
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
StJohns Expires April 14, 2005 [Page 13]

730
doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt Normal file
View File

@@ -0,0 +1,730 @@
Network Working Group M. StJohns
Internet-Draft Nominum, Inc.
Expires: February 16, 2006 August 15, 2005
Automated Updates of DNSSEC Trust Anchors
draft-ietf-dnsext-trustupdate-timers-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a means for automated, authenticated and
authorized updating of DNSSEC "trust anchors". The method provides
protection against single key compromise of a key in the trust point
key set. Based on the trust established by the presence of a current
anchor, other anchors may be added at the same place in the
hierarchy, and, ultimately, supplant the existing anchor.
This mechanism, if adopted, will require changes to resolver
management behavior (but not resolver resolution behavior), and the
StJohns Expires February 16, 2006 [Page 1]
Internet-Draft trustanchor-update August 2005
addition of a single flag bit to the DNSKEY record.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6
3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8
5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9
5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
StJohns Expires February 16, 2006 [Page 2]
Internet-Draft trustanchor-update August 2005
1. Introduction
As part of the reality of fielding DNSSEC (Domain Name System
Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
community has come to the realization that there will not be one
signed name space, but rather islands of signed name space each
originating from specific points (i.e. 'trust points') in the DNS
tree. Each of those islands will be identified by the trust point
name, and validated by at least one associated public key. For the
purpose of this document we'll call the association of that name and
a particular key a 'trust anchor'. A particular trust point can have
more than one key designated as a trust anchor.
For a DNSSEC-aware resolver to validate information in a DNSSEC
protected branch of the hierarchy, it must have knowledge of a trust
anchor applicable to that branch. It may also have more than one
trust anchor for any given trust point. Under current rules, a chain
of trust for DNSSEC-protected data that chains its way back to ANY
known trust anchor is considered 'secure'.
Because of the probable balkanization of the DNSSEC tree due to
signing voids at key locations, a resolver may need to know literally
thousands of trust anchors to perform its duties. (e.g. Consider an
unsigned ".COM".) Requiring the owner of the resolver to manually
manage this many relationships is problematic. It's even more
problematic when considering the eventual requirement for key
replacement/update for a given trust anchor. The mechanism described
herein won't help with the initial configuration of the trust anchors
in the resolvers, but should make trust point key replacement/
rollover more viable.
As mentioned above, this document describes a mechanism whereby a
resolver can update the trust anchors for a given trust point, mainly
without human intervention at the resolver. There are some corner
cases discussed (e.g. multiple key compromise) that may require
manual intervention, but they should be few and far between. This
document DOES NOT discuss the general problem of the initial
configuration of trust anchors for the resolver.
1.1 Compliance Nomenclature
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119].
1.2 Changes since -00
Added the concept of timer triggered resolver queries to refresh the
StJohns Expires February 16, 2006 [Page 3]
Internet-Draft trustanchor-update August 2005
resolvers view of the trust anchor key RRSet.
Re-submitted expired draft as -01. Updated DNSSEC RFC References.
2. Theory of Operation
The general concept of this mechanism is that existing trust anchors
can be used to authenticate new trust anchors at the same point in
the DNS hierarchy. When a new SEP key is added to a trust point
DNSKEY RRSet, and when that RRSet is validated by an existing trust
anchor, then the new key can be added to the set of trust anchors.
There are some issues with this approach which need to be mitigated.
For example, a compromise of one of the existing keys could allow an
attacker to add their own 'valid' data. This implies a need for a
method to revoke an existing key regardless of whether or not that
key is compromised. As another example assuming a single key
compromise, an attacker could add a new key and revoke all the other
old keys.
2.1 Revocation
Assume two trust anchor keys A and B. Assume that B has been
compromised. Without a specific revocation bit, B could invalidate A
simply by sending out a signed trust point key set which didn't
contain A. To fix this, we add a mechanism which requires knowledge
of the private key of a DNSKEY to revoke that DNSKEY.
A key is considered revoked when the resolver sees the key in a self-
signed RRSet and the key has the REVOKE bit set to '1'. Once the
resolver sees the REVOKE bit, it MUST NOT use this key as a trust
anchor or for any other purposes except validating the RRSIG over the
DNSKEY RRSet specifically for the purpose of validating the
revocation. Unlike the 'Add' operation below, revocation is
immediate and permanent upon receipt of a valid revocation at the
resolver.
N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
than one without the bit set. This affects the matching of a DNSKEY
to DS records in the parent, or the fingerprint stored at a resolver
used to configure a trust point. [msj3]
In the given example, the attacker could revoke B because it has
knowledge of B's private key, but could not revoke A.
2.2 Add Hold-Down
Assume two trust point keys A and B. Assume that B has been
StJohns Expires February 16, 2006 [Page 4]
Internet-Draft trustanchor-update August 2005
compromised. An attacker could generate and add a new trust anchor
key - C (by adding C to the DNSKEY RRSet and signing it with B), and
then invalidate the compromised key. This would result in the both
the attacker and owner being able to sign data in the zone and have
it accepted as valid by resolvers.
To mitigate, but not completely solve, this problem, we add a hold-
down time to the addition of the trust anchor. When the resolver
sees a new SEP key in a validated trust point DNSKEY RRSet, the
resolver starts an acceptance timer, and remembers all the keys that
validated the RRSet. If the resolver ever sees the DNSKEY RRSet
without the new key but validly signed, it stops the acceptance
process and resets the acceptance timer. If all of the keys which
were originally used to validate this key are revoked prior to the
timer expiring, the resolver stops the acceptance process and resets
the timer.
Once the timer expires, the new key will be added as a trust anchor
the next time the validated RRSet with the new key is seen at the
resolver. The resolver MUST NOT treat the new key as a trust anchor
until the hold down time expires AND it has retrieved and validated a
DNSKEY RRSet after the hold down time which contains the new key.
N.B.: Once the resolver has accepted a key as a trust anchor, the key
MUST be considered a valid trust anchor by that resolver until
explictly revoked as described above.
In the given example, the zone owner can recover from a compromise by
revoking B and adding a new key D and signing the DNSKEY RRSet with
both A and B.
The reason this does not completely solve the problem has to do with
the distributed nature of DNS. The resolver only knows what it sees.
A determined attacker who holds one compromised key could keep a
single resolver from realizing that key had been compromised by
intercepting 'real' data from the originating zone and substituting
their own (e.g. using the example, signed only by B). This is no
worse than the current situation assuming a compromised key.
2.3 Remove Hold-down
A new key which has been seen by the resolver, but hasn't reached
it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
zone owner. If the resolver sees a validated DNSKEY RRSet without
this key, it waits for the remove hold-down time and then, if the key
hasn't reappeared, SHOULD discard any information about the key.
StJohns Expires February 16, 2006 [Page 5]
Internet-Draft trustanchor-update August 2005
2.4 Active Refresh
A resolver which has been configured for automatic update of keys
from a particular trust point MUST query that trust point (e.g. do a
lookup for the DNSKEY RRSet and related RRSIG records) no less often
than the lesser of 15 days or half the original TTL for the DNSKEY
RRSet or half the RRSIG expiration interval. The expiration interval
is the amount of time from when the RRSIG was last retrieved until
the expiration time in the RRSIG.
If the query fails, the resolver MUST repeat the query until
satisfied no more often than once an hour and no less often than the
lesser of 1 day or 10% of the original TTL or 10% of the original
expiration interval.
2.5 Resolver Parameters
2.5.1 Add Hold-Down Time
The add hold-down time is 30 days or the expiration time of the TTL
of the first trust point DNSKEY RRSet which contained the key,
whichever is greater. This ensures that at least two validated
DNSKEY RRSets which contain the new key MUST be seen by the resolver
prior to the key's acceptance.
2.5.2 Remove Hold-Down Time
The remove hold-down time is 30 days.
2.5.3 Minimum Trust Anchors per Trust Point
A compliant resolver MUST be able to manage at least five SEP keys
per trust point.
3. Changes to DNSKEY RDATA Wire Format
Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
flag. If this bit is set to '1', AND the resolver sees an
RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
consider this key permanently invalid for all purposes except for
validing the revocation.
4. State Table
The most important thing to understand is the resolver's view of any
key at a trust point. The following state table describes that view
at various points in the key's lifetime. The table is a normative
part of this specification. The initial state of the key is 'Start'.
StJohns Expires February 16, 2006 [Page 6]
Internet-Draft trustanchor-update August 2005
The resolver's view of the state of the key changes as various events
occur.
[msj1] This is the state of a trust point key as seen from the
resolver. The column on the left indicates the current state. The
header at the top shows the next state. The intersection of the two
shows the event that will cause the state to transition from the
current state to the next.
NEXT STATE
--------------------------------------------------
FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
----------------------------------------------------------
Start | |NewKey | | | | |
----------------------------------------------------------
AddPend |KeyRem | |AddTime| | |
----------------------------------------------------------
Valid | | | |KeyRem |Revbit | |
----------------------------------------------------------
Missing | | |KeyPres| |Revbit | |
----------------------------------------------------------
Revoked | | | | | |RemTime|
----------------------------------------------------------
Removed | | | | | | |
----------------------------------------------------------
4.1 Events
NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
That key will become a new trust anchor for the named trust point
after its been present in the RRSet for at least 'add time'.
KeyPres The key has returned to the valid DNSKEY RRSet.
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
this key.
AddTime The key has been in every valid DNSKEY RRSet seen for at
least the 'add time'.
RemTime A revoked key has been missing from the trust point DNSKEY
RRSet for sufficient time to be removed from the trust set.
RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
"REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
signed by this key.
4.2 States
Start The key doesn't yet exist as a trust anchor at the resolver.
It may or may not exist at the zone server, but hasn't yet been
seen at the resolver.
StJohns Expires February 16, 2006 [Page 7]
Internet-Draft trustanchor-update August 2005
AddPend The key has been seen at the resolver, has its 'SEP' bit set,
and has been included in a validated DNSKEY RRSet. There is a
hold-down time for the key before it can be used as a trust
anchor.
Valid The key has been seen at the resolver and has been included in
all validated DNSKEY RRSets from the time it was first seen up
through the hold-down time. It is now valid for verifying RRSets
that arrive after the hold down time. Clarification: The DNSKEY
RRSet does not need to be continuously present at the resolver
(e.g. its TTL might expire). If the RRSet is seen, and is
validated (i.e. verifies against an existing trust anchor), this
key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
Missing This is an abnormal state. The key remains as a valid trust
point key, but was not seen at the resolver in the last validated
DNSKEY RRSet. This is an abnormal state because the zone operator
should be using the REVOKE bit prior to removal. [Discussion
item: Should a missing key be considered revoked after some
period of time?]
Revoked This is the state a key moves to once the resolver sees an
RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
this key with its REVOKE bit set to '1'. Once in this state, this
key MUST permanently be considered invalid as a trust anchor.
Removed After a fairly long hold-down time, information about this
key may be purged from the resolver. A key in the removed state
MUST NOT be considered a valid trust anchor.
5. Scenarios
The suggested model for operation is to have one active key and one
stand-by key at each trust point. The active key will be used to
sign the DNSKEY RRSet. The stand-by key will not normally sign this
RRSet, but the resolver will accept it as a trust anchor if/when it
sees the signature on the trust point DNSKEY RRSet.
Since the stand-by key is not in active signing use, the associated
private key may (and SHOULD) be provided with additional protections
not normally available to a key that must be used frequently. E.g.
locked in a safe, split among many parties, etc. Notionally, the
stand-by key should be less subject to compromise than an active key,
but that will be dependent on operational concerns not addressed
here.
5.1 Adding A Trust Anchor
Assume an existing trust anchor key 'A'.
1. Generate a new key pair.
StJohns Expires February 16, 2006 [Page 8]
Internet-Draft trustanchor-update August 2005
2. Create a DNSKEY record from the key pair and set the SEP and Zone
Key bits.
3. Add the DNSKEY to the RRSet.
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
'A'.
5. Wait a while.
5.2 Deleting a Trust Anchor
Assume existing trust anchors 'A' and 'B' and that you want to revoke
and delete 'A'.
1. Set the revolcation bit on key 'A'.
2. Sign the DNSKEY RRSet with both 'A' and 'B'.
'A' is now revoked. The operator SHOULD include the revoked 'A' in
the RRSet for at least the remove hold-down time, but then may remove
it from the DNSKEY RRSet.
5.3 Key Roll-Over
Assume existing keys A and B. 'A' is actively in use (i.e. has been
signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been
in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
used to sign the RRSet.)
1. Generate a new key pair 'C'.
2. Add 'C' to the DNSKEY RRSet.
3. Set the revocation bit on key 'A'.
4. Sign the RRSet with 'A' and 'B'.
'A' is now revoked, 'B' is now the active key, and 'C' will be the
stand-by key once the hold-down expires. The operator SHOULD include
the revoked 'A' in the RRSet for at least the remove hold-down time,
but may then remove it from the DNSKEY RRSet.
5.4 Active Key Compromised
This is the same as the mechanism for Key Roll-Over (Section 5.3)
above assuming 'A' is the active key.
5.5 Stand-by Key Compromised
Using the same assumptions and naming conventions as Key Roll-Over
(Section 5.3) above:
1. Generate a new key pair 'C'.
2. Add 'C' to the DNSKEY RRSet.
3. Set the revocation bit on key 'B'.
4. Sign the RRSet with 'A' and 'B'.
'B' is now revoked, 'A' remains the active key, and 'C' will be the
stand-by key once the hold-down expires. 'B' SHOULD continue to be
included in the RRSet for the remove hold-down time.
StJohns Expires February 16, 2006 [Page 9]
Internet-Draft trustanchor-update August 2005
6. Security Considerations
6.1 Key Ownership vs Acceptance Policy
The reader should note that, while the zone owner is responsible
creating and distributing keys, it's wholly the decision of the
resolver owner as to whether to accept such keys for the
authentication of the zone information. This implies the decision
update trust anchor keys based on trust for a current trust anchor
key is also the resolver owner's decision.
The resolver owner (and resolver implementers) MAY choose to permit
or prevent key status updates based on this mechanism for specific
trust points. If they choose to prevent the automated updates, they
will need to establish a mechanism for manual or other out-of-band
updates outside the scope of this document.
6.2 Multiple Key Compromise
This scheme permits recovery as long as at least one valid trust
anchor key remains uncompromised. E.g. if there are three keys, you
can recover if two of them are compromised. The zone owner should
determine their own level of comfort with respect to the number of
active valid trust anchors in a zone and should be prepared to
implement recovery procedures once they detect a compromise. A
manual or other out-of-band update of all resolvers will be required
if all trust anchor keys at a trust point are compromised.
6.3 Dynamic Updates
Allowing a resolver to update its trust anchor set based in-band key
information is potentially less secure than a manual process.
However, given the nature of the DNS, the number of resolvers that
would require update if a trust anchor key were compromised, and the
lack of a standard management framework for DNS, this approach is no
worse than the existing situation.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
StJohns Expires February 16, 2006 [Page 10]
Internet-Draft trustanchor-update August 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.
Editorial Comments
[msj1] msj: N.B. This table is preliminary and will be revised to
match implementation experience. For example, should there
be a state for "Add hold-down expired, but haven't seen the
new RRSet"?
[msj2] msj: To be assigned.
[msj3] msj: For discussion: What's the implementation guidance for
resolvers currently with respect to the non-assigned flag
bits? If they consider the flag bit when doing key matching
at the trust anchor, they won't be able to match.
Author's Address
Michael StJohns
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94063
USA
Phone: +1-301-528-4729
Email: Mike.StJohns@nominum.com
URI: www.nominum.com
StJohns Expires February 16, 2006 [Page 11]
Internet-Draft trustanchor-update August 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
StJohns Expires February 16, 2006 [Page 12]
Internet-Draft trustanchor-update August 2005
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
StJohns Expires February 16, 2006 [Page 13]

52
doc/draft/draft-ietf-dnsext-tsig-sha-03.txt → doc/draft/draft-ietf-dnsext-tsig-sha-04.txt
View File

@@ -1,21 +1,20 @@
INTERNET-DRAFT Donald E. Eastlake 3rd INTERNET-DRAFT Donald E. Eastlake 3rd
UPDATES RFC 2845 Motorola Laboratories UPDATES RFC 2845 Motorola Laboratories
Expires: October 2005 April 2005 Expires: December 2005 June 2005
HMAC SHA TSIG Algorithm Identifiers HMAC SHA TSIG Algorithm Identifiers
---- --- ---- --------- ----------- ---- --- ---- --------- -----------
<draft-ietf-dnsext-tsig-sha-03.txt> <draft-ietf-dnsext-tsig-sha-04.txt>
Status of This Document Status of This Document
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
This draft is intended to be become a Proposed Standard RFC. This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
@@ -188,16 +187,16 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
authentication codes. The only specified HMAC based TSIG algorithm authentication codes. The only specified HMAC based TSIG algorithm
identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321]. identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
The use of SHA-1 [FIPS 180-1, RFC 3174], which is a 160 bit hash, as The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
compared with the 128 bits for MD5, and additional hash algorithms in compared with the 128 bits for MD5, and additional hash algorithms in
the SHA family [FIPS 180-2, RFC 3874] with 224, 256, 384, and 512 the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
bits, may be preferred in some cases particularly since increasingly and 512 bits, may be preferred in some cases particularly since
successful cryptanalytic attacks are being made on the shorter increasingly successful cryptanalytic attacks are being made on the
hashes. Use of TSIG between a DNS resolver and server is by mutual shorter hashes. Use of TSIG between a DNS resolver and server is by
agreement. That agreement can include the support of additional mutual agreement. That agreement can include the support of
algorithms and may specify policies as to which algorithms and additional algorithms and may specify policies as to which algorithms
truncations are acceptable subject to the restrication and guidelines and truncations are acceptable subject to the restrication and
in Section 3 and 4 below. guidelines in Section 3 and 4 below.
The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the
table below for convenience. Implementations which support TSIG MUST table below for convenience. Implementations which support TSIG MUST
@@ -435,15 +434,16 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
the stronger SHA-1 and SHA-256 algorithms are being made mandatory the stronger SHA-1 and SHA-256 algorithms are being made mandatory
due to caution. due to caution.
See also the Security Considerations section of [RFC 2845] from which See the Security Considerations section of [RFC 2845]. See also the
the limits on truncation in this RFC were taken. Security Considerations section of [RFC 2104] from which the limits
on truncation in this RFC were taken.
6. Copyright and Disclaimer 6. Copyright and Disclaimer
Copyright (C) The Internet Society 2005. This document is subject to Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78 and except the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights. as set forth therein, the authors retain all their rights.
@@ -460,7 +460,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
D. Eastlake 3rd [Page 8] D. Eastlake 3rd [Page 8]
@@ -501,11 +500,11 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
2003. 2003.
[RFC 3874] - "A 224-bit One-way Hash Function: SHA-224", R. Housley, [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
September 2004, September 2004,
[SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
(SHA)", work in progress.
@@ -540,9 +539,9 @@ Author's Address
Expiration and File Name Expiration and File Name
This draft expires in October 2005. This draft expires in December 2005.
Its file name is draft-ietf-dnsext-tsig-sha-03.txt Its file name is draft-ietf-dnsext-tsig-sha-04.txt
@@ -579,4 +578,3 @@ Expiration and File Name
D. Eastlake 3rd [Page 10] D. Eastlake 3rd [Page 10]