ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2004-10-27 00:41:02 +00:00
parent 783707ee55
commit d7d8197c4b
13 changed files with 6784 additions and 2745 deletions
Download Patch File Download Diff File Expand all files Collapse all files

504
doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt → doc/draft/draft-ietf-dnsext-dnssec-intro-13.txt
View File

@@ -2,7 +2,7 @@
DNS Extensions R. Arends
Internet-Draft Telematica Instituut
Expires: January 13, 2005 R. Austein
Expires: April 10, 2005 R. Austein
ISC
M. Larson
VeriSign
@@ -10,17 +10,19 @@ Expires: January 13, 2005 R. Austein
USC/ISI
S. Rose
NIST
July 15, 2004
October 10, 2004
DNS Security Introduction and Requirements
draft-ietf-dnsext-dnssec-intro-11
draft-ietf-dnsext-dnssec-intro-13
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
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
@@ -39,24 +41,24 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2005.
This Internet-Draft will expire on April 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2004).
Abstract
Arends, et al. Expires April 10, 2005 [Page 1]
Internet-Draft DNSSEC Introduction and Requirements October 2004
The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System. This
Arends, et al. Expires January 13, 2005 [Page 1]
Internet-Draft DNSSEC Introduction and Requirements July 2004
document introduces these extensions, and describes their
capabilities and limitations. This document also discusses the
services that the DNS security extensions do and do not provide.
@@ -69,7 +71,7 @@ Table of Contents
2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4
3. Services Provided by DNS Security . . . . . . . . . . . . . . 8
3.1 Data Origin Authentication and Data Integrity . . . . . . 8
3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9
3.2 Authenticating Name and Type Non-Existence . . . . . . . . 10
4. Services Not Provided by DNS Security . . . . . . . . . . . . 11
5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12
6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14
@@ -106,11 +108,9 @@ Table of Contents
Arends, et al. Expires January 13, 2005 [Page 2]
Arends, et al. Expires April 10, 2005 [Page 2]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
1. Introduction
@@ -119,25 +119,24 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
(DNSSEC). This document and its two companion documents
([I-D.ietf-dnsext-dnssec-records] and
[I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the
security extensions defined in RFC 2535 [RFC2535] and its
predecessors. These security extensions consist of a set of new
resource record types and modifications to the existing DNS protocol
[RFC1035]. The new records and protocol modifications are not fully
described in this document, but are described in a family of
documents outlined in Section 10. Section 3 and Section 4 describe
the capabilities and limitations of the security extensions in
greater detail. Section 5 discusses the scope of the document set.
Section 6, Section 7, Section 8, and Section 9 discuss the effect
that these security extensions will have on resolvers, stub
resolvers, zones and name servers.
security extensions defined in [RFC2535] and its predecessors. These
security extensions consist of a set of new resource record types and
modifications to the existing DNS protocol ([RFC1035]). The new
records and protocol modifications are not fully described in this
document, but are described in a family of documents outlined in
Section 10. Section 3 and Section 4 describe the capabilities and
limitations of the security extensions in greater detail. Section 5
discusses the scope of the document set. Section 6, Section 7,
Section 8, and Section 9 discuss the effect that these security
extensions will have on resolvers, stub resolvers, zones and name
servers.
This document and its two companions update and obsolete RFCs 2535
[RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655
[RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress
[I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but
does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
[RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts
of 3226 [RFC3226] (dealing with DNSSEC).
This document and its two companions obsolete [RFC2535], [RFC3008],
[RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
[RFC3845]. This document set also updates, but does not obsolete,
[RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
[RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
DNSSEC.
The DNS security extensions provide origin authentication and
integrity protection for DNS data, as well as a means of public key
@@ -164,9 +163,10 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 3]
Arends, et al. Expires April 10, 2005 [Page 3]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
2. Definitions of Important DNSSEC Terms
@@ -177,23 +177,24 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
section quickly, read the rest of this document, then come back to
this section.
Authentication Chain: An alternating sequence of DNSKEY RRsets and DS
RRsets forms a chain of signed data, with each link in the chain
vouching for the next. A DNSKEY RR is used to verify the
signature covering a DS RR and allows the DS RR to be
authenticated. The DS RR contains a hash of another DNSKEY RR and
this new DNSKEY RR is authenticated by matching the hash in the DS
RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset
and, in turn, some DNSKEY RR in this set may be used to
authenticate another DS RR and so forth until the chain finally
ends with a DNSKEY RR whose corresponding private key signs the
desired DNS data. For example, the root DNSKEY RRset can be used
to authenticate the DS RRset for "example." The "example." DS
RRset contains a hash that matches some "example." DNSKEY, and
this DNSKEY's corresponding private key signs the "example."
DNSKEY RRset. Private key counterparts of the "example." DNSKEY
RRset sign data records such as "www.example." as well as DS RRs
for delegations such as "subzone.example."
Authentication Chain: An alternating sequence of DNS public key
(DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
signed data, with each link in the chain vouching for the next. A
DNSKEY RR is used to verify the signature covering a DS RR and
allows the DS RR to be authenticated. The DS RR contains a hash
of another DNSKEY RR and this new DNSKEY RR is authenticated by
matching the hash in the DS RR. This new DNSKEY RR in turn
authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
this set may be used to authenticate another DS RR and so forth
until the chain finally ends with a DNSKEY RR whose corresponding
private key signs the desired DNS data. For example, the root
DNSKEY RRset can be used to authenticate the DS RRset for
"example." The "example." DS RRset contains a hash that matches
some "example." DNSKEY, and this DNSKEY's corresponding private
key signs the "example." DNSKEY RRset. Private key counterparts
of the "example." DNSKEY RRset sign data records such as
"www.example." as well as DS RRs for delegations such as
"subzone.example."
Authentication Key: A public key that a security-aware resolver has
verified and can therefore use to authenticate data. A
@@ -211,19 +212,32 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
even if the local policy is simply to authenticate any new public
key for which the resolver is able verify the signature.
Authoritative RRset: Within the context of a particular zone, an
RRset is "authoritative" if and only if the owner name of the
RRset lies within the subset of the name space that is at or below
the zone apex and at or above the cuts that separate the zone from
its children, if any. All RRsets at the zone apex are
Arends, et al. Expires April 10, 2005 [Page 4]
Internet-Draft DNSSEC Introduction and Requirements October 2004
authoritative, except for certain RRsets at this domain name that,
if present, belong to this zone's parent. These RRset could
include a DS RRset, the NSEC RRset referencing this DS RRset (the
"parental NSEC"), and RRSIG RRs associated with these RRsets, all
of which are authoritative in the parent zone. Similarly, if this
zone contains any delegation points, only the parental NSEC RRset,
DS RRsets, and any RRSIG RRs associated with these these RRsets
are authoritative for this zone.
Delegation Point: Term used to describe the name at the parental side
of a zone cut. That is, the delegation point for "foo.example"
would be the foo.example node in the "example" zone (as opposed to
the zone apex of the "foo.example" zone).
Arends, et al. Expires January 13, 2005 [Page 4]
Internet-Draft DNSSEC Introduction and Requirements July 2004
the zone apex of the "foo.example" zone). See also: zone apex.
Island of Security: Term used to describe a signed, delegated zone
that does not have an authentication chain from its delegating
@@ -259,6 +273,14 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
responses, and is capable of establishing an appropriately secured
channel to a security-aware recursive name server which will
provide these services on behalf of the security-aware stub
Arends, et al. Expires April 10, 2005 [Page 5]
Internet-Draft DNSSEC Introduction and Requirements October 2004
resolver. See also: security-aware stub resolver, validating
security-aware stub resolver.
@@ -270,15 +292,10 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
DNS security extensions defined in this document set. In
particular, a security-aware name server is an entity which
receives DNS queries, sends DNS responses, supports the EDNS0
[RFC2671] message size extension and the DO bit [RFC3225], and
([RFC2671]) message size extension and the DO bit ([RFC3225]), and
supports the RR types and message header bits defined in this
document set.
Arends, et al. Expires January 13, 2005 [Page 5]
Security-Aware Recursive Name Server: An entity which acts in both
the security-aware name server and security-aware resolver roles.
A more cumbersome equivalent phrase would be "a security-aware
@@ -288,10 +305,10 @@ Arends, et al. Expires January 13, 2005 [Page 5]
(defined in section 2.4 of [RFC1034]) which understands the DNS
security extensions defined in this document set. In particular,
a security-aware resolver is an entity which sends DNS queries,
receives DNS responses, supports the EDNS0 [RFC2671] message size
extension and the DO bit [RFC3225], and is capable of using the RR
types and message header bits defined in this document set to
provide DNSSEC services.
receives DNS responses, supports the EDNS0 ([RFC2671]) message
size extension and the DO bit ([RFC3225]), and is capable of using
the RR types and message header bits defined in this document set
to provide DNSSEC services.
Security-Aware Stub Resolver: An entity acting in the role of a stub
resolver (defined in section 5.3.1 of [RFC1034]) which has enough
@@ -307,8 +324,18 @@ Arends, et al. Expires January 13, 2005 [Page 5]
"security-aware".
Signed Zone: A zone whose RRsets are signed and which contains
properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS
records.
properly constructed DNSKEY, Resource Record Signature (RRSIG),
Next Secure (NSEC) and (optionally) DS records.
Arends, et al. Expires April 10, 2005 [Page 6]
Internet-Draft DNSSEC Introduction and Requirements October 2004
Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A
validating security-aware resolver uses this public key or hash as
@@ -328,18 +355,12 @@ Arends, et al. Expires January 13, 2005 [Page 5]
security-aware stub resolver, non-validating security-aware stub
resolver.
Arends, et al. Expires January 13, 2005 [Page 6]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Validating Stub Resolver: A less tedious term for a validating
security-aware stub resolver.
Zone Apex: Term used to describe the name at the child's side of a
zone cut. See also: delegation point.
Zone Signing Key (ZSK): An authentication key that corresponds to a
private key used to sign a zone. Typically a zone signing key
will be part of the same DNSKEY RRset as the key signing key whose
@@ -367,30 +388,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 7]
Arends, et al. Expires April 10, 2005 [Page 7]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
3. Services Provided by DNS Security
@@ -401,16 +401,19 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
data. These mechanisms are described below.
These mechanisms require changes to the DNS protocol. DNSSEC adds
four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two
new message header bits (CD and AD). In order to support the larger
DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support
for the DO bit [RFC3225], so that a security-aware resolver can
indicate in its queries that it wishes to receive DNSSEC RRs in
response messages.
four new resource record types: Resource Record Signature, DNS Public
Key, Delegation Signer, and Next Secure (RRSIG, DNSKEY, DS and NSEC)
and two new message header bits: Checking Disabled and Authenticated
Data (CD and AD). In order to support the larger DNS message sizes
that result from adding the DNSSEC RRs, DNSSEC also requires EDNS0
support ([RFC2671]). Finally, DNSSEC requires support for the DNSSEC
OK (DO) EDNS header bit ([RFC3225]), so that a security-aware
resolver can indicate in its queries that it wishes to receive DNSSEC
RRs in response messages.
These services protect against most of the threats to the Domain Name
System described in [I-D.ietf-dnsext-dns-threats].
System described in [RFC3833]. Please see Section 12 for a
discussion of the limitations of these extensions.
3.1 Data Origin Authentication and Data Integrity
@@ -438,29 +441,31 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
offline when practical to do so. To discover a public key reliably
via DNS resolution, the target key itself needs to be signed by
either a configured authentication key or another key that has been
Arends, et al. Expires April 10, 2005 [Page 8]
Internet-Draft DNSSEC Introduction and Requirements October 2004
authenticated previously. Security-aware resolvers authenticate zone
information by forming an authentication chain from a newly learned
public key back to a previously known authentication public key,
Arends, et al. Expires January 13, 2005 [Page 8]
Internet-Draft DNSSEC Introduction and Requirements July 2004
which in turn either has been configured into the resolver or must
have been learned and verified previously. Therefore, the resolver
must be configured with at least one trust anchor. If the configured
key is a zone signing key, then it will authenticate the associated
zone; if the configured key is a key signing key, it will
authenticate a zone signing key. If the resolver has been configured
with the hash of a key rather than the key itself, the resolver may
need to obtain the key via a DNS query. To help security-aware
resolvers establish this authentication chain, security-aware name
servers attempt to send the signature(s) needed to authenticate a
zone's public key(s) in the DNS reply message along with the public
key itself, provided there is space available in the message.
must be configured with at least one trust anchor.
If the configured trust anchor is a zone signing key, then it will
authenticate the associated zone; if the configured key is a key
signing key, it will authenticate a zone signing key. If the
configured trust anchor is the hash of a key rather than the key
itself, the resolver may need to obtain the key via a DNS query. To
help security-aware resolvers establish this authentication chain,
security-aware name servers attempt to send the signature(s) needed
to authenticate a zone's public key(s) in the DNS reply message along
with the public key itself, provided there is space available in the
message.
The Delegation Signer (DS) RR type simplifies some of the
administrative tasks involved in signing delegations across
@@ -492,19 +497,19 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
protocol extensions defined in this document set. See Section 5 for
further discussion.
Arends, et al. Expires April 10, 2005 [Page 9]
Internet-Draft DNSSEC Introduction and Requirements October 2004
3.2 Authenticating Name and Type Non-Existence
The security mechanism described in Section 3.1 only provides a way
to sign existing RRsets in a zone. The problem of providing negative
responses with the same level of authentication and integrity
Arends, et al. Expires January 13, 2005 [Page 9]
Internet-Draft DNSSEC Introduction and Requirements July 2004
requires the use of another new resource record type, the NSEC
record. The NSEC record allows a security-aware resolver to
authenticate a negative reply for either name or type non-existence
@@ -551,14 +556,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 10]
Arends, et al. Expires April 10, 2005 [Page 10]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
4. Services Not Provided by DNS Security
@@ -578,9 +578,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
The DNS security extensions provide data and origin authentication
for DNS data. The mechanisms outlined above are not designed to
protect operations such as zone transfers and dynamic update
[RFC3007]. Message authentication schemes described in [RFC2845] and
[RFC2931] address security operations that pertain to these
transactions.
([RFC2136], [RFC3007]). Message authentication schemes described in
[RFC2845] and [RFC2931] address security operations that pertain to
these transactions.
@@ -612,9 +612,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 11]
Arends, et al. Expires April 10, 2005 [Page 11]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
5. Scope of the DNSSEC Document Set and Last Hop Issues
@@ -668,9 +668,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 12]
Arends, et al. Expires April 10, 2005 [Page 12]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
the lack of the specification of such communication does not prohibit
@@ -724,9 +724,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 13]
Arends, et al. Expires April 10, 2005 [Page 13]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
6. Resolver Considerations
@@ -744,13 +744,19 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
If a security-aware resolver is separated from the relevant
authoritative name servers by a recursive name server or by any sort
of device which acts as a proxy for DNS, and if the recursive name
server or proxy is not security-aware, the security-aware resolver
may not be capable of operating in a secure mode. For example, if a
security-aware resolver's packets are routed through a network
address translation device that includes a DNS proxy which is not
security-aware, the security-aware resolver may find it difficult or
impossible to obtain or validate signed DNS data.
of intermediary device which acts as a proxy for DNS, and if the
recursive name server or intermediary device is not security-aware,
the security-aware resolver may not be capable of operating in a
secure mode. For example, if a security-aware resolver's packets are
routed through a network address translation (NAT) device that
includes a DNS proxy which is not security-aware, the security-aware
resolver may find it difficult or impossible to obtain or validate
signed DNS data. The security-aware resolver may have a particularly
difficult time obtaining DS RRs in such a case, since DS RRs do not
follow the usual DNS rules for ownership of RRs at zone cuts. Note
that this problem is not specific to NATs -- any security-oblivious
DNS software of any kind between the security-aware resolver and the
authoritative name servers will interfere with DNSSEC.
If a security-aware resolver must rely on an unsigned zone or a name
server that is not security aware, the resolver may not be able to
@@ -764,7 +770,7 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
security-aware resolver's own clock is wrong. Thus, a security-aware
resolver which is part of a security-aware recursive name server will
need to pay careful attention to the DNSSEC "checking disabled" (CD)
bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid
bit ([I-D.ietf-dnsext-dnssec-records]). This is in order to avoid
blocking valid signatures from getting through to other
security-aware resolvers which are clients of this recursive name
server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure
@@ -774,15 +780,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 14]
Arends, et al. Expires April 10, 2005 [Page 14]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
7. Stub Resolver Considerations
@@ -806,20 +806,20 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
place itself at the mercy of the recursive name servers that it uses,
since it does not perform DNSSEC validity checks on its own. The
second issue requires some kind of channel security mechanism; proper
use of DNS transaction authentication mechanisms such as SIG(0) or
TSIG would suffice, as would appropriate use of IPsec, and particular
implementations may have other choices available, such as operating
system specific interprocess communication mechanisms.
Confidentiality is not needed for this channel, but data integrity
and message authentication are.
use of DNS transaction authentication mechanisms such as SIG(0)
([RFC2931]) or TSIG ([RFC2845]) would suffice, as would appropriate
use of IPsec, and particular implementations may have other choices
available, such as operating system specific interprocess
communication mechanisms. Confidentiality is not needed for this
channel, but data integrity and message authentication are.
A security-aware stub resolver that does trust both its recursive
name servers and its communication channel to them may choose to
examine the setting of the AD bit in the message header of the
response messages it receives. The stub resolver can use this flag
bit as a hint to find out whether the recursive name server was able
to validate signatures for all of the data in the Answer and
Authority sections of the response.
examine the setting of the Authenticated Data (AD) bit in the message
header of the response messages it receives. The stub resolver can
use this flag bit as a hint to find out whether the recursive name
server was able to validate signatures for all of the data in the
Answer and Authority sections of the response.
There is one more step that a security-aware stub resolver can take
if, for whatever reason, it is not able to establish a useful trust
@@ -836,9 +836,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 15]
Arends, et al. Expires April 10, 2005 [Page 15]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
8. Zone Considerations
@@ -862,14 +862,14 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
RRsets, regardless of whether or not the resolver is security-aware.
The inception and expiration fields in the RRSIG RR
[I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time
period during which the signature can be used to validate the covered
RRset. The signatures associated with signed zone data are only
valid for the time period specified by these fields in the RRSIG RRs
in question. TTL values cannot extend the validity period of signed
RRsets in a resolver's cache, but the resolver may use the time
remaining before expiration of the signature validity period of a
signed RRset as an upper bound for the TTL of the signed RRset and
([I-D.ietf-dnsext-dnssec-records]), on the other hand, specify the
time period during which the signature can be used to validate the
covered RRset. The signatures associated with signed zone data are
only valid for the time period specified by these fields in the RRSIG
RRs in question. TTL values cannot extend the validity period of
signed RRsets in a resolver's cache, but the resolver may use the
time remaining before expiration of the signature validity period of
a signed RRset as an upper bound for the TTL of the signed RRset and
its associated RRSIG RR in the resolver's cache.
8.2 New Temporal Dependency Issues for Zones
@@ -892,9 +892,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 16]
Arends, et al. Expires April 10, 2005 [Page 16]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
9. Name Server Considerations
@@ -948,9 +948,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 17]
Arends, et al. Expires April 10, 2005 [Page 17]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
10. DNS Security Document Family
@@ -975,7 +975,10 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
to the group of documents that describe how specific digital
signature algorithms should be implemented to fit the DNSSEC resource
record format. Each document in this set deals with a specific
digital signature algorithm.
digital signature algorithm. Please see the appendix on "DNSSEC
Algorithm and Digest Types" in [I-D.ietf-dnsext-dnssec-records] for a
list of the algorithms that were defined at the time this core
specification was written.
The "Transaction Authentication Protocol" document set refers to the
group of documents that deal with DNS message authentication,
@@ -988,7 +991,7 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
related purposes. DNSSEC does not provide any direct security for
these new uses, but may be used to support them. Documents that fall
in this category include the use of DNS in the storage and
distribution of certificates [RFC2538].
distribution of certificates ([RFC2538]).
@@ -1001,12 +1004,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 18]
Arends, et al. Expires April 10, 2005 [Page 18]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
11. IANA Considerations
@@ -1060,9 +1060,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 19]
Arends, et al. Expires April 10, 2005 [Page 19]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
12. Security Considerations
@@ -1071,8 +1071,8 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
the document set that contains the new security records and DNS
protocol modifications. The extensions provide data origin
authentication and data integrity using digital signatures over
resource record sets.This document discusses the capabilities and
limitations of these extensions.
resource record sets. This section discusses the limitations of
these extensions.
In order for a security-aware resolver to validate a DNS response,
all zones along the path from the trusted starting point to the zone
@@ -1089,8 +1089,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
This document briefly discusses other methods of adding security to a
DNS query, such as using a channel secured by IPsec or using a DNS
transaction authentication mechanism, but transaction security is not
part of DNSSEC per se.
transaction authentication mechanism such as TSIG ([RFC2845]) or
SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC
per se.
A non-validating security-aware stub resolver, by definition, does
not perform DNSSEC signature validation on its own, and thus is
@@ -1112,15 +1113,15 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
attacks takes at least two forms. An attacker may be able to consume
resources in a security-aware resolver's signature validation code by
tampering with RRSIG RRs in response messages or by constructing
needlessly complex signature chains. An attacker may also be able to
Arends, et al. Expires January 13, 2005 [Page 20]
Arends, et al. Expires April 10, 2005 [Page 20]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
needlessly complex signature chains. An attacker may also be able to
consume resources in a security-aware name server which supports DNS
dynamic update, by sending a stream of update messages that force the
security-aware name server to re-sign some RRsets in the zone more
@@ -1151,8 +1152,8 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
data itself is vulnerable to tampering during zone transfer
operations. Thus, while DNSSEC can provide data origin
authentication and data integrity for RRsets, it cannot do so for
zones, and other mechanisms must be used to protect zone transfer
operations.
zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be
used to protect zone transfer operations.
Please see [I-D.ietf-dnsext-dnssec-records] and
[I-D.ietf-dnsext-dnssec-protocol] for additional security
@@ -1171,10 +1172,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 21]
Arends, et al. Expires April 10, 2005 [Page 21]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
13. Acknowledgements
@@ -1194,10 +1194,10 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid,
Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob
Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and
Suzanne Woolf.
Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob
Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz,
Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler,
Brian Wellington, and Suzanne Woolf.
No doubt the above list is incomplete. We apologize to anyone we
left out.
@@ -1228,9 +1228,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 22]
Arends, et al. Expires April 10, 2005 [Page 22]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
14. References
@@ -1272,23 +1272,6 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
14.2 Informative References
[I-D.ietf-dnsext-dns-threats]
Atkins, D. and R. Austein, "Threat Analysis Of The Domain
Name System", draft-ietf-dnsext-dns-threats-07 (work in
progress), April 2004.
[I-D.ietf-dnsext-nsec-rdata]
Schlyter, J., "DNSSEC NSEC RDATA Format",
draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
2004.
Arends, et al. Expires January 13, 2005 [Page 23]
Internet-Draft DNSSEC Introduction and Requirements July 2004
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
@@ -1299,6 +1282,13 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
Arends, et al. Expires April 10, 2005 [Page 23]
Internet-Draft DNSSEC Introduction and Requirements October 2004
[RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
the Domain Name System (DNS)", RFC 2538, March 1999.
@@ -1333,6 +1323,11 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
[RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
Entry Point Flag", RFC 3757, April 2004.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
RDATA Format", RFC 3845, August 2004.
@@ -1340,9 +1335,14 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004
Arends, et al. Expires January 13, 2005 [Page 24]
Arends, et al. Expires April 10, 2005 [Page 24]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
Authors' Addresses
@@ -1396,9 +1396,9 @@ Authors' Addresses
Arends, et al. Expires January 13, 2005 [Page 25]
Arends, et al. Expires April 10, 2005 [Page 25]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Internet-Draft DNSSEC Introduction and Requirements October 2004
Intellectual Property Statement
@@ -1452,6 +1452,6 @@ Acknowledgment
Arends, et al. Expires January 13, 2005 [Page 26]
Arends, et al. Expires April 10, 2005 [Page 26]

900
doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt → doc/draft/draft-ietf-dnsext-dnssec-protocol-09.txt
View File

File diff suppressed because it is too large Load Diff

334
doc/draft/draft-ietf-dnsext-dnssec-records-09.txt → doc/draft/draft-ietf-dnsext-dnssec-records-11.txt
View File

@@ -2,7 +2,7 @@
DNS Extensions R. Arends
Internet-Draft Telematica Instituut
Expires: January 13, 2005 R. Austein
Expires: April 10, 2005 R. Austein
ISC
M. Larson
VeriSign
@@ -10,17 +10,19 @@ Expires: January 13, 2005 R. Austein
USC/ISI
S. Rose
NIST
July 15, 2004
October 10, 2004
Resource Records for the DNS Security Extensions
draft-ietf-dnsext-dnssec-records-09
draft-ietf-dnsext-dnssec-records-11
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
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
@@ -39,24 +41,24 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2005.
This Internet-Draft will expire on April 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2004).
Abstract
Arends, et al. Expires April 10, 2005 [Page 1]
Internet-Draft DNSSEC Resource Records October 2004
This document is part of a family of documents that describes the DNS
Security Extensions (DNSSEC). The DNS Security Extensions are a
Arends, et al. Expires January 13, 2005 [Page 1]
Internet-Draft DNSSEC Resource Records July 2004
collection of resource records and protocol modifications that
provide source authentication for the DNS. This document defines the
public key (DNSKEY), delegation signer (DS), resource record digital
@@ -92,7 +94,7 @@ Table of Contents
3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 11
3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 11
3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 12
3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12
3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 13
4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14
4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14
4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 14
@@ -103,16 +105,16 @@ Table of Contents
5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18
5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18
5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 19
Arends, et al. Expires April 10, 2005 [Page 2]
Internet-Draft DNSSEC Resource Records October 2004
5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 19
5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 19
Arends, et al. Expires January 13, 2005 [Page 2]
Internet-Draft DNSSEC Resource Records July 2004
5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 19
5.2 Processing of DS RRs When Validating Responses . . . . . . 19
5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 20
@@ -162,43 +164,46 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 3]
Arends, et al. Expires April 10, 2005 [Page 3]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
1. Introduction
The DNS Security Extensions (DNSSEC) introduce four new DNS resource
record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the
purpose of each resource record (RR), the RR's RDATA format, and its
presentation format (ASCII representation).
record types: DNS Public Key (DNSKEY), Resource Record Signature
(RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This
document defines the purpose of each resource record (RR), the RR's
RDATA format, and its presentation format (ASCII representation).
1.1 Background and Related Documents
The reader is assumed to be familiar with the basic DNS concepts
described in [RFC1034], [RFC1035] and subsequent RFCs that update
them: [RFC2136], [RFC2181] and [RFC2308].
This document is part of a family of documents that define DNSSEC,
which should be read together as a set.
This document is part of a family of documents that define the DNS
security extensions. The DNS security extensions (DNSSEC) are a
collection of resource records and DNS protocol modifications that
add source authentication and data integrity to the Domain Name
System (DNS). An introduction to DNSSEC and definitions of common
terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is
assumed to be familiar with this document. A description of DNS
protocol modifications can be found in
[I-D.ietf-dnsext-dnssec-protocol].
[I-D.ietf-dnsext-dnssec-intro] contains an introduction to DNSSEC and
definition of common terms; the reader is assumed to be familiar with
this document. [I-D.ietf-dnsext-dnssec-intro] also contains a list
of other documents updated by and obsoleted by this document set.
[I-D.ietf-dnsext-dnssec-protocol] defines the DNSSEC protocol
operations.
The reader is also assumed to be familiar with the basic DNS concepts
described in [RFC1034], [RFC1035], and the subsequent documents that
update them, particularly [RFC2181] and [RFC2308].
This document defines the DNSSEC resource records.
All numeric DNS type codes given in this document are decimal
integers.
1.2 Reserved Words
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 [RFC2119].
document are to be interpreted as described in [RFC2119].
@@ -215,14 +220,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 4]
Arends, et al. Expires April 10, 2005 [Page 4]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
2. The DNSKEY Resource Record
@@ -233,7 +233,8 @@ Internet-Draft DNSSEC Resource Records July 2004
described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its
authoritative RRsets using a private key and stores the corresponding
public key in a DNSKEY RR. A resolver can then use the public key to
authenticate signatures covering the RRsets in the zone.
validate signatures covering the RRsets in the zone, and thus
authenticate them.
The DNSKEY RR is not intended as a record for storing arbitrary
public keys and MUST NOT be used to store certificates or public keys
@@ -272,15 +273,15 @@ Internet-Draft DNSSEC Resource Records July 2004
Bit 15 of the Flags field is the Secure Entry Point flag, described
in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a
key intended for use as a secure entry point. This flag is only
Arends, et al. Expires January 13, 2005 [Page 5]
Arends, et al. Expires April 10, 2005 [Page 5]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
key intended for use as a secure entry point. This flag is only
intended to be to a hint to zone signing or debugging software as to
the intended use of this DNSKEY record; validators MUST NOT alter
their behavior during the signature validation process in any way
@@ -328,15 +329,16 @@ Internet-Draft DNSSEC Resource Records July 2004
with a value of 3.
The Algorithm field MUST be represented either as an unsigned decimal
integer or as an algorithm mnemonic as specified in Appendix A.1.
Arends, et al. Expires January 13, 2005 [Page 6]
Arends, et al. Expires April 10, 2005 [Page 6]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
integer or as an algorithm mnemonic as specified in Appendix A.1.
The Public Key field MUST be represented as a Base64 encoding of the
Public Key. Whitespace is allowed within the Base64 text. For a
definition of Base64 encoding, see [RFC3548].
@@ -386,11 +388,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 7]
Arends, et al. Expires April 10, 2005 [Page 7]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
3. The RRSIG Resource Record
@@ -444,9 +444,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 8]
Arends, et al. Expires April 10, 2005 [Page 8]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
@@ -500,9 +500,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 9]
Arends, et al. Expires April 10, 2005 [Page 9]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
The value of the Labels field MUST NOT count either the null (root)
@@ -535,12 +535,12 @@ Internet-Draft DNSSEC Resource Records July 2004
authentication prior to the inception date and MUST NOT be used for
authentication after the expiration date.
Signature Expiration and Inception field values are in POSIX.1 time
format: a 32-bit unsigned number of seconds elapsed since 1 January
1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The
longest interval which can be expressed by this format without
wrapping is approximately 136 years. An RRSIG RR can have an
Expiration field value which is numerically smaller than the
The Signature Expiration and Inception field values specify a date
and time in the form of a 32-bit unsigned number of seconds elapsed
since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
byte order. The longest interval which can be expressed by this
format without wrapping is approximately 136 years. An RRSIG RR can
have an Expiration field value which is numerically smaller than the
Inception field value if the expiration field value is near the
32-bit wrap-around point or if the signature is long lived. Because
of this, all comparisons involving these fields MUST use "Serial
@@ -556,9 +556,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 10]
Arends, et al. Expires April 10, 2005 [Page 10]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
3.1.7 The Signer's Name Field
@@ -612,9 +612,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 11]
Arends, et al. Expires April 10, 2005 [Page 11]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
canonical form; and
@@ -643,14 +643,19 @@ Internet-Draft DNSSEC Resource Records July 2004
decimal integer.
The Signature Expiration Time and Inception Time field values MUST be
represented either as seconds since 1 January 1970 00:00:00 UTC or in
the form YYYYMMDDHHmmSS in UTC, where:
represented either as an unsigned decimal integer indicating seconds
since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in
UTC, where:
YYYY is the year (0001-9999, but see Section 3.1.5);
MM is the month number (01-12);
DD is the day of the month (01-31);
HH is the hour in 24 hours notation (00-23);
mm is the minute (00-59); and
SS is the second (00-59).
Note that it is always be possible to distinguish between these two
formats, because the YYYYMMDDHHmmSS format will always be exactly 14
digits, while the decimal representation of a 32-bit unsigned integer
can never be longer than 10 digits.
The Key Tag field MUST be represented as an unsigned decimal integer.
@@ -660,19 +665,19 @@ Internet-Draft DNSSEC Resource Records July 2004
signature. Whitespace is allowed within the Base64 text. See
Section 2.2.
Arends, et al. Expires April 10, 2005 [Page 12]
Internet-Draft DNSSEC Resource Records October 2004
3.3 RRSIG RR Example
The following RRSIG RR stores the signature for the A RRset of
host.example.com:
Arends, et al. Expires January 13, 2005 [Page 12]
Internet-Draft DNSSEC Resource Records July 2004
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
20030220173103 2642 example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
@@ -719,14 +724,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 13]
Arends, et al. Expires April 10, 2005 [Page 13]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
4. The NSEC Resource Record
@@ -756,7 +756,7 @@ Internet-Draft DNSSEC Resource Records July 2004
The NSEC RR is class independent.
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
field. This is in the spirit of negative caching [RFC2308].
field. This is in the spirit of negative caching ([RFC2308]).
4.1 NSEC RDATA Wire Format
@@ -780,9 +780,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 14]
Arends, et al. Expires April 10, 2005 [Page 14]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
last NSEC record in the zone is the name of the zone apex (the owner
@@ -836,9 +836,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 15]
Arends, et al. Expires April 10, 2005 [Page 15]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
interpreted as zero octets.
@@ -892,9 +892,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 16]
Arends, et al. Expires April 10, 2005 [Page 16]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
0x04 'h' 'o' 's' 't'
@@ -948,9 +948,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 17]
Arends, et al. Expires April 10, 2005 [Page 17]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
5. The DS Resource Record
@@ -1004,9 +1004,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 18]
Arends, et al. Expires April 10, 2005 [Page 18]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
5.1.1 The Key Tag Field
@@ -1060,9 +1060,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 19]
Arends, et al. Expires April 10, 2005 [Page 19]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC
@@ -1116,9 +1116,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 20]
Arends, et al. Expires April 10, 2005 [Page 20]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
6. Canonical Form and Order of Resource Records
@@ -1172,9 +1172,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 21]
Arends, et al. Expires April 10, 2005 [Page 21]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
@@ -1228,9 +1228,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 22]
Arends, et al. Expires April 10, 2005 [Page 22]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
7. IANA Considerations
@@ -1261,9 +1261,10 @@ Internet-Draft DNSSEC Resource Records July 2004
its use with the DNS security extensions. Each algorithm entry
could refer to an algorithm that can be used for zone signing,
transaction security (see [RFC2931]) or both. Values 6-251 are
available for assignment by IETF standards action. See Appendix A
for a full listing of the DNS Security Algorithm Numbers entries
at the time of writing and their status of use in DNSSEC.
available for assignment by IETF standards action ([RFC3755]).
See Appendix A for a full listing of the DNS Security Algorithm
Numbers entries at the time of writing and their status of use in
DNSSEC.
[RFC3658] created an IANA registry for DNSSEC DS Digest Types, and
assigned value 0 to reserved and value 1 to SHA-1.
@@ -1276,17 +1277,16 @@ Internet-Draft DNSSEC Resource Records July 2004
Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
this registry only contains an assignment for bit 7 (the ZONE bit)
and a reservation for bit 15 for the Secure Entry Point flag (SEP
bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by
IETF Standards Action.
this registry only contains assignments for bit 7 (the ZONE bit)
and bit 15 (the Secure Entry Point flag (SEP) bit, see [RFC3757]).
As also stated in [RFC3755], bits 0-6 and 8-14 are available for
assignment by IETF Standards Action.
Arends, et al. Expires January 13, 2005 [Page 23]
Arends, et al. Expires April 10, 2005 [Page 23]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
8. Security Considerations
@@ -1315,7 +1315,8 @@ Internet-Draft DNSSEC Resource Records July 2004
resource record. It is possible for two distinct DNSKEY RRs to have
the same owner name, the same algorithm type, and the same key tag.
An implementation which uses only the key tag to select a DNSKEY RR
might select the wrong public key in some circumstances.
might select the wrong public key in some circumstances. Please see
Appendix B for further details.
The table of algorithms in Appendix A and the key tag calculation
algorithms in Appendix B include the RSA/MD5 algorithm for
@@ -1339,10 +1340,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 24]
Arends, et al. Expires April 10, 2005 [Page 24]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
9. Acknowledgments
@@ -1396,9 +1396,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 25]
Arends, et al. Expires April 10, 2005 [Page 25]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
10. References
@@ -1439,6 +1439,9 @@ Internet-Draft DNSSEC Resource Records July 2004
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
@@ -1446,17 +1449,17 @@ Internet-Draft DNSSEC Resource Records July 2004
SIG(0)s)", RFC 2931, September 2000.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Arends, et al. Expires April 10, 2005 [Page 26]
Internet-Draft DNSSEC Resource Records October 2004
Name System (DNS)", RFC 3110, May 2001.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Arends, et al. Expires January 13, 2005 [Page 26]
Internet-Draft DNSSEC Resource Records July 2004
Resource Record (RR)", RFC 3445, December 2002.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
@@ -1476,17 +1479,21 @@ Internet-Draft DNSSEC Resource Records July 2004
10.2 Informative References
[I-D.ietf-dnsext-nsec-rdata]
Schlyter, J., "DNSSEC NSEC RDATA Format",
draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
2004.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
System (DNS)", RFC 2537, March 1999.
[RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
RDATA Format", RFC 3845, August 2004.
Authors' Addresses
@@ -1501,16 +1508,9 @@ Authors' Addresses
Arends, et al. Expires January 13, 2005 [Page 27]
Arends, et al. Expires April 10, 2005 [Page 27]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
Rob Austein
@@ -1564,9 +1564,9 @@ Internet-Draft DNSSEC Resource Records July 2004
Arends, et al. Expires January 13, 2005 [Page 28]
Arends, et al. Expires April 10, 2005 [Page 28]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
Appendix A. DNSSEC Algorithm and Digest Types
@@ -1600,11 +1600,11 @@ A.1 DNSSEC Algorithm Types
Value Algorithm [Mnemonic] Signing References Status
----- -------------------- --------- ---------- ---------
0 reserved
1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED
2 Diffie-Hellman [DH] n RFC 2539 -
3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL
1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED
2 Diffie-Hellman [DH] n [RFC2539] -
3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL
4 Elliptic Curve [ECC] TBA -
5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY
5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY
252 Indirect [INDIRECT] n -
253 Private [PRIVATEDNS] y see below OPTIONAL
254 Private [PRIVATEOID] y see below OPTIONAL
@@ -1620,9 +1620,9 @@ A.1.1 Private Algorithm Types
Arends, et al. Expires January 13, 2005 [Page 29]
Arends, et al. Expires April 10, 2005 [Page 29]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
domain name, which MUST NOT be compressed. The domain name indicates
@@ -1676,9 +1676,9 @@ A.2 DNSSEC Digest Types
Arends, et al. Expires January 13, 2005 [Page 30]
Arends, et al. Expires April 10, 2005 [Page 30]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
Appendix B. Key Tag Calculation
@@ -1713,7 +1713,7 @@ Appendix B. Key Tag Calculation
same input.
Please note that the algorithm for calculating the Key Tag is almost
but not completely identical to the familiar ones complement checksum
but not completely identical to the familiar ones-complement checksum
used in many other Internet protocols. Key Tags MUST be calculated
using the algorithm described here rather than the ones complement
checksum.
@@ -1732,9 +1732,9 @@ Appendix B. Key Tag Calculation
Arends, et al. Expires January 13, 2005 [Page 31]
Arends, et al. Expires April 10, 2005 [Page 31]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
/*
@@ -1788,9 +1788,9 @@ B.1 Key Tag for Algorithm 1 (RSA/MD5)
Arends, et al. Expires January 13, 2005 [Page 32]
Arends, et al. Expires April 10, 2005 [Page 32]
Internet-Draft DNSSEC Resource Records July 2004
Internet-Draft DNSSEC Resource Records October 2004
Intellectual Property Statement
@@ -1844,6 +1844,6 @@ Acknowledgment
Arends, et al. Expires January 13, 2005 [Page 33]
Arends, et al. Expires April 10, 2005 [Page 33]

814
doc/draft/draft-ietf-dnsext-ecc-key-05.txt Normal file
View File

@@ -0,0 +1,814 @@
<EFBFBD>©À
INTERNET-DRAFT ECC Keys in the DNS
Expires: February 2005 August 2004
Elliptic Curve KEYs in the DNS
-------- ----- ---- -- --- ---
<draft-ietf-dnsext-ecc-key-05.txt>
Richard C. Schroeppel
Donald Eastlake 3rd
Status of This Document
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent
to the DNS 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
The standard method for storing elliptic curve cryptographic keys in
the Domain Name System is specified.
Copyright Notice
Copyright (C) The Internet Society. All Rights Reserved.
R. Schroeppel, et al [Page 1]
INTERNET-DRAFT ECC Keys in the DNS
Acknowledgement
The assistance of Hilarie K. Orman in the production of this document
is greatfully acknowledged.
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Copyright Notice...........................................1
Acknowledgement............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Elliptic Curve Data in Resource Records.................3
3. The Elliptic Curve Equation.............................9
4. How do I Compute Q, G, and Y?..........................10
5. Performance Considerations.............................11
6. Security Considerations................................11
7. IANA Considerations....................................11
Copyright and Disclaimer..................................12
Informational References..................................13
Normative Refrences.......................................13
Authors Addresses.........................................14
Expiration and File Name..................................14
R. Schroeppel, et al [Page 2]
INTERNET-DRAFT ECC Keys in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. The DNS has been extended to include digital
signatures and cryptographic keys as described in [RFC intro,
protocol, records].
This document describes how to store elliptic curve cryptographic
(ECC) keys in the DNS so they can be used for a variety of security
purposes. A DNS elliptic curve SIG resource record is not defined.
Familiarity with ECC cryptography is assumed [Menezes].
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].
2. Elliptic Curve Data in Resource Records
Elliptic curve public keys are stored in the DNS within the RDATA
portions of key RRs with the structure shown below [RFC records].
The period of key validity may not be in the RR with the key but
could be indicated by RR(s) with signatures that authenticates the
RR(s) containing the key.
The research world continues to work on the issue of which is the
best elliptic curve system, which finite field to use, and how to
best represent elements in the field. So, representations are
defined for every type of finite field, and every type of elliptic
curve. The reader should be aware that there is a unique finite
field with a particular number of elements, but many possible
representations of that field and its elements. If two different
representations of a field are given, they are interconvertible with
a tedious but practical precomputation, followed by a fast
computation for each field element to be converted. It is perfectly
reasonable for an algorithm to work internally with one field
representation, and convert to and from a different external
representation.
R. Schroeppel, et al [Page 3]
INTERNET-DRAFT ECC Keys in the DNS
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S M -FMT- A B Z|
+-+-+-+-+-+-+-+-+
| LP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P (length determined from LP) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F (length determined from LF) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGJ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRDV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H (length determined from LH) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K (length determined from LK) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (length determined from LA) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ALTA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B (length determined from LB) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C (length determined from LC) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LG |
R. Schroeppel, et al [Page 4]
INTERNET-DRAFT ECC Keys in the DNS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G (length determined from LG) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Y (length determined from LY) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SMFMTABZ is a flags octet as follows:
S = 1 indicates that the remaining 7 bits of the octet selects
one of 128 predefined choices of finite field, element
representation, elliptic curve, and signature parameters.
MFMTABZ are omitted, as are all parameters from LP through G.
LY and Y are retained.
If S = 0, the remaining parameters are as in the picture and
described below.
M determines the type of field underlying the elliptic curve.
M = 0 if the field is a GF[2^N] field;
M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
FMT is a three bit field describing the format of the field
representation.
FMT = 0 for a (mod P) field.
> 0 for an extension field, either GF[2^D] or GF[P^D].
The degree D of the extension, and the field polynomial
must be specified. The field polynomial is always monic
(leading coefficient 1.)
FMT = 1 The field polynomial is given explicitly; D is implied.
If FMT >=2, the degree D is given explicitly.
= 2 The field polynomial is implicit.
= 3 The field polynomial is a binomial. P>2.
= 4 The field polynomial is a trinomial.
= 5 The field polynomial is the quotient of a trinomial by a
short polynomial. P=2.
= 6 The field polynomial is a pentanomial. P=2.
Flags A and B apply to the elliptic curve parameters.
R. Schroeppel, et al [Page 5]
INTERNET-DRAFT ECC Keys in the DNS
A = 1 When P>=5, the curve parameter A is negated. If P=2, then
A=1 indicates that the A parameter is special. See the
ALTA parameter below, following A. The combination A=1,
P=3 is forbidden.
B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
then B=1 indicates an alternate elliptic curve equation is
used. When P=2 and B=1, an additional curve parameter C
is present.
The Z bit SHOULD be set to zero on creation of an RR and MUST be
ignored when processing an RR (when S=0).
Most of the remaining parameters are present in some formats and
absent in others. The presence or absence of a parameter is
determined entirely by the flags. When a parameter occurs, it is in
the order defined by the picture.
Of the remaining parameters, PFHKQABCGY are variable length. When
present, each is preceded by a one-octet length field as shown in the
diagram above. The length field does not include itself. The length
field may have values from 0 through 110. The parameter length in
octets is determined by a conditional formula: If LL<=64, the
parameter length is LL. If LL>64, the parameter length is 16 times
(LL-60). In some cases, a parameter value of 0 is sensible, and MAY
be represented by an LL value of 0, with the data field omitted. A
length value of 0 represents a parameter value of 0, not an absent
parameter. (The data portion occupies 0 space.) There is no
requirement that a parameter be represented in the minimum number of
octets; high-order 0 octets are allowed at the front end. Parameters
are always right adjusted, in a field of length defined by LL. The
octet-order is always most-significant first, least-significant last.
The parameters H and K may have an optional sign bit stored in the
unused high-order bit of their length fields.
LP defines the length of the prime P. P must be an odd prime. The
parameters LP,P are present if and only if the flag M=1. If M=0, the
prime is 2.
LF,F define an explicit field polynomial. This parameter pair is
present only when FMT = 1. The length of a polynomial coefficient is
ceiling(log2 P) bits. Coefficients are in the numerical range
[0,P-1]. The coefficients are packed into fixed-width fields, from
higher order to lower order. All coefficients must be present,
including any 0s and also the leading coefficient (which is required
to be 1). The coefficients are right justified into the octet string
of length specified by LF, with the low-order "constant" coefficient
at the right end. As a concession to storage efficiency, the higher
order bits of the leading coefficient may be elided, discarding high-
order 0 octets and reducing LF. The degree is calculated by
R. Schroeppel, et al [Page 6]
INTERNET-DRAFT ECC Keys in the DNS
determining the bit position of the left most 1-bit in the F data
(counting the right most bit as position 0), and dividing by
ceiling(log2 P). The division must be exact, with no remainder. In
this format, all of the other degree and field parameters are
omitted. The next parameters will be LQ,Q.
If FMT>=2, the degree of the field extension is specified explicitly,
usually along with other parameters to define the field polynomial.
DEG is a two octet field that defines the degree of the field
extension. The finite field will have P^DEG elements. DEG is
present when FMT>=2.
When FMT=2, the field polynomial is specified implicitly. No other
parameters are required to define the field; the next parameters
present will be the LQ,Q pair. The implicit field poynomial is the
lexicographically smallest irreducible (mod P) polynomial of the
correct degree. The ordering of polynomials is by highest-degree
coefficients first -- the leading coefficient 1 is most important,
and the constant term is least important. Coefficients are ordered
by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of
degree D is X^D (which is not irreducible). The next is X^D+1, which
is sometimes irreducible, followed by X^D-1, which isn‚ÇÖt. Assuming
odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
X, X^D + X + 1, X^D + X - 1, etc.
When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
odd. The polynomial is determined by the degree and the low order
term K. Of all the field parameters, only the LK,K parameters are
present. The high-order bit of the LK octet stores on optional sign
for K; if the sign bit is present, the field polynomial is X^DEG - K.
When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
K. When P=2, the H and K parameters are implicitly 1, and are
omitted from the representation. Only DEG and DEGH are present; the
next parameters are LQ,Q. When P>2, then LH,H and LK,K are
specified. Either or both of LH, LK may contain a sign bit for its
parameter.
When FMT=5, then P=2 (only). The field polynomial is the exact
quotient of a trinomial divided by a small polynomial, the trinomial
divisor. The small polynomial is right-adjusted in the two octet
field TRDV. DEG specifies the degree of the field. The degree of
TRDV is calculated from the position of the high-order 1 bit. The
trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
DEGH is 0, the middle term is omitted from the trinomial. The
quotient must be exact, with no remainder.
When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
with the degrees of the middle terms given by the three 2-octet
R. Schroeppel, et al [Page 7]
INTERNET-DRAFT ECC Keys in the DNS
values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
> DEGJ > 0.
DEGH, DEGI, DEGJ are two-octet fields that define the degree of
a term in a field polynomial. DEGH is present when FMT = 4,
5, or 6. DEGI and DEGJ are present only when FMT = 6.
TRDV is a two-octet right-adjusted binary polynomial of degree <
16. It is present only for FMT=5.
LH and H define the H parameter, present only when FMT=4 and P
is odd. The high bit of LH is an optional sign bit for H.
LK and K define the K parameter, present when FMT = 3 or 4, and
P is odd. The high bit of LK is an optional sign bit for K.
The remaining parameters are concerned with the elliptic curve and
the signature algorithm.
LQ defines the length of the prime Q. Q is a prime > 2^159.
In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
member of the pair is an element from the finite field defined
earlier. The length field defines a long octet string. Field
elements are represented as (mod P) polynomials of degree < DEG, with
DEG or fewer coefficients. The coefficients are stored from left to
right, higher degree to lower, with the constant term last. The
coefficients are represented as integers in the range [0,P-1]. Each
coefficient is allocated an area of ceiling(log2 P) bits. The field
representation is right-justified; the "constant term" of the field
element ends at the right most bit. The coefficients are fitted
adjacently without regard for octet boundaries. (Example: if P=5,
three bits are used for each coefficient. If the field is GF[5^75],
then 225 bits are required for the coefficients, and as many as 29
octets may be needed in the data area. Fewer octets may be used if
some high-order coefficients are 0.) If a flag requires a field
element to be negated, each non-zero coefficient K is replaced with
P-K. To save space, 0 bits may be removed from the left end of the
element representation, and the length field reduced appropriately.
This would normally only happen with A,B,C, because the designer
chose curve parameters with some high-order 0 coefficients or bits.
If the finite field is simply (mod P), then the field elements are
simply numbers (mod P), in the usual right-justified notation. If
the finite field is GF[2^D], the field elements are the usual right-
justified polynomial basis representation.
R. Schroeppel, et al [Page 8]
INTERNET-DRAFT ECC Keys in the DNS
LA,A is the first parameter of the elliptic curve equation.
When P>=5, the flag A = 1 indicates A should be negated (mod
P). When P=2 (indicated by the flag M=0), the flag A = 1
indicates that the parameter pair LA,A is replaced by the two
octet parameter ALTA. In this case, the parameter A in the
curve equation is x^ALTA, where x is the field generator.
Parameter A often has the value 0, which may be indicated by
LA=0 (with no A data field), and sometimes A is 1, which may
be represented with LA=1 and a data field of 1, or by setting
the A flag and using an ALTA value of 0.
LB,B is the second parameter of the elliptic curve equation.
When P>=5, the flag B = 1 indicates B should be negated (mod
P). When P=2 or 3, the flag B selects an alternate curve
equation.
LC,C is the third parameter of the elliptic curve equation,
present only when P=2 (indicated by flag M=0) and flag B=1.
LG,G defines a point on the curve, of order Q. The W-coordinate
of the curve point is given explicitly; the Z-coordinate is
implicit.
LY,Y is the user‚ÇÖs public signing key, another curve point of
order Q. The W-coordinate is given explicitly; the Z-
coordinate is implicit. The LY,Y parameter pair is always
present.
3. The Elliptic Curve Equation
(The coordinates of an elliptic curve point are named W,Z instead of
the more usual X,Y to avoid confusion with the Y parameter of the
signing key.)
The elliptic curve equation is determined by the flag octet, together
with information about the prime P. The primes 2 and 3 are special;
all other primes are treated identically.
If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
+ A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
If A and/or B is negative (i.e., in the range from P/2 to P), and
P>=5, space may be saved by putting the sign bit(s) in the A and B
bits of the flags octet, and the magnitude(s) in the parameter
fields.
If M=1 and P=3, the B flag has a different meaning: it specifies an
alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
the right-hand-side is different. When P=3, this equation is more
R. Schroeppel, et al [Page 9]
INTERNET-DRAFT ECC Keys in the DNS
commonly used.
If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
parameter can often be 0 or 1, or be chosen as a single-1-bit value.
The flag B is used to select an alternate curve equation, Z^2 + C*Z =
W^3 + A*W + B. This is the only time that the C parameter is used.
4. How do I Compute Q, G, and Y?
The number of points on the curve is the number of solutions to the
curve equation, + 1 (for the "point at infinity"). The prime Q must
divide the number of points. Usually the curve is chosen first, then
the number of points is determined with Schoof‚ÇÖs algorithm. This
number is factored, and if it has a large prime divisor, that number
is taken as Q.
G must be a point of order Q on the curve, satisfying the equation
Q * G = the point at infinity (on the elliptic curve)
G may be chosen by selecting a random [RFC 1750] curve point, and
multiplying it by (number-of-points-on-curve/Q). G must not itself
be the "point at infinity"; in this astronomically unlikely event, a
new random curve point is recalculated.
G is specified by giving its W-coordinate. The Z-coordinate is
calculated from the curve equation. In general, there will be two
possible Z values. The rule is to choose the "positive" value.
In the (mod P) case, the two possible Z values sum to P. The smaller
value is less than P/2; it is used in subsequent calculations. In
GF[P^D] fields, the highest-degree non-zero coefficient of the field
element Z is used; it is chosen to be less than P/2.
In the GF[2^N] case, the two possible Z values xor to W (or to the
parameter C with the alternate curve equation). The numerically
smaller Z value (the one which does not contain the highest-order 1
bit of W (or C)) is used in subsequent calculations.
Y is specified by giving the W-coordinate of the user‚ÇÖs public
signature key. The Z-coordinate value is determined from the curve
equation. As with G, there are two possible Z values; the same rule
is followed for choosing which Z to use.
R. Schroeppel, et al [Page 10]
INTERNET-DRAFT ECC Keys in the DNS
During the key generation process, a random [RFC 1750] number X must
be generated such that 1 <= X <= Q-1. X is the private key and is
used in the final step of public key generation where Y is computed
as
Y = X * G (as points on the elliptic curve)
If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
in the (mod P) case, or the high-order non-zero coefficient of Z >
P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
GF[2^N] case), then X must be replaced with Q-X. This will
correspond to the correct Z-coordinate.
5. Performance Considerations
Elliptic curve signatures use smaller moduli or field sizes than RSA
and DSA. Creation of a curve is slow, but not done very often. Key
generation is faster than RSA or DSA.
DNS implementations have been optimized for small transfers,
typically less than 512 octets including DNS overhead. Larger
transfers will perform correctly and and extensions have been
standardized to make larger transfers more efficient [RFC 2671].
However, it is still advisable at this time to make reasonable
efforts to minimize the size of RR sets stored within the DNS
consistent with adequate security.
6. Security Considerations
Keys retrieved from the DNS should not be trusted unless (1) they
have been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and
dependent on local policy.
Some specific key generation considerations are given in the body of
this document.
7. IANA Considerations
Assignment of meaning to the remaining ECC data flag bits or to
values of ECC fields outside the ranges for which meaning in defined
R. Schroeppel, et al [Page 11]
INTERNET-DRAFT ECC Keys in the DNS
in this document requires an IETF consensus as defined in [RFC 2434].
Copyright and Disclaimer
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.
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.
R. Schroeppel, et al [Page 12]
INTERNET-DRAFT ECC Keys in the DNS
Informational References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and
facilities", 11/01/1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", 12/29/1994.
[RFC intro] - "DNS Security Introduction and Requirements", R.
Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress,
draft-ietf-dnsext-dnssec-intro-*.txt.
[RFC protocol] - "Protocol Modifications for the DNS Security
Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose,
work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt.
[RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August
1999.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[Menezes] - Alfred Menezes, "Elliptic Curve Public Key
Cryptosystems", 1993 Kluwer.
[Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves",
1986, Springer Graduate Texts in mathematics #106.
Normative Refrences
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", October 1998.
[RFC records] - "Resource Records for the DNS Security Extensions",
R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in
progress, draft-ietf-dnsext-dnssec-records- *.txt.
R. Schroeppel, et al [Page 13]
INTERNET-DRAFT ECC Keys in the DNS
Authors Addresses
Rich Schroeppel
500 S. Maple Drive
Woodland Hills, UT 84653 USA
Telephone: 1-801-423-7998(h)
1-505-844-9079(w)
Email: rschroe@sandia.gov
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-634-2066 (h)
+1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in February 2004.
Its file name is draft-ietf-dnsext-ecc-key-05.txt.
R. Schroeppel, et al [Page 14]

698
doc/draft/draft-ietf-dnsext-mdns-33.txt → doc/draft/draft-ietf-dnsext-mdns-37.txt
View File

File diff suppressed because it is too large Load Diff

464
doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-04.txt Normal file
View File

@@ -0,0 +1,464 @@
INTERNET-DRAFT DSA Information in the DNS
OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
Motorola Laboratories
Expires: February 2005 August 2004
DSA Keying and Signature Information in the DNS
--- ------ --- --------- ----------- -- --- ---
<draft-ietf-dnsext-rfc2536bis-dsa-04.txt>
Donald E. Eastlake 3rd
Status of This Document
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Distribution of this document is unlimited. Comments should be sent
to the DNS extensions 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
The standard method of encoding US Government Digital Signature
Algorithm keying and signature information for use in the Domain Name
System is specified.
Copyright Notice
Copyright (C) The Internet Society 2004. All Rights Reserved.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DSA Information in the DNS
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Copyright Notice...........................................1
Table of Contents..........................................2
1. Introduction............................................3
2. DSA Keying Information..................................3
3. DSA Signature Information...............................4
4. Performance Considerations..............................4
5. Security Considerations.................................5
6. IANA Considerations.....................................5
Copyright and Disclaimer...................................5
Normative References.......................................7
Informative References.....................................7
Authors Address............................................8
Expiration and File Name...................................8
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DSA Information in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information [RFC 1034, 1035]. The DNS has been extended to
include digital signatures and cryptographic keys as described in
[RFC intro, proto, records] and additional work is underway which
would require the storage of keying and signature information in the
DNS.
This document describes how to encode US Government Digital Signature
Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
2. DSA Keying Information
When DSA public keys are stored in the DNS, the structure of the
relevant part of the RDATA part of the RR being used is as shown
below.
The period of key validity is not included in this data but is
indicated separately, for example by an RR which signs and
authenticates the RR containing the keying information.
Field Size
----- ----
T 1 octet
Q 20 octets
P 64 + T*8 octets
G 64 + T*8 octets
Y 64 + T*8 octets
As described in [FIPS 186-2] and [Schneier], T is a key size
parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
is greater than 8 is reserved and the remainder of the data may have
a different format in that case.) Q is a prime number selected at
key generation time such that 2**159 < Q < 2**160 so Q is always 20
octets long and, as with all other fields, is stored in "big-endian"
network order. P, G, and Y are calculated as directed by the [FIPS
186-2] key generation algorithm [Schneier]. P is in the range
2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
and Y are quantities modulo P and so can be up to the same length as
P and are allocated fixed size fields with the same number of octets
as P.
During the key generation process, a random number X must be
generated such that 1 <= X <= Q-1. X is the private key and is used
in the final step of public key generation where Y is computed as
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DSA Information in the DNS
Y = G**X mod P
3. DSA Signature Information
The portion of the RDATA area used for US Digital Signature Algorithm
signature information is shown below with fields in the order they
occur.
Field Size
----- ----
T 1 octet
R 20 octets
S 20 octets
The data signed must be determined. Then the following steps are
taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
specified in the public key [Schneier]:
hash = SHA-1 ( data )
Generate a random K such that 0 < K < Q.
R = ( G**K mod P ) mod Q
S = ( K**(-1) * (hash + X*R) ) mod Q
For infromation on the SHA-1 hash function see [FIPS 180-1] and [RFC
3174].
Since Q is 160 bits long, R and S can not be larger than 20 octets,
which is the space allocated.
T is copied from the public key. It is not logically necessary in
the SIG but is present so that values of T > 8 can more conveniently
be used as an escape for extended versions of DSA or other algorithms
as later standardized.
4. Performance Considerations
General signature generation speeds are roughly the same for RSA [RFC
3110] and DSA. With sufficient pre-computation, signature generation
with DSA is faster than RSA. Key generation is also faster for DSA.
However, signature verification is an order of magnitude slower than
RSA when the RSA public exponent is chosen to be small, as is
recommended for some applications.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DSA Information in the DNS
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including DNS overhead. Larger
transfers will perform correctly and extensions have been
standardized [RFC 2671] to make larger transfers more efficient, it
is still advisable at this time to make reasonable efforts to
minimize the size of RR sets containing keying and/or signature
inforamtion consistent with adequate security.
5. Security Considerations
Keys retrieved from the DNS should not be trusted unless (1) they
have been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and
dependent on local policy.
The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
current DSA standard may limit the security of DSA. For particular
applications, implementors are encouraged to consider the range of
available algorithms and key sizes.
DSA assumes the ability to frequently generate high quality random
numbers. See [RFC 1750] for guidance. DSA is designed so that if
biased rather than random numbers are used, high bandwidth covert
channels are possible. See [Schneier] and more recent research. The
leakage of an entire DSA private key in only two DSA signatures has
been demonstrated. DSA provides security only if trusted
implementations, including trusted random number generation, are
used.
6. IANA Considerations
Allocation of meaning to values of the T parameter that are not
defined herein (i.e., > 8 ) requires an IETF standards actions. It
is intended that values unallocated herein be used to cover future
extensions of the DSS standard.
Copyright and Disclaimer
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.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DSA Information in the DNS
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.
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DSA Information in the DNS
Normative References
[FIPS 180-1] - U.S. Federal Information Processing Standard: Secure
Hash Standard, April 1995.
[FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
Signature Standard, 27 January 2000.
[RFC records] - "Resource Records for the DNS Security Extensions",
R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in
progress, draft-ietf-dnsext-dnssec-records- *.txt.
Informative References
[RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, 11/01/1987.
[RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, 11/01/1987.
[RFC 1750] - "Randomness Recommendations for Security", D. Eastlake,
S. Crocker, J. Schiller, December 1994.
[RFC intro] - "DNS Security Introduction and Requirements", R.
Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress,
draft-ietf-dnsext-dnssec-intro-*.txt.
[RFC protocol] - "Protocol Modifications for the DNS Security
Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose,
work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt.
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
1999.
[RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
(DNS)", D. Eastlake 3rd. May 2001.
[RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
Jones, September 2001.
[Schneier] - "Applied Cryptography Second Edition: protocols,
algorithms, and source code in C" (second edition), Bruce Schneier,
1996, John Wiley and Sons, ISBN 0-471-11709-9.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DSA Information in the DNS
Authors Address
Donald E. Eastlake 3rd
Motorola Labortories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-786-7554(w)
+1-508-634-2066(h)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in February 2005.
Its file name is draft-ietf-dnsext-rfc2536bis-dsa-04.txt.
D. Eastlake 3rd [Page 8]

582
doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-04.txt Normal file
View File

@@ -0,0 +1,582 @@
INTERNET-DRAFT Diffie-Hellman Information in the DNS
OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
Motorola Laboratories
Expires: February 2005 August 2004
Storage of Diffie-Hellman Keying Information in the DNS
------- -- -------------- ------ ----------- -- --- ---
<draft-ietf-dnsext-rfc2539bis-dhk-04.txt>
Status of This Document
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Distribution of this document is unlimited. Comments should be sent
to the DNS extensions 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
The standard method for encoding Diffie-Hellman keys in the Domain
Name System is specified.
Copyright
Copyright (C) The Internet Society 2004.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
Acknowledgements
Part of the format for Diffie-Hellman keys and the description
thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
and Hemma Prafullchandra. In addition, the following persons
provided useful comments that were incorporated into the predecessor
of this document: Ran Atkinson, Thomas Narten.
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Copyright..................................................1
Acknowledgements...........................................2
Table of Contents..........................................2
1. Introduction............................................3
1.1 About This Document....................................3
1.2 About Diffie-Hellman...................................3
2. Encoding Diffie-Hellman Keying Information..............4
3. Performance Considerations..............................5
4. IANA Considerations.....................................5
5. Security Considerations.................................5
Copyright and Disclaimer...................................5
Normative References.......................................7
Informative Refences.......................................7
Author Address.............................................7
Expiration and File Name...................................8
Appendix A: Well known prime/generator pairs...............9
A.1. Well-Known Group 1: A 768 bit prime..................9
A.2. Well-Known Group 2: A 1024 bit prime.................9
A.3. Well-Known Group 3: A 1536 bit prime................10
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
similar information [RFC 1034, 1035]. The DNS has been extended to
include digital signatures and cryptographic keys as described in
[RFC intro, proto, records] and additonal work is underway which
would use the storage of keying information in the DNS.
1.1 About This Document
This document describes how to store Diffie-Hellman keys in the DNS.
Familiarity with the Diffie-Hellman key exchange algorithm is assumed
[Schneier, RFC 2631].
1.2 About Diffie-Hellman
Diffie-Hellman requires two parties to interact to derive keying
information which can then be used for authentication. Thus Diffie-
Hellman is inherently a key agreement algorithm. As a result, no
format is defined for Diffie-Hellman "signature information". For
example, assume that two parties have local secrets "i" and "j".
Assume they each respectively calculate X and Y as follows:
X = g**i ( mod p )
Y = g**j ( mod p )
They exchange these quantities and then each calculates a Z as
follows:
Zi = Y**i ( mod p )
Zj = X**j ( mod p )
Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
secret between the two parties that an adversary who does not know i
or j will not be able to learn from the exchanged messages (unless
the adversary can derive i or j by performing a discrete logarithm
mod p which is hard for strong p and g).
The private key for each party is their secret i (or j). The public
key is the pair p and g, which must be the same for the parties, and
their individual X (or Y).
For further information about Diffie-Hellman and precautions to take
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
in deciding on a p and g, see [RFC 2631].
2. Encoding Diffie-Hellman Keying Information
When Diffie-Hellman keys appear within the RDATA portion of a RR,
they are encoded as shown below.
The period of key validity is not included in this data but is
indicated separately, for example by an RR which signs and
authenticates the RR containing the keying information.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEY flags | protocol | algorithm=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prime length (or flag) | prime (p) (or special) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ prime (p) (variable length) | generator length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| generator (g) (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| public value length | public value (variable length)/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ public value (g^i mod p) (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prime length is length of the Diffie-Hellman prime (p) in bytes if it
is 16 or greater. Prime contains the binary representation of the
Diffie-Hellman prime with most significant byte first (i.e., in
network order). If "prime length" field is 1 or 2, then the "prime"
field is actually an unsigned index into a table of 65,536
prime/generator pairs and the generator length SHOULD be zero. See
Appedix A for defined table entries and Section 4 for information on
allocating additional table entries. The meaning of a zero or 3
through 15 value for "prime length" is reserved.
Generator length is the length of the generator (g) in bytes.
Generator is the binary representation of generator with most
significant byte first. PublicValueLen is the Length of the Public
Value (g**i (mod p)) in bytes. PublicValue is the binary
representation of the DH public value with most significant byte
first.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
3. Performance Considerations
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including DNS overhead. Larger
transfers will perform correctly and extensions have been
standardized [RFC 2671] to make larger transfers more efficient, it
is still advisable at this time to make reasonable efforts to
minimize the size of RR sets containing keying information consistent
with adequate security.
4. IANA Considerations
Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
an IETF consensus as defined in [RFC 2434].
Well known prime/generator pairs number 0x0000 through 0x07FF can
only be assigned by an IETF standards action. [RFC 2539], the
Proposed Standard predecessor of this document, assigned 0x0001
through 0x0002. This document assigns 0x0003. Pairs number 0s0800
through 0xBFFF can be assigned based on RFC documentation. Pairs
number 0xC000 through 0xFFFF are available for private use and are
not centrally coordinated. Use of such private pairs outside of a
closed environment may result in conflicts and/or security failures.
5. Security Considerations
Keying information retrieved from the DNS should not be trusted
unless (1) it has been securely obtained from a secure resolver or
independently verified by the user and (2) this secure resolver and
secure obtainment or independent verification conform to security
policies acceptable to the user. As with all cryptographic
algorithms, evaluating the necessary strength of the key is important
and dependent on security policy.
In addition, the usual Diffie-Hellman key strength considerations
apply. (p-1)/2 should also be prime, g should be primitive mod p, p
should be "large", etc. [RFC 2631, Schneier]
Copyright and Disclaimer
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.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
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.
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
Normative References
[RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
1999.
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
in RFCs", T. Narten, H. Alvestrand, October 1998.
[RFC records] - "Resource Records for the DNS Security Extensions",
R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in
progress, draft-ietf-dnsext-dnssec-records- *.txt.
Informative Refences
[RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, November 1987.
[RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, November 1987.
[RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
1999.
[RFC intro] - "DNS Security Introduction and Requirements", R.
Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress,
draft-ietf-dnsext-dnssec-intro-*.txt.
[RFC protocol] - "Protocol Modifications for the DNS Security
Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose,
work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
and Sons.
Author Address
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-786-7554 (w)
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
+1-508-634-2066 (h)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in February 2005.
Its file name is draft-ietf-dnsext-rfc2539bis-dhk-04.txt.
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
Appendix A: Well known prime/generator pairs
These numbers are copied from the IPSEC effort where the derivation of
these values is more fully explained and additional information is available.
Richard Schroeppel performed all the mathematical and computational
work for this appendix.
A.1. Well-Known Group 1: A 768 bit prime
The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
decimal value is
155251809230070893513091813125848175563133404943451431320235
119490296623994910210725866945387659164244291000768028886422
915080371891804634263272761303128298374438082089019628850917
0691316593175367469551763119843371637221007210577919
Prime modulus: Length (32 bit words): 24, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
A.2. Well-Known Group 2: A 1024 bit prime
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its decimal value is
179769313486231590770839156793787453197860296048756011706444
423684197180216158519368947833795864925541502180565485980503
646440548199239100050792877003355816639229553136239076508735
759914822574862575007425302077447712589550957937778424442426
617334727629299387668709205606050270810842907692932019128194
467627007
Prime modulus: Length (32 bit words): 32, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
A.3. Well-Known Group 3: A 1536 bit prime
The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
Its decimal value is
241031242692103258855207602219756607485695054850245994265411
694195810883168261222889009385826134161467322714147790401219
650364895705058263194273070680500922306273474534107340669624
601458936165977404102716924945320037872943417032584377865919
814376319377685986952408894019557734611984354530154704374720
774996976375008430892633929555996888245787241299381012913029
459299994792636526405928464720973038494721168143446471443848
8520940127459844288859336526896320919633919
Prime modulus Length (32 bit words): 48, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
D. Eastlake 3rd [Page 10]

755
doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt Normal file
View File

@@ -0,0 +1,755 @@
Network Working Group B. Laurie
Internet-Draft Nominet
Expires: March 2, 2005 R. Loomis
SAIC
September 2004
Requirements related to DNSSEC Signed Proof of Non-Existence
draft-ietf-dnsext-signed-nonexistence-requirements-01
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 March 2, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
DNSSEC-bis uses the NSEC record to provide authenticated denial of
existence of RRsets. NSEC also has the side-effect of permitting
zone enumeration, even if zone transfers have been forbidden.
Because some see this as a problem, this document has been assembled
to detail the possible requirements for denial of existence A/K/A
signed proof of non-existence.
Laurie & Loomis Expires March 2, 2005 [Page 1]
Internet-Draft signed-nonexistence-requirements September 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3
4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4
5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4
6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4
7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5
9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5
10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6
11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6
12. Non-overlap of denial records with possible zone records . . 7
13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7
14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8
15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8
16. Minimisation of Client Complexity . . . . . . . . . . . . . 8
17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8
18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8
19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8
20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8
21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9
22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9
23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9
24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9
25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9
26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9
27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
28. Requirements notation . . . . . . . . . . . . . . . . . . . 9
29. Security Considerations . . . . . . . . . . . . . . . . . . 10
30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
30.1 Normative References . . . . . . . . . . . . . . . . . . . 10
30.2 Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . 11
Laurie & Loomis Expires March 2, 2005 [Page 2]
Internet-Draft signed-nonexistence-requirements September 2004
1. Introduction
NSEC records allow trivial enumeration of zones - a situation that
has existed for several years but which has recently been raised as a
significant concern for DNSSECbis deployment in several zones.
Alternate proposals have been made that make zone enumeration more
difficult, and some previous proposals to modify DNSSEC had related
requirements/desirements that are relevant to the discussion. In
addition the original designs for NSEC/NXT records were based on
working group discussions and the choices made were not always
documented with context and requirements-- so some of those choices
may need to be restated as requirements. Overall, the working group
needs to better understand the requirements for denial of existence
(and certain other requirements related to DNSSECbis deployment) in
order to evaluate the proposals that may replace NSEC.
In the remainder of this document, "NSEC++" is used as shorthand for
"a denial of existence proof that will replace NSEC". "NSECbis" has
also been used as shorthand for this, but we avoid that usage since
NSECbis will not be part of DNSSECbis and therefore there might be
some confusion.
2. Non-purposes
This document does not currently document the reasons why zone
enumeration might be "bad" from a privacy, security, business, or
other perspective--except insofar as those reasons result in
requirements. Once the list of requirements is complete and vaguely
coherent, the trade-offs (reducing zone enumeration will have X cost,
while providing Y benefit) may be revisited. The editors of this
compendium received inputs on the potential reasons why zone
enumeration is bad (and there was significant discussion on the
DNSEXT WG mailing list) but that information fell outside the scope
of this document.
Note also that this document does not assume that NSEC *must* be
replaced with NSEC++, if the requirements can be met through other
methods (e.g., "white lies" with the current NSEC). As is stated
above, this document is focused on requirements collection and
(ideally) prioritization rather than on the actual implementation.
3. Zone Enumeration
Authenticated denial should not permit trivial zone enumeration.
Additional discussion: NSEC (and NXT before it) provide a linked
list that could be "walked" to trivially enumerate all the signed
records in a zone. This requirement is primarily (though not
Laurie & Loomis Expires March 2, 2005 [Page 3]
Internet-Draft signed-nonexistence-requirements September 2004
exclusively) important for zones that either are delegation-only/
-mostly or do not have reverse lookup (PTR) records configured, since
enterprises that have PTR records for all A records have already
provided a similar capability to enumerate the contents of DNS zones.
Contributor: various
4. Zone Enumeration II
Zone enumeration should be at least as difficult as it would be to
effect a dictionary attack using simple DNS queries to do the same in
an unsecured zone.
(Editor comment: it is not clear how to measure difficulty in this
case. Some examples could be monetary cost, bandwidth, processing
power or some combination of these. It has also been suggested that
the requirement is that the graph of difficulty of enumeration vs.
the fraction of the zone enumerated should be approximately the same
shape in the two cases)
Contributor: Nominet
5. Zone Enumeration III
Enumeration of a zone with random contents should computationally
infeasible.
Editor comment: this is proposed as a way of evaluating the
effectiveness of a proposal rather than as a requirement anyone would
actually have in practice.
Contributor: Alex Bligh
6. Exposure of Contents
NSEC++ should not expose any of the contents of the zone (apart from
the NSEC++ records themselves, of course).
Editor comment: this is a weaker requirement than prevention of
enumeration, but certainly any zone that satisfied this requirement
would also satisfy the trivial prevention of enumeration requirement.
Contributor: Ed Lewis
7. Zone Size
Requirement: NSEC++ should make it possible to take precautions
against trivial zone size estimates. Since not all zone owners care
Laurie & Loomis Expires March 2, 2005 [Page 4]
Internet-Draft signed-nonexistence-requirements September 2004
about others estimation of the size of a zone, it is not always
necessary to prohibit trivial estimation of the size of the zone but
NSEC++ should allow such measures.
Additional Discussion: Even with proposals based on obfuscating names
with hashes it is trivial to give very good estimates of the number
of domains in a certain zone. Just send 10 random queries and look
at the range between the two hash values returned in each NSEC++. As
hash output can be assumed to follow a rectangular random
distribution, using the mean difference between the two values, you
can estimate the total number of records. It is probably sufficient
to look at even one NSEC++, since the two hash values should follow a
(I believe) Poisson distribution.
The concern is motivated by some wording remembered from NSEC, which
stated that NSEC MUST only be present for existing owner names in the
zone, and MUST NOT be present for non-existing owner names. If
similar wording were carried over to NSEC++, introducing bogus owner
names in the hash chain (an otherwise simple solution to guard
against trivial estimates of zone size) wouldn't be allowed.
One simple attempt at solving this is to describe in the
specifications how zone signer tools can add a number of random
"junk" records.
Editor's comment: it is interesting that obfuscating names might
actually make it easier to estimate zone size.
Contributor: Simon Josefsson.
8. Single Method
Requirement: A single NSEC++ method must be able to carry both
old-style denial (i.e. plain labels) and whatever the new style
looks like. Having two separate denial methods could result in
cornercases where one method can deny the other and vice versa.
Additional discussion: This requirement can help -bis folks to a
smooth upgrade to -ter. First they'd change the method while the
content is the same, then they can change content of the method.
Contributor: Roy Arends.
9. Empty Non-terminals
Requirement: Empty-non-terminals (ENT) should remain empty. In
other words, adding NSEC++ records to an existing DNS structure
should not cause the creation of NSEC++ records (or related records)
Laurie & Loomis Expires March 2, 2005 [Page 5]
Internet-Draft signed-nonexistence-requirements September 2004
at points that are otherwise ENT.
Additional discussion: Currently NSEC complies with ENT requirement:
b.example.com NSEC a.c.example.com implies the existence of an ENT
with ownername c.example.com. NSEC2 breaks that requirement, since
the ownername is entirely hashed causing the structure to disappear.
This is why EXIST was introduced. But EXIST causes ENT to be
non-empty-terminals. Next to the dissappearance of ENT, it causes
(some) overhead since an EXIST record needs a SIG, NSEC2 and
SIG(NSEC2). DNSNR honours this requirement by hashing individual
labels instead of ownernames. However this causes very long labels.
Truncation is a measure against very long ownernames, but that is
controversial. There is a fair discussion of the validity of
truncation in the DNSNR draft, but that hasn't got proper review yet.
Contributor: Roy Arends.
(Editor comment: it is not clear to us that an EXIST record needs an
NSEC2 record, since it is a special purpose record only used for
denial of existence)
10. Prevention of Precomputed Dictionary Attacks
Requirement: NSEC++ needs to provide a method to reduce the
effectiveness of precomputed dictionary attacks.
Additional Discussion: Salt is a measure against dictionary attacks.
There are other possible measures (such as iterating hashes in
NSEC2). The salt needs to be communicated in every response, since
it is needed in every verification. Some have suggested to move the
salt to a special record instead of the denial record. I think this
is not wise. Response size has more priority over zone size. An
extra record causes a larger response than a larger existing record.
Contributor: Roy Arends.
(Editor comment: the current version of NSEC2 also has the salt in
every NSEC2 record)
11. DNSSEC-Adoption and Zone-Growth Relationship
Background: Currently with NSEC, when a delegation centric zone
deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
when the DNSSEC-adoption rate of the subzones remains low--because
each delegation point creates at least one NSEC record and
corresponding signature in the parent even if the child is not
signed.
Laurie & Loomis Expires March 2, 2005 [Page 6]
Internet-Draft signed-nonexistence-requirements September 2004
Requirements: A delegation-only (or delegation-mostly) zone that is
signed but which has no signed child zones should initially need only
to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
minimal set of NSEC++ records to cover zone contents. Further,
during the transition of a delegation-only zone from 0% signed
children to 100% signed children, the growth in the delegation-only
zone should be roughly proportional to the percentage of signed child
zones.
Additional Discussion: This is why DNSNR has the Authoritative Only
bit. This is similar to opt-in for delegations only. This (bit) is
currently the only method to help delegation-centric zone cope with
zone-growth due to DNSSEC adoption. As an example, A delegation only
zone which deploys DNSSEC with the help of this bit, needs to add
SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No
more than that.
Contributor: Roy Arends.
12. Non-overlap of denial records with possible zone records
Requirement: NSEC++ records should in some way be differentiated
from regular zone records, so that there is no possibility that a
record in the zone could be duplicated by a non-existence proof
(NSEC++) record.
Additional discussion: This requirement is derived from a discussion
on the DNSEXT mailing list related to copyrights and domain names.
As was outlined there, one solution is to put NSEC++ records in a
separate namespace, e.g.: $ORIGIN co.uk.
873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
; for amazon.co.uk.
Contributor: various
(Editor comment: One of us still does not see why a conflict
matters. Even if there is an apparent conflict or overlap, the
"conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
other name _never_ appears in NSEC2 records.)
13. Exposure of Private Keys
Private keys associated with the public keys in the DNS should be
exposed as little as possible. It is highly undesirable for private
keys to be distributed to nameservers, or to otherwise be available
in the run-time environment of nameservers.
Laurie & Loomis Expires March 2, 2005 [Page 7]
Internet-Draft signed-nonexistence-requirements September 2004
Contributors: Nominet, Olaf Kolkman, Ed Lewis
14. Minimisation of Zone Signing Cost
The additional cost of creating an NSEC++ signed zone should not
significantly exceed the cost of creating an ordinary signed zone.
Contributor: Nominet
15. Minimisation of Asymmetry
Nameservers should have to do as little additional work as necessary.
More precisely, it is desirable for any increase in cost incurred by
the nameservers to be offset by a proportionate increase in cost to
DNS `clients', e.g. stub and/or `full-service' resolvers.
Contributor: Nominet
16. Minimisation of Client Complexity
Caching, wildcards, CNAMEs, DNAMEs should continue to work without
adding too much complexity at the client side.
Contributor: Olaf Kolkman
17. Completeness
A proof of nonexistence should be possible for all nonexistent data
in the zone.
Contributor: Olaf Kolkman
18. Purity of Namespace
The name space should not be muddied with fake names or data sets.
Contributor: Ed Lewis
19. Replay Attacks
NSEC++ should not allow a replay to be used to deny existence of an
RR that actually exists.
Contributor: Ed Lewis
20. Compatibility with NSEC
NSEC++ should not introduce changes incompatible with NSEC.
Laurie & Loomis Expires March 2, 2005 [Page 8]
Internet-Draft signed-nonexistence-requirements September 2004
Contributor: Ed Lewis
21. Compatibility with NSEC II
NSEC++ should differ from NSEC in a way that is transparent to the
resolver or validator.
Contributor: Ed Lewis
22. Compatibility with NSEC III
NSEC++ should differ from NSEC as little as possible whilst achieving
other requirements.
Contributor: Alex Bligh
23. Coexistence with NSEC
NSEC++ should be optional, allowing NSEC to be used instead.
Contributor: Ed Lewis, Alex Bligh
24. Coexistence with NSEC II
NSEC++ should not impose extra work on those content with NSEC.
Contributor: Ed Lewis
25. Protocol Design
A good security protocol would allow signing the nonexistence of some
selected names without revealing anything about other names.
Contributor: Dan Bernstein
26. Process
Clearly not all of these requirements can be met. Therefore the next
phase of this document will be to either prioritise them or narrow
them down to a non-contradictory set, which should then allow us to
judge proposals on the basis of their fit.
27. Acknowledgements
28. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Laurie & Loomis Expires March 2, 2005 [Page 9]
Internet-Draft signed-nonexistence-requirements September 2004
document are to be interpreted as described in [RFC2119].
29. Security Considerations
There are currently no security considerations called out in this
draft. There will be security considerations in the choice of which
requirements will be implemented, but there are no specific security
requirements during the requirements collection process.
30. References
30.1 Normative References
[dnssecbis-protocol]
"DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
Month 2004.
30.2 Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
Authors' Addresses
Ben Laurie
Nominet
17 Perryn Road
London W3 7LR
England
Phone: +44 (20) 8735 0686
EMail: ben@algroup.co.uk
Rip Loomis
Science Applications International Corporation
7125 Columbia Gateway Drive, Suite 300
Columbia, MD 21046
US
EMail: gilbert.r.loomis@saic.com
Laurie & Loomis Expires March 2, 2005 [Page 10]
Internet-Draft signed-nonexistence-requirements September 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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Laurie & Loomis Expires March 2, 2005 [Page 11]

313
doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt → doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
View File

@@ -3,51 +3,106 @@
DNSEXT Working Group Yuji Kamite
INTERNET-DRAFT NTT Communications
<draft-ietf-dnsext-tkey-renewal-mode-04.txt> Masaya Nakayama
Expires: Aug. 2004 The University of Tokyo
Feb. 2004
DNS Extensions Yuji Kamite
Internet-Draft NTT Communications
Expires: April 15, 2005 Masaya Nakayama
The University of Tokyo
October 14, 2004
TKEY Secret Key Renewal Mode
draft-ietf-dnsext-tkey-renewal-mode-05
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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 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.''
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 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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document defines a new mode in TKEY and proposes an atomic
method for changing secret keys used for TSIG periodically.
Originally, TKEY provides methods of setting up shared secrets other
Kamite, et. al. Expires April 15, 2005 [Page 1]
INTERNET-DRAFT October 2004
than manual exchange, but it cannot control timing of key renewal
very well though it can add or delete shared keys separately. This
proposal is a systematical key renewal procedure intended for
preventing signing DNS messages with old and non-safe keys
permanently.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3
1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4
1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4
2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5
2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5
2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6
2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7
2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7
2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7
2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8
2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8
2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10
2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10
2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11
2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12
2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13
2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14
3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15
4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15
4.2 Authentication Methods Considerations . . . . . . . . . . 15
5. Special Considerations for Two Servers' Case . . . . . . . . 16
5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16
6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17
7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1 Normative References . . . . . . . . . . . . . . . . . . . 21
11.2 Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23
@@ -55,65 +110,9 @@ Abstract
Kamite, et. al. [Page 1]
Kamite, et. al. Expires April 15, 2005 [Page 2]
INTERNET-DRAFT Feb. 2004
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4
1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4
2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5
2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5
2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6
2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 7
2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . . . 7
2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . . 7
2.3.3 Attributes of Generated Key . . . . . . . . . . . . . . . 8
2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . . . 8
2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 10
2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10
2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11
2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12
2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13
2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14
3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Compulsory Key Revocation . . . . . . . . . . . . . . . . . . . . 15
4.1 Compulsory Key Revocation by Server . . . . . . . . . . . . . 15
4.2 Authentication Methods Considerations . . . . . . . . . . . . 15
5 Special Considerations for Two Servers' Case . . . . . . . . . . 16
5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16
6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 17
7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17
8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 20
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20
10 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 21
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22
Kamite, et. al. [Page 2]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
1. Introduction
@@ -167,9 +166,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 3]
Kamite, et. al. Expires April 15, 2005 [Page 3]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
and must be updated. It must be between Inception Time and Expiry
@@ -223,9 +222,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 4]
Kamite, et. al. Expires April 15, 2005 [Page 4]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
In this state, if a client sends a normal query (e.g., question about
@@ -279,9 +278,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 5]
Kamite, et. al. Expires April 15, 2005 [Page 5]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
When the present time is equal to Inception Time, or between
@@ -335,9 +334,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 6]
Kamite, et. al. Expires April 15, 2005 [Page 6]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
Server MUST keep track of clients ignoring PartialRevoke, thus
@@ -391,9 +390,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 7]
Kamite, et. al. Expires April 15, 2005 [Page 7]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
client, a new shared secret can be established. The details of
@@ -447,9 +446,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 8]
Kamite, et. al. Expires April 15, 2005 [Page 8]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
CLASS u_int16_t (defined in [RFC2930])
@@ -494,18 +493,18 @@ INTERNET-DRAFT Feb. 2004
in Other Data filed:
Field Type Comment
------- ------ -------
OldNAME domain name of the old key
OldAlgorithm domain algorithm of the old key
Field Type Comment
------- ------ -------
OldNAME domain name of the old key
OldAlgorithm domain algorithm of the old key
Kamite, et. al. [Page 9]
Kamite, et. al. Expires April 15, 2005 [Page 9]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
"OldName" indicates the name of the previous key (usually,
@@ -559,9 +558,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 10]
Kamite, et. al. Expires April 15, 2005 [Page 10]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
including "OldName" and "OldAlgorithm" that indicate the revoked key.
@@ -615,9 +614,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 11]
Kamite, et. al. Expires April 15, 2005 [Page 11]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
TKEY "Mode" field stores the value of "DH exchange for key
@@ -671,9 +670,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 12]
Kamite, et. al. Expires April 15, 2005 [Page 12]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
Query
@@ -727,9 +726,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 13]
Kamite, et. al. Expires April 15, 2005 [Page 13]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
Query
@@ -783,9 +782,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 14]
Kamite, et. al. Expires April 15, 2005 [Page 14]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
client or not. If client has not received yet because of any reasons
@@ -839,9 +838,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 15]
Kamite, et. al. Expires April 15, 2005 [Page 15]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
shared secret, they keep using TSIG for queries and responses.
@@ -895,9 +894,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 16]
Kamite, et. al. Expires April 15, 2005 [Page 16]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
hosts want to send queries, but it is possible.
@@ -951,9 +950,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 17]
Kamite, et. al. Expires April 15, 2005 [Page 17]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
(3) Suppose the present time is 19:55. If Client sends a query
@@ -1007,9 +1006,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 18]
Kamite, et. al. Expires April 15, 2005 [Page 18]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
Answer Section also contains KEY RRs for DH.
@@ -1063,9 +1062,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 19]
Kamite, et. al. Expires April 15, 2005 [Page 19]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
(11) This key is used until next day's 15:00. After that, it will
@@ -1119,12 +1118,12 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 20]
Kamite, et. al. Expires April 15, 2005 [Page 20]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
10. Acknowledgement
10. Acknowledgements
The authors would like to thank Olafur Gudmundsson, whose helpful
input and comments contributed greatly to this document.
@@ -1132,9 +1131,7 @@ INTERNET-DRAFT Feb. 2004
11. References
[RFC2104]
H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
Authentication", RFC2104, February 1997.
11.1. Normative References
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
@@ -1157,6 +1154,11 @@ INTERNET-DRAFT Feb. 2004
D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
)", RFC 2931, September 2000.
11.2. Informative References
[RFC2104]
H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
Authentication", RFC2104, February 1997.
@@ -1172,12 +1174,9 @@ INTERNET-DRAFT Feb. 2004
Kamite, et. al. [Page 21]
Kamite, et. al. Expires April 15, 2005 [Page 21]
INTERNET-DRAFT Feb. 2004
INTERNET-DRAFT October 2004
Authors' Addresses
@@ -1231,5 +1230,63 @@ Authors' Addresses
Kamite, et. al. [Page 22]
Kamite, et. al. Expires April 15, 2005 [Page 22]
INTERNET-DRAFT 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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kamite, et. al. Expires April 15, 2005 [Page 23]

1501
doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1010
doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt
View File

File diff suppressed because it is too large Load Diff

818
doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt Normal file
View File

@@ -0,0 +1,818 @@
DNSEXT Working Group E. Lewis
INTERNET DRAFT NeuStar
Expiration Date: April 2005 October 2004
Clarifying the Role of Wild Card Domains
in the Domain Name System
draft-ietf-dnsext-wcard-clarify-03.txt
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 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 11, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The definition of wild cards is recast from the original in RFC 1034,
in words that are more specific and in line with RFC 2119. This
document is meant to supplement the definition in RFC 1034 and not to
significantly alter the spirit or intent of that definition.
1 Introduction
In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the synthesis
of answers from special records called wildcards. The original
definitions are incomplete. This document clarifies and describes
the wildcard synthesis by adding to the discussion and making
limited modifications. Modifications are made only where necessary
to close inconsistencies that have led to interoperability issues.
1.1 Motivation
Over time many implementations have diverged in different ways from
the original definition, or at least what had been intended. Although
there is clearly a need to clarify the original documents in light
of this, the impetus for this document lay in the engineering of
the DNS security extensions [RFC TBD]. With an unclear definition
of wildcards the design of authenticated denial became entangled.
Although this document is motivated by DNSSEC and the need to
have a separate document passed for the sake of DNSSEC, other
motivations have risen. The renewed understanding of wildcards gained
is worthy of being documented.
1.2 The Original Definition
This document is intended to not make changes. To reinforce
this, sections of RFC 1034 are repeated verbatim for convenience
of the reader, to help in comparison of old and new text.
There are a few passages which are changed. This may seem to
contradict the goal of not changing the original specification,
but the changes herein are required because of inconsistencies
with the wording in RFC 1034.
The beginning of the discussion ought to start with the definition
of the term "wildcard" as it appears in RFC 1034, section 4.3.3.
# In the previous algorithm, special treatment was given to RRs with owner
# names starting with the label "*". Such RRs are called wildcards.
# Wildcard RRs can be thought of as instructions for synthesizing RRs.
# When the appropriate conditions are met, the name server creates RRs
# with an owner name equal to the query name and contents taken from the
# wildcard RRs.
This passage appears after the algorithm in which they are used is
presented. The terminology is not consistent, the word "wildcard"
is clearly defined to be a resource record. In the next sentence
the term is shifted to be an adjective, the first step on the
path to overloading the term. Wildcard has also been used to
refer to domain names that begin with a "*".
1.3 The Clarification
The clarification effort can be divided into three sections. One
is the use of new terminology to better describe wildcards. Changes
to words in RFC 1034 that have resulted by discovering conflicting
concepts are presented. Descriptions of special type records in the
context of being wildcards is discussed.
1.3.1 New Terms
The term "wildcard" has become so overloaded it is virtually useless
as a description. A few new terms will be introduced to be more
descriptive. The new terms that will be introduced are:
Asterisk Label - a label consisting of an asterisk ("*") and no
other characters.
Wild Card Domain Name - a domain name whose least significant
label (first when reading left to right) is an asterisk label.
Other labels might also be asterisk labels.
Source of Synthesis - a Wild Card Domain Name when it is consulted in
the final paragraph of step 3, part c of RFC 1034's 4.3.2 algorithm.
Closest Encloser - in RFC 1034's 4.3.2 algorithm, the name at which
the last match was possible in step 3, part c. This is the longest
sequence of exactly matching labels from the root downward in both the
sought name (QNAME) and in the zone being examined.
Label Match - two labels are equivalent if the label type and label
length are the same bit sequence and if the name is the label is
equivalent bit wise after down casing all of the ASCII characters.
[Ed note: do we still call them ASCII?]
These terms will be more fully described as needed later. These
terms will be used to describe a few changes to the words in RFC
1034. A summary of the changes appear next and will be fully
covered in later sections.
1.3.2 Changed Text
The definition of "existence" is changed, superficially, to exclude
empty domains that have no subdomains with resource records. This
change will not be apparent to implementations, it is needed to
make descriptions more concise.
In RFC 1034, there is text that seems to bar having two Asterisk
Labels in a Wild Card Domain Name. There is no further discussion,
no prescribed error handling, nor enforcement described. In this
document, the use of such names will be discouraged, but implementations
will have to account for the possibility of such a name's use.
The actions when a Source of Synthesis owns a CNAME RR are changed to
mirror the actions if an exact match name owns a CNAME RR. This
is an addition to the words in RFC 1034, section 4.3.2, step 3,
part c.
1.3.3 Considerations with Special Types
This clarification will describe in some detail the semantics of
wildcard CNAME RRs, wildcard NS RRs, wildcard SOA RR's,
wildcard DNAME RRs [RFC wxyz], and empty, non-terminal wildcards.
Understanding these types in the context of wildcards has been
clouded because these types incur special processing if they
are the result of an exact match.
By the definition in RFC 1034, there can be no empty, non-terminal
"wildcards", but in the algorithm, it is possible that an empty
non-terminal is sought as the potential owner of a "wildcard." This
is one example of why the ordering of the discussion in RFC 1034 is
confusing.
1.4 Standards 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 the document entitled
"Key words for use in RFCs to Indicate Requirement Levels." [RFC2119]
Quotations of RFC 1034 (as has already been done once above) are
denoted by a '#' in the leftmost column.
2 "Wildcard"
The context of the wildcard concept involves the algorithm by which
a name server prepares a response (in RFC 1034's section 4.3.2) and
the way in which a resource record (set) is identified as being a
source of synthetic data (section 4.3.3).
Tackling the latter first, there are two objectives in defining a
means to identify a resource record set as a source of synthesis.
First is the desire to maintain all DNS data in a consistent manner.
Avoiding the need for implementations to have many internal data
structures is a good thing. Not that this means limiting quantity,
but rather types of data. The second objective impacts interoperability,
that is a master server of one implementation has to be able to
send the synthesis instructions to the slaves. Although there are
alternatives to the use of zone transfers via port 53, a truly
interoperable record synthesis approach has to be able to insert the
synthesis instructions into a zone transfer.
The objectives in describing the synthesis of records in the context
of the name server algorithm include knowing when to employ the
process of synthesis and how the synthesis is carried out.
2.1 Identifying a wildcard
To provide a more accurate description of "wildcards", the definition
has to start with a discussion of the domain names that appear as
owners.
2.1.1 Wild Card Domain Name and Asterisk Label
A "Wild Card Domain Name" is defined by having its initial label be:
0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
The first octet is the normal label type and length for a 1 octet
long label, the second octet is the ASCII representation [RFC 20] for
the '*' character. In RFC 1034, ASCII encoding is assumed to be the
character encoding.
A descriptive name of a label equaling that value is an "Asterisk
Label."
RFC 1034's definition of wildcard would be "a resource record owned
by a Wild Card Domain Name." This is mentioned to help maintain some
orientation between this clarification and RFC 1034. Keep in mind,
that in "Clarifications to the DNS Specification" [RFC 2181] the name
of the basic unit of DNS data became the resource record set (RRSet) and
not the resource record.
2.1.2 Variations on Wild Card Domain Names
RFC 1034 and RFC 1035 do not explicitly mention the case in which a
domain name might be something like "the*.example.com." The
interpretation is that this domain name in a zone would only match
queries for "the*.example.com" and not have any other role. An
asterisk ('*') occurring other than as the sole character in
a label is simply a character forming part of the label and has no
special meaning. This is not an Asterisk Label, simply a label
an asterisk in it. The same is true for "**.example.com." and
"*the.example.com."
[Ed note: the above paragraph reads too strong. The intent ought to
be that such names do not fall under the rules of wildcards. The
intent is not to bar any future attempts to define other forms of
synthesis - nor is the intent to encourage them.]
The interpretation of a wild card domain specification which is not a
leaf domain is not clearly defined in RFC 1034. E.g., sub.*.example.,
is not discussed, not barred. In wanting to minimize changes from
the original specification, such names are permitted. Although
"sub.*.example." is not a Wild Card Domain Name, "*.example." is.
RRSets used to synthesize records can be owned by a Wild Card Domain
Name that has subdomains.
2.1.3 Non-terminal Wild Card Domain Names
In section 4.3.3, the following is stated:
# .......................... The owner name of the wildcard RRs is of
# the form "*.<anydomain>", where <anydomain> is any domain name.
# <anydomain> should not contain other * labels......................
This covers names like "*.foo.*.example." The pre-RFC2119 wording uses
"should not" which has an ambiguous meaning. The specification does not
proscribe actions upon seeing such a name, such as whether or not a
zone containing the name should fail to be served. What if a dynamic
update (RFC2136) requested to add the name to the zone? The failure
semantics are not defined.
The recommendation is that implementations ought to anticipate the
appearance of such names but generally discourage their use in
operations. No standards statement, such as "MAY NOT" or "SHOULD NOT"
is made here.
The interpretation of this is, when seeking a Wild Card Domain Name
for the purposes of record synthesis, an implementation ought not to
check the domain name for subdomains.
It is possible that a Wild Card Domain Name is an empty non-terminal.
(See the upcoming sections on empty non-terminals.) In this case,
the lookup will terminate as would any empty non-terminal match.
2.2 Existence Rules
The notion that a domain name 'exists' arises numerous times in
discussions about the wildcard concept. RFC 1034 raises the issue
of existence in a number of places, usually in reference to
non-existence and in reference to processing involving wildcards.
RFC 1034 contains algorithms that describe how domain names impact
the preparation of an answer and does define wildcards as a means of
synthesizing answers. Because of this a discussion on wildcards
needs to cover a definition of existence.
To help clarify the topic of wild cards, a positive definition of
existence is needed. Complicating matters, though, is the
realization that existence is relative. To an authoritative server,
a domain name exists if the domain name plays a role following the
algorithms of preparing a response. To a resolver, a domain name
exists if there is any data available corresponding to the name. The
difference between the two is the synthesis of records according to a
wildcard.
For the purposes of this document, the point of view of an
authoritative server is more interesting. A domain name is said to
exist if it plays a role in the execution of the algorithms in RFC 1034.
2.2.1. An Example
To illustrate what is meant by existence consider this complete zone:
$ORIGIN example.
example. 3600 IN SOA <SOA RDATA>
example. 3600 NS ns.example.com.
example. 3600 NS ns.example.net.
*.example. 3600 TXT "this is a wild card"
*.example. 3600 MX 10 host1.example.
host1.example. 3600 A 192.0.4.1
_ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
_ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
subdel.example. 3600 NS ns.example.com.
subdel.example. 3600 NS ns.example.net.
A look at the domain names in a tree structure is helpful:
|
-------------example------------
/ / \ \
/ / \ \
/ / \ \
* host1 host2 subdel
| |
| |
_tcp _tcp
| |
| |
_ssh _ssh
The following queries would be synthesized from the wild card:
QNAME=host3.example. QTYPE=MX, QCLASS=IN
the answer will be a "host3.example. IN MX ..."
QNAME=host3.example. QTYPE=A, QCLASS=IN
the answer will reflect "no error, but no data"
because there is no A RR set at '*.example.'
QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
the answer will be "foo.bar.example. IN TXT ..."
because bar.example. does not exist, but the wildcard does.
The following queries would not be synthesized from the wild card:
QNAME=host1.example., QTYPE=MX, QCLASS=IN
because host1.example. exists
QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
because *.example. exists
QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
because _tcp.host1.example. exists (without data)
QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN
because host2.example. exists (without data)
QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
because subdel.example. exists (and is a zone cut)
To the server, all of the domains in the tree exist. The resolver will
get answers to some names off the tree, thanks to synthesis.
2.2.2 Empty Non-terminals
Empty non-terminals are domain names that own no resource records but
have subdomains which do. This is defined in section 3.1 of RFC 1034:
# The domain name space is a tree structure. Each node and leaf on the
# tree corresponds to a resource set (which may be empty). The domain
# system makes no distinctions between the uses of the interior nodes and
# leaves, and this memo uses the term "node" to refer to both.
The parenthesized "which may be empty" specifies that empty non-
terminals are explicitly recognized. According to the definition of
existence in this document, empty non-terminals do exist at the
server.
Pedantically reading the above paragraph can lead to an
interpretation that all possible domains exist - up to the suggested
limit of 255 octets for a domain name [RFC 1035]. For example,
www.example. may have an A RR, and as far as is practically
concerned, is a leaf of the domain tree. But the definition can be
taken to mean that sub.www.example. also exists, albeit with no data.
By extension, all possible domains exist, from the root on down. As
RFC 1034 also defines "an authoritative name error indicating that
the name does not exist" in section 4.3.1, this is not the intent of
the original document.
2.2.3 Yet Another Definition of Existence
RFC1034's wording is clarified by the following paragraph:
A node is considered to have an impact on the algorithms of
4.3.2 if it is a leaf node with any resource sets or an interior
node (with or without a resource set) that has a subdomain that
is a leaf node with a resource set. A QNAME and QCLASS matching
an existing node never results in a response code of
authoritative name error (RCODE==3).
The terminology in the above paragraph is chosen to remain as close
to that in the original document. The term "with" is a alternate
form for "owning" in this case, hence "a leaf node owning resources
sets, or an interior node, owning or not owning any resource set,
that has a leaf node owning a resource set as a subdomain," is the
proper interpretation of the middle sentence.
As an aside, an "authoritative name error", response code (RCODE) 3,
has been called NXDOMAIN in some RFCs, such as RFC 2136 [RFC 2136].
NXDOMAIN is the mnemonic assigned to such an error by at least one
implementation of DNS.
Summarizing the discussion on existence in non-RFC1034 words:
An authoritative server is to treat a domain name as existing
during the execution of the algorithms in RFC 1034 when the
domain name conforms to the following definition. A domain name
is defined to exist if the domain name owns data or has a
subdomain that exists, or both.
Note that at a zone boundary, the domain name owns data, including
the NS RR set. At the delegating server, the NS RR set is not
authoritative, but that is of no consequence here. The domain name
owns data, therefore, it exists.
2.3 When does a Wild Card Domain Name not own a wildcard (record)
When a Wild Card Domain Name appears in a message's query section,
no special processing occurs. Asterisk Labels in such a context
only Label Matches other Asterisk Labels in the existing zone tree
when the 4.3.2 algorithm is being followed.
When a Wild Card Domain Name appears in the resource data of a
record, no special processing occurs. An Asterisk Label in that
context literally means just an asterisk.
3. Impact of a Wild Card Domain On a Response
The description of how wild cards impact response generation is in
RFC 1034, section 4.3.2. That passage contains the algorithm
followed by a server in constructing a response. Within that
algorithm, step 3, part 'c' defines the behavior of the wild card.
The algorithm is directly quoted in lines that begin with a '#' sign.
Commentary is interleaved.
There is a documentation issue deserving some explanation. The
algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo
code, i.e., it's steps are not intended to be followed in strict
order. The "algorithm" is a suggestion. As such, in step 3, parts
a, b, and c, do not have to be implemented in that order.
Another issue needing explanation is that RFC 1034 is a full
standard. There is another RFC, RFC 2672, which makes, or proposes
an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME
RR. RFC 2672 is a proposed standard. The dilemma in writing these
clarifications is knowing which document is the one being clarified.
Fortunately, the difference between RFC 1034 and RFC 2672 is not
significant with respect to wild card synthesis, so this document
will continue to state that it is clarifying RFC 1034. If RFC 2672
progresses along the standards track, it will need to refer to
modifying RFC 1034's algorithm as amended here.
3.1 Step 2
Step 2 of the RFC 1034's section 4.3.2 reads:
# 2. Search the available zones for the zone which is the nearest
# ancestor to QNAME. If such a zone is found, go to step 3,
# otherwise step 4.
In this step, the most appropriate zone for the response is chosen.
There are two reasons to repeat this. One is that this means all
of step 3 is done within the context of a zone, which will constrain
the discussion. The other is the though behind synthesizing entire
zones and the use of Wild Card Domain Names to do so.
3.2 Step 3
Step 3 is dominated by three parts, labelled a, b, and c. But the
beginning of the Step is important and needs explanation.
# 3. Start matching down, label by label, in the zone. The
# matching process can terminate several ways:
The word matching in this care refers to Label Matching. The concept
is based in the view of the zone as the tree of existing names. The
Query Name is considered to be an ordered sequence of labels - as
if the name were a path from the root to the owner of the desired
data.
The process of Label Matching ends in one of three choices, the parts
a, b, and c. Once one of the parts is chosen, the other parts are
not considered. (E.g., do not execute part c and then change the
execution path to finish in part b.) The process of Label Matching
is also done independent of the Query Type.
Parts a and b are not an issue for this clarification as they do not
relate to record synthesis. Part a generally covers a situation in
which all of the labels in the search (query) name have been matched
down the tree, e.g., the sought name exists as an exact Label Match.
Part b generally covers a situation in which any label in the sought
name Label Matches a tree label and the tree label has a NS RRSet.
3.3 Part 'c'
The context of part 'c' is that the process of Label Matching the
labels in the sought name has resulted in a situation in which there
is nothing corresponding in the tree. It is as if the lookup has
"fallen off the tree."
# c. If at some label, a match is impossible (i.e., the
# corresponding label does not exist), look to see if a
# the "*" label exists.
To help describe the process of looking "to see is a the [sic]
label exists" a term has been coined to describe the last label
matched. The term is "Closest Encloser."
3.3.1 Closest Encloser and the Source of Synthesis
The "Closest Encloser" is the node in the zone's tree of existing
domain names that is has the most matching labels with the sought
name. Each match is a "Label Match" and the order of the labels
is also the same. The Closest Encloser is an existing name in the
zone, it may be an empty non-terminal, it may even be a Wild Card
Domain Name itself. In no circumstances is the Closest Encloser
the used to synthesize records though.
A "Source of Synthesis" is defined in the context of a lookup
process as the Wild Card Domain Name immediately descending from
the Closest Encloser provided the Wild Card Domain Name exists.
A Source of Synthesis does not guarantee having a RRSet to use
for synthesis, a Source of Synthesis may even be an empty
non-terminal.
If a Source of Synthesis exists, it will be the Wild Card Domain Name
that is identified by an Asterisk Label below the Closest Encloser.
E.g., "<Asterisk Label>.<Closest Encloser> or "*.<Closest Encloser>."
If the Source of Synthesis does not exist (not on the domain tree),
there will be no wildcard synthesis
The important concept is that for any given lookup process, there
is at most one place at which wildcard synthetic records can be
obtained. If the Source of Synthesis does not exist, the lookup
terminates, the lookup does not look for other wildcard records.
Other terms have been coined on the mailing list in the past. E.g.,
it has been said that existing names block the application of
wildcard records. This is still an appropriate viewpoint, but
replacing this notion with the Closest Encloser and Source of
Synthesis the depiction of the wildcard process is clearer.
3.3.2 Closest Encloser and Source of Synthesis Examples
To illustrate, using the example zone in section 2.2.1 of this document,
the following chart shows QNAMEs and the closest enclosers.
QNAME Closest Encloser Source of Synthesis
host3.example. example. *.example.
_telnet._tcp.host1.example. _tcp.host1.example. no source
_telnet._tcp.host2.example. host2.example. no source
_telnet._tcp.host3.example. example. *.example.
_chat._udp.host3.example. example. *.example.
The fact that a closest encloser will be the only superdomain that
can have a candidate wild card will have an impact when it comes to
designing pre-calculated authenticated denial of existence proofs.
3.3.3 Non-existent Source of Synthesis
In RFC 1034:
# If the "*" label does not exist, check whether the name
# we are looking for is the original QNAME in the query
# or a name we have followed due to a CNAME. If the name
# is original, set an authoritative name error in the
# response and exit. Otherwise just exit.
The above passage is clear, evidenced by the lack of discussion and
mis-implementation of it over the years. It is included for
completeness only. (No attempt is made to re-interpret it lest
a mistake in editing leads to confusion.)
3.3.4 Type Matching
RFC 1034 concludes part c with this:
# If the "*" label does exist, match RRs at that node
# against QTYPE. If any match, copy them into the answer
# section, but set the owner of the RR to be QNAME, and
# not the node with the "*" label. Go to step 6.
This final paragraph covers the role of the QTYPE in the lookup process.
Based on implementation feedback and similarities between step a and
step c a change to this passage a change has been made.
The change is to add the following text:
If the data at the source of synthesis is a CNAME, and
QTYPE doesn't match CNAME, copy the CNAME RR into the
answer section of the response changing the owner name
to the QNAME, change QNAME to the canonical name in the
CNAME RR, and go back to step 1.
This is essentially the same text in step a covering the processing of
CNAME RRSets.
4. Considerations with Special Types
Five types of RRSets owned by a Wild Card Domain Name have caused
confusion. Four explicit types causing confusion are SOA, NS, CNAME,
DNAME, and the fifth type - "none."
4.1. SOA RR's at a Wild Card Domain Name
A Wild Card Domain Name owning an SOA RRSet means that the domain
is at the root of the zone (apex). The domain can not be a Source of
Synthesis because that is, but definition, a descendent node (of
the Closest Encloser) and a zone apex is at the top of the zone.
Although a Wild Card Domain Name can not be a Source of Synthesis,
there is no reason to forbid the ownership of an SOA RRSet. This
means that zones with names like "*.<Parent Zone>.", and even
"*.<Parent Sublabels>.<Parent Zone>."
Step 2 (section 3.1) does not provide a means to specify a means to
synthesize a zone. Therefore, according to the rules there, the
only way in which a zone that has a name which is a Wild Card
Domain Name is if the QNAME is in a domain below the zone's name.
E.g., if *.example. has an SOA record, then only a query like
QNAME=*.example., QTYPE=A, QCLASS=IN would see it. As another
example, a QNAME of www.*.example. would also result in passing
through the zone.
4.2. NS RR's at a Wild Card Domain Name
The semantics of a Wild Card Domain Name ownership of a NS RRSet
has been unclear. Looking through RFC 1034, the recommendation
is to have the NS RRSet act the same a any non-special type, e.g.,
like an A RR.
If the NS RRSet in question is at the top of the zone, i.e., the
name also owns an SOA RRSet, the QNAME equals the zone name. This
would trigger part 'a' of Step 3.
In any other case, the Wild Card Domain Name owned NS RRSet would
be the only RRSet (prior to changes instituted by DNSSEC) at the
node by DNS rules. If the QNAME equals the Wild Card Domain Name
or is a subdomain of it, then the node would be considered in part
'b' of Step 3.
Note that there is no synthesis of records in the authority section
because part 'b' does not account for synthesis. The referral
returned would have the Wild Card Domain Name in the authority section,
unchanged.
If the QNAME is not the same as the Wild Card Domain Name nor a
subdomain of it, then part 'c' of Step 3 has been triggered. Once
part 'c' is entered, there is no reverting to part 'b' - i.e.,
once an NS RRSet is synthesized it does not mean that the server has
to consider the name delegated away. I.e., the server is not
synthesizing a record (the NS RRSet) that means the server does not
have the right to synthesize.
4.3. CNAME RR's at a Wild Card Domain Name
The issue of CNAME RR's owned by wild card domain names has prompted
a suggested change to the last paragraph of step 3c of the algorithm
in 4.3.2. The changed text appears in section 3.3.4 of this document.
4.4. DNAME RR's at a Wild Card Domain Name
The specification of the DNAME RR, which is at the proposed level of
standardization, is not as mature as the full standard in RFC 1034.
Because of this, or the reason for this is, there appears to be a
a number of issues with that definition and it's rewrite of the algorithm
in 4.3.2. For the time being, when it comes to wild card processing
issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME
at a wild card domain name is effectively the same as a CNAME at a
wild card domain name.
4.5 Empty Non-terminal Wild Card Domain Name
If a Source of Synthesis is an empty non-terminal, then the response
will be one of no error in the return code and no RRSet in the answer
section.
5. Security Considerations
This document is refining the specifications to make it more likely
that security can be added to DNS. No functional additions are being
made, just refining what is considered proper to allow the DNS,
security of the DNS, and extending the DNS to be more predictable.
6. References
Normative References
[RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969
[RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
Nov-01-1987
[RFC 1035] Domain Names - Implementation and Specification, P.V
Mockapetris, Nov-01-1987
[RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
Bradner, March 1997
Informative References
[RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P.
Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997
[RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999
[RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999
7. Others Contributing to This Document
Others who have been editors of this document: Bob Halley and Robert Elz.
Others who have directly caused text to appear in the document: Paul
Vixie and Olaf Kolkman. Many others have indirect influences on the
content.
8. Editor
Name: Edward Lewis
Affiliation: NeuStar
Address: tbd
Phone: tbd
Email: tbd (please send comments to namedroppers)
Comments on this document can be sent to the editors or the mailing
list for the DNSEXT WG, namedroppers@ops.ietf.org.
9. Trailing Boilerplate
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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Expiration
This document expires on or about 11 April 2005.

836
doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt → doc/draft/draft-ietf-dnsop-ipv6-dns-issues-10.txt
View File

File diff suppressed because it is too large Load Diff