+
DNSEXT Working Group Olafur Gudmundsson
- INTERNET-DRAFT June 2002
- <draft-ietf-dnsext-delegation-signer-08.txt>
+ INTERNET-DRAFT October 2002
+ <draft-ietf-dnsext-delegation-signer-10.txt>
Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090.
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
- This draft expires on December 30, 2002.
+ This draft expires on April 16, 2003.
Copyright Notice
-Gudmundsson Expires December 2002 [Page 1]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
+Gudmundsson Expires April 2003 [Page 1]
+
+INTERNET-DRAFT Delegation Signer Record October 2002
operational considerations. The intent is to use this resource record
on the Internet have differing NS RRsets at parent and child. There
are a number of reasons for this, including a lack of communication
between parent and child and bogus name servers being listed to meet
- registrar requirements.
+ registry requirements.
DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to
have its KEY RRset signed by its parent to create a verifiable chain
-Gudmundsson Expires December 2002 [Page 2]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
+Gudmundsson Expires April 2003 [Page 2]
+
+INTERNET-DRAFT Delegation Signer Record October 2002
Another complication of the DNSSEC key model is that the KEY record
-Gudmundsson Expires December 2002 [Page 3]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
+Gudmundsson Expires April 2003 [Page 3]
+
+INTERNET-DRAFT Delegation Signer Record October 2002
This is cryptographically equivalent to using just KEY records.
RRset. If a query contains the OK bit, a server returning a referral
for the delegation MUST include the following RRsets in the authority
section in this order:
+ If DS RRset is present:
parent NS RRset
- DS and SIG(DS) (if DS is present)
- parent NXT and SIG(NXT) (If no DS)
+ DS and SIG(DS)
+ If no DS RRset is present:
+ parent NS RRset
+ parent NXT and SIG(NXT)
This increases the size of referral messages and may cause some or
all glue to be omitted. If the DS or NXT RRsets with signatures do
- not fit in the DNS message, the TC bit MUST be set. Additional
- section processing is not changed.
+Gudmundsson Expires April 2003 [Page 4]
-Gudmundsson Expires December 2002 [Page 4]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
+INTERNET-DRAFT Delegation Signer Record October 2002
+ not fit in the DNS message, the TC bit MUST be set. Additional
+ section processing is not changed.
+
A DS RRset accompanying an NS RRset indicates that the child zone is
secure. If an NS RRset exists without a DS RRset, the child zone is
- unsecure. DS RRsets MUST NOT appear at non-delegation points or at a
- zone's apex.
+ unsecure (from the parents point of view). DS RRsets MUST NOT appear
+ at non-delegation points or at a zone's apex.
- The following section 2.2.1 replaces RFC2535 sections 2.3.4 and 3.4,
- section 2.2.2 replaces RFC3008 section 2.7, and RFC3090 updates are
- in section 2.2.3.
+ Section 2.2.1 defines special considerations related to authoritative
+ servers responding to DS queries. Section 2.2.2 replaces RFC2535
+ sections 2.3.4 and 3.4, section 2.2.3 replaces RFC3008 section 2.7,
+ and section 2.2.4 updates RFC3090.
-2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points
+2.2.2 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points
DNS security views each zone as a unit of data completely under the
control of the zone owner with each entry (RRset) signed by a special
since one server could be serving both the zone above and below a
delegation point [RFC 2181].
- Each DS RRset stored in the parent zone MUST be signed by one of the
- parent zone's private key. The parent zone MUST NOT contain a KEY
- RRset at any delegation point. Delegations in the parent MAY contain
- only the following RR types: NS, DS, NXT and SIG. The NS RRset MUST
- NOT be signed. The NXT RRset is the exceptional case: it will always
- appear differently and authoritatively in both the parent and child
- zones if both are secure.
+ Each DS RRset stored in the parent zone MUST be signed by, at least,
+ one of the parent zone's private key. The parent zone MUST NOT
+ contain a KEY RRset at any delegation point. Delegations in the
+ parent MAY contain only the following RR types: NS, DS, NXT and SIG.
+ The NS RRset MUST NOT be signed. The NXT RRset is the exceptional
+ case: it will always appear differently and authoritatively in both
+ the parent and child zones if both are secure.
A secure zone MUST contain a self-signed KEY RRset at its apex. Upon
verifying the DS RRset from the parent, a resolver MAY trust any KEY
in the answer section.
-2.2.2 Signer's Name (replaces RFC3008 section 2.7)
- The signer's name field of a SIG RR MUST contain the name of the zone
- to which the data and signature belong. The combination of signer's
- name, key tag, and algorithm MUST identify a zone key if the SIG is
- to be considered material. This document defines a standard policy
-Gudmundsson Expires December 2002 [Page 5]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
+Gudmundsson Expires April 2003 [Page 5]
+
+INTERNET-DRAFT Delegation Signer Record October 2002
+
+
+2.2.2.1 Special processing for DS queries
+
+ When a server is authoritative for the parent zone at a delegation
+ point and receives a query for the DS record at that name, it will
+ return the DS from the parent zone. This is true whether or not it
+ is also authoritative for the child zone.
+
+ When the server is authoritative for the child zone at a delegation
+ point but not the parent zone, there is no natural response, since
+ the child zone is not authoritative for the DS record at the zone's
+ apex. As these queries are only expected to originate from recursive
+ servers which are not DS-aware, the authoritative server MUST answer
+ with:
+ RCODE: NOERROR
+ AA bit: set
+ Answer Section: Empty
+ Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
+
+ That is, it answers as if it is authoritative and the DS record does
+ not exist. DS-aware recursive servers will query the parent zone at
+ delegation points, so will not be affected by this.
+ A server authoritative for only the child zone at a delegation point
+ that is also a caching server MAY (if the RD bit is set in the query)
+ perform recursion to find the DS record at the delegation point, and
+ may return the DS record from its cache. In this case, the AA bit
+ MUST not be set in the response.
+
+
+2.2.3 Signer's Name (replaces RFC3008 section 2.7)
+
+ The signer's name field of a SIG RR MUST contain the name of the zone
+ to which the data and signature belong. The combination of signer's
+ name, key tag, and algorithm MUST identify a zone key if the SIG is
+ to be considered material. This document defines a standard policy
for DNSSEC validation; local policy may override the standard policy.
There are no restrictions on the signer field of a SIG(0) record.
record.
+
+
+
+
+Gudmundsson Expires April 2003 [Page 6]
+
+INTERNET-DRAFT Delegation Signer Record October 2002
+
+
2.2.4.1 RFC3090: Updates to section 1: Introduction
Most of the text is still relevant but the words ``NULL key'' are to
DNS delegation model, declaring it to be broken because there is no
good way to assert if a delegation exists. In the RFC2535 version of
DNSSEC, the presence of the NS bit in the NXT bit map proves there is
-
-
-
-Gudmundsson Expires December 2002 [Page 6]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
-
-
a delegation at this name. Something more explicit is needed and the
DS record addresses this need for secure delegations.
The DS record is a major change to DNS: it is the first resource
record that can appear only on the upper side of a delegation. Adding
- it will cause interoperability problems and requires a flag day for
+ it will cause interoperabilty problems and requires a flag day for
DNSSEC. Many old servers and resolvers MUST be upgraded to take
advantage of DS. Some old servers will be able to be authoritative
for zones with DS records but will not add the NXT or DS records to
the authority section. The same is true for caching servers; in
fact, some may even refuse to pass on the DS or NXT records.
+
+
+
+
+Gudmundsson Expires April 2003 [Page 7]
+
+INTERNET-DRAFT Delegation Signer Record October 2002
+
+
2.4 Wire Format of the DS record
The DS (type=TDB) record contains these fields: key tag, algorithm,
KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
Digest type value 0 is reserved, value 1 is SHA-1, and reserving
- other types requires IETF standards action. For interoperability
+ other types requires IETF standards action. For interoperabilty
reasons, as few digest algorithms as possible should be reserved. The
-
-
-
-Gudmundsson Expires December 2002 [Page 7]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
-
-
only reason to reserve additional digest types is to increase
security.
The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
of key size, new digest types probably will have larger digests.
+
+
+
+Gudmundsson Expires April 2003 [Page 8]
+
+INTERNET-DRAFT Delegation Signer Record October 2002
+
+
2.4.1 Justifications for Fields
The algorithm and key tag fields are present to allow resolvers to
delegations are locally secure. This is bad, but the DNSEXT Working
Group has determined that rather than dealing with both
RFC2535-secured zones and DS-secured zones, a rapid adoption of DS is
-
-
-
-Gudmundsson Expires December 2002 [Page 8]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
-
-
preferable. Thus the only option for early adopters is to upgrade to
DS as soon as possible.
RFC2535 adds the following two cases:
+
+
+Gudmundsson Expires April 2003 [Page 9]
+
+INTERNET-DRAFT Delegation Signer Record October 2002
+
+
Secure RFC2535: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXT
Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
-Gudmundsson Expires December 2002 [Page 9]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson Expires April 2003 [Page 10]
+
+INTERNET-DRAFT Delegation Signer Record October 2002
3 Resolver
secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example.
secure.example. KEY <tag=12345 alg=3>
+ secure.example. KEY <tag=54321 alg=5>
+ secure.example. NXT <nxt stuff>
secure.example. SIG(KEY) <key-tag=12345 alg=3>
- secure.example. SIG(SOA) <key-tag=12345 alg=3>
- secure.example. SIG(NS) <key-tag=12345 alg=5>
+ secure.example. SIG(SOA) <key-tag=54321 alg=5>
+ secure.example. SIG(NS) <key-tag=54321 alg=5>
+ secure.example. SIG(NXT) <key-tag=54321 alg=5>
In this example the private key for "example." signs the DS record
for "secure.example.", making that a secure delegation. The DS record
and trusted.
This example has only one DS record for the child, but parents MUST
- allow multiple DS records to facilitate key rollover. It is strongly
- recommended that the DS RRset be kept small: two or three DS records
- SHOULD be sufficient in all cases.
+ allow multiple DS records to facilitate key rollover and multiple KEY
+ algorithms.
+
- The resolver determines the security status of "unsecure.example." by
- examining the parent zone's NXT record for this name. The absence of
- the DS bit indicates an unsecure delegation.
-Gudmundsson Expires December 2002 [Page 10]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
+Gudmundsson Expires April 2003 [Page 11]
+INTERNET-DRAFT Delegation Signer Record October 2002
+
+
+ The resolver determines the security status of "unsecure.example." by
+ examining the parent zone's NXT record for this name. The absence of
+ the DS bit indicates an unsecure delegation. Note the NXT record
+ SHOULD only be examined after verifying the corresponding signature.
3.1 Resolver Cost Estimates for DS Records
The DS record represents a change to the DNSSEC protocol and there is
an installed base of implementations, as well as textbooks on how to
- set up secure delegations. Implementations that do not understand the
- DS record will not be able to follow the KEY to DS to KEY chain and
- will consider all zones secured that way as unsecure.
+Gudmundsson Expires April 2003 [Page 12]
+INTERNET-DRAFT Delegation Signer Record October 2002
-Gudmundsson Expires December 2002 [Page 11]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
+ set up secure delegations. Implementations that do not understand the
+ DS record will not be able to follow the KEY to DS to KEY chain and
+ will consider all zones secured that way as unsecure.
5 IANA Considerations:
[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC
3225, December 2001.
-[RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver
- message size requirements'', RFC 3226, December 2001.
+Gudmundsson Expires April 2003 [Page 13]
+INTERNET-DRAFT Delegation Signer Record October 2002
-Gudmundsson Expires December 2002 [Page 12]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2002
+
+[RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver
+ message size requirements'', RFC 3226, December 2001.
Author Address
+Gudmundsson Expires April 2003 [Page 14]
-
-
-
-Gudmundsson Expires December 2002 [Page 13]
-Network Working Group R. Arends
-Internet-Draft Nominum
-Expires: January 21, 2003 M. Larson
+DNS Extensions R. Arends
+Internet-Draft
+Expires: April 24, 2003 M. Larson
VeriSign
D. Massey
USC/ISI
S. Rose
NIST
- July 23, 2002
+ October 24, 2002
DNS Security Introduction and Requirements
- draft-ietf-dnsext-dnssec-intro-02
+ draft-ietf-dnsext-dnssec-intro-03
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 21, 2003.
+ This Internet-Draft will expire on April 24, 2003.
Copyright Notice
-Arends, et al. Expires January 21, 2003 [Page 1]
+Arends, et al. Expires April 24, 2003 [Page 1]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-Arends, et al. Expires January 21, 2003 [Page 2]
+Arends, et al. Expires April 24, 2003 [Page 2]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
1. Introduction
-Arends, et al. Expires January 21, 2003 [Page 3]
+Arends, et al. Expires April 24, 2003 [Page 3]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
2. Definitions of Important DNSSEC Terms
- trusted key: A public key, for a zone or a host, that a resolver
- trusts and that can therefore be used to verify data. A key can
- become trusted in two ways. First, it can be statically
- configured and declared as trusted in the resolver's
- configuration. Second, if a new key is referenced by a DS record
- that is signed by an already trusted key, and the signature
- verifies, the new key becomes trusted.
-
- chain of trust: In DNSSEC, a key signs a DS record, which points to
- another key, which in turn signs another DS record, which points
- to yet another key, etc. This alternating succession of KEY and
- DS records forms a chain of signed data, with each link in the
- chain vouching for the next. A resolver starting at a piece of
- data in the chain signed by a trusted key can verify all
- subsequent signatures. Thus all subsequent data in the chain is
- trusted.
+ authentication key: A public key, for a zone or a host, that a
+ resolver trusts and that can therefore be used to verify data. A
+ key can become trusted in two ways: First, it can be statically
+ configured and declared in the resolver's initial configuration.
+ Second, if a new key is referenced by a DS record that is signed
+ by an already known authentication key, and the signature
+ verifies, the new key becomes trusted by the resolver.
+
+ authentication path: In DNSSEC, a key signs a DS record, which points
+ to another key, which in turn signs another DS record, which
+ points to yet another key, etc. This alternating succession of
+ KEY and DS records forms a chain of signed data, with each link in
+ the chain vouching for the next. A resolver starting at a piece
+ of data in the chain signed by a known authentication key can
+ verify all subsequent signatures. Thus all subsequent data in the
+ chain is verified and authenticated.
security-aware resolver: A resolver (defined in section 2.4 of [4])
that understands the DNS security extensions. In particular, a
- security-aware resolver uses trusted keys to verify signatures
- over RRsets and (optionally) DNS messages.
+ security-aware resolver uses known authentication keys to verify
+ signatures over RRsets and (optionally) DNS messages.
security-aware server: A name server (also defined in section 2.4 of
[4]) that understands the DNS security extensions. In particular,
unsigned zone: The proper term for the opposite of a secure zone.
- secure zone: A zone whose RRsets are signed and which contains
+ signed zone: A zone whose RRsets are signed and which contains
properly constructed KEY, SIG, NXT and (optionally) DS records.
-Arends, et al. Expires January 21, 2003 [Page 4]
+Arends, et al. Expires April 24, 2003 [Page 4]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
3. Services Provided by DNS Security
record (see Section 3.2 below). (Note that the private keys used to
sign zone data must be kept secure and best practices call for them
to be stored offline.) To reliably discover a public key by DNS
- resolution, the key itself needs to be signed by another key that the
- resolver trusts. Zone information is authenticated by forming a
- chain of trust from a newly learned public key back to a trusted
- public key (which is either statically configured or previously
- learned and verified). Therefore, the resolver must be configured
- with at least one public key that authenticates one zone as a
- starting point. To establish this chain of trust, security-aware
- servers attempt to send the signature(s) needed to authenticate a
- zone's public key in the DNS reply message along with the public key
- itself, provided there is space available in the message.
+ resolution, the key itself needs to be signed by either a statically
+ configured authentication key or another key that has been previously
+ authenticated. Zone information is authenticated by forming a chain
+ from a newly learned public key back to a previously known
+ authentication public key (which is either statically configured or
+ previously learned and verified). Therefore, the resolver must be
+ configured with at least one public key that authenticates one zone
+ as a starting point. To establish this authentication chain,
+ security-aware servers attempt to send the signature(s) needed to
+ authenticate a zone's public key in the DNS reply message along with
+ the public key itself, provided there is space available in the
+ message.
- The chain of trust specified in the original DNS security extensions
- proceeded from signed KEY record to signed KEY record, as necessary,
- and finally to the queried RRset. A new record, the delegation
- signer (DS), has been added for additional flexibility. The DS RRset
+ The authentication chain specified in the original DNS security
+ extensions proceeded from signed KEY record to signed KEY record, as
-Arends, et al. Expires January 21, 2003 [Page 5]
+Arends, et al. Expires April 24, 2003 [Page 5]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
- resides at a delegation point in a parent zone and specifies the keys
- used by the specified child zone to self-sign the KEY RRset at its
- apex. The child, in turn, uses one of these keys to sign its zone
- data. The chain of trust is therefore DS->KEY->[DS->KEY->...]-
- >RRset.
+ necessary, and finally to the queried RRset. A new record, the
+ delegation signer (DS), has been added for additional flexibility.
+ The DS RRset resides at a delegation point in a parent zone and
+ specifies the keys used by the specified child zone to self-sign the
+ KEY RRset at its apex. The child, in turn, uses one of these keys to
+ sign its zone data. The authentication chain is therefore DS->KEY-
+ >[DS->KEY->...]->RRset.
Adding data origin authentication and data integrity requires minor
changes to the on-the-wire DNS protocol. Several new resource record
The KEY resource record is defined to associate public keys with DNS
names. This record permits the DNS to be used as a public key
distribution mechanism in support of DNSSEC. Security-aware
- resolvers can query for a zone's public key when establishing a chain
- of trust.
+ resolvers can query for a zone's public key when establishing a
+ authentication chain.
The syntax of the KEY resource record (and the other additional
resource records required for DNSSEC) is described in [9]. It
now restricted for use with DNSSEC only. Work is in progress on
storing public keys [14] and certificates [15] used by other
protocols and applications in the DNS. A secure DNS tree could then
- be used as a lightweight trust mechanism. Some administrators and
- users may consider a validated DNSSEC signature to be sufficient to
-Arends, et al. Expires January 21, 2003 [Page 6]
+Arends, et al. Expires April 24, 2003 [Page 6]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
- trust a public key stored in the DNS.
+ be used as a lightweight key distribution mechanism that could
+ support other protocols. However, this should not lead to the
+ conclusion that the DNS is then safe to use as a trusted protocol or
+ a Public Key Infrastructure. DNSSEC lacks many features found in a
+ PKI such as a Certificate Revocation List (CRL).
3.3 Transaction Security
-
-
-
-
-Arends, et al. Expires January 21, 2003 [Page 7]
+Arends, et al. Expires April 24, 2003 [Page 7]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
4. Services Not Provided by DNS Security
-Arends, et al. Expires January 21, 2003 [Page 8]
+Arends, et al. Expires April 24, 2003 [Page 8]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
5. Resolver Considerations
A security-aware resolver needs to be able to perform necessary
cryptographic functions to verify digital signatures using at least
the mandatory-to-implement algorithms. Also, security-aware
- resolvers must be capable of forming a chain of trust from a newly
- learned zone back to a trusted key. This might require additional
- queries to intermediate DNS zones for necessary KEY, DS and SIG
- records. It is assumed that a security-aware resolver will be
- configured with at least one trusted key to aid this process.
+ resolvers must be capable of forming a authentication chain from a
+ newly learned zone back to a trusted authentication key. This might
+ require additional queries to intermediate DNS zones for necessary
+ KEY, DS and SIG records. It is assumed that a security-aware
+ resolver will be configured with at least one authentication key to
+ aid this process.
The stub resolver found in many hosts may be augmented to provide a
different set of security features instead of the full security
part of the DNS resolution path, the resolver cannot ensure security.
If a security-aware resolver must rely on an unsecure server (or
unsigned zone), the resolver cannot verify DNS responses and should
- rely on local policy when trusting responses.
+ rely on local policy when following responses.
-
-Arends, et al. Expires January 21, 2003 [Page 9]
+Arends, et al. Expires April 24, 2003 [Page 9]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
6. Zone Considerations
-Arends, et al. Expires January 21, 2003 [Page 10]
+Arends, et al. Expires April 24, 2003 [Page 10]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
7. Server Considerations
-Arends, et al. Expires January 21, 2003 [Page 11]
+Arends, et al. Expires April 24, 2003 [Page 11]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
8. DNS Security Document Family
|
+-----------+ +-------------+
| DNSSEC | | New |
- | Protocol |<-------->| Security |
+ | Protocol |--------->| Security |
| Documents | | Uses |
+-----------+ +-------------+
|
-Arends, et al. Expires January 21, 2003 [Page 12]
+Arends, et al. Expires April 24, 2003 [Page 12]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
2. Resource Records for DNS Security Extensions [9]
-Arends, et al. Expires January 21, 2003 [Page 13]
+Arends, et al. Expires April 24, 2003 [Page 13]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
9. IANA Considerations
-Arends, et al. Expires January 21, 2003 [Page 14]
+Arends, et al. Expires April 24, 2003 [Page 14]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
10. Security Considerations
-Arends, et al. Expires January 21, 2003 [Page 15]
+Arends, et al. Expires April 24, 2003 [Page 15]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
11. Acknowledgements
-Arends, et al. Expires January 21, 2003 [Page 16]
+Arends, et al. Expires April 24, 2003 [Page 16]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
Normative References
-Arends, et al. Expires January 21, 2003 [Page 17]
+Arends, et al. Expires April 24, 2003 [Page 17]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
Informative References
Authors' Addresses
Roy Arends
- Nominum, Inc.
- 2385 Bay Street
- Redwood City, CA 94063
- USA
+ Bankastraat 41-E
+ 1094 EB Amsterdam
+ NL
- EMail: roy.arends@nominum.com
+ EMail: roy@logmess.com
Matt Larson
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
- Gaithersburg, MD 20899-3460
+ Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.gov
-Arends, et al. Expires January 21, 2003 [Page 18]
+
+Arends, et al. Expires April 24, 2003 [Page 18]
\f
-Internet-Draft DNSSEC Intro. and Requirements July 2002
+Internet-Draft DNSSEC Intro. and Requirements October 2002
Full Copyright Statement
-Arends, et al. Expires January 21, 2003 [Page 19]
+Arends, et al. Expires April 24, 2003 [Page 19]
\f
+
+
Network Working Group R. Arends
-Internet-Draft Nominum, Inc.
-Expires: December 26, 2002 M. Kosters
+Internet-Draft
+Expires: April 14, 2003 M. Kosters
D. Blacka
Verisign, Inc.
- June 27, 2002
+ October 14, 2002
DNSSEC Opt-In
- draft-ietf-dnsext-dnssec-opt-in-02
+ draft-ietf-dnsext-dnssec-opt-in-03
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 December 26, 2002.
+ This Internet-Draft will expire on April 14, 2003.
Copyright Notice
secured. Maintaining this cryptography is not practical or
necessary. This document describes an "Opt-In" model that allows
administrators to omit this cryptography and manage the cost of
- adopting DNSSEC.
+ adopting DNSSEC with large zones.
-Arends, et al. Expires December 26, 2002 [Page 1]
+Arends, et al. Expires April 14, 2003 [Page 1]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
Table of Contents
- 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 5
- 3.1 Server Considerations . . . . . . . . . . . . . . . . . . . . 5
- 3.2 Client Considerations . . . . . . . . . . . . . . . . . . . . 6
- 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
- 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
- References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
- A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 16
- B. Changes from Prior Versions . . . . . . . . . . . . . . . . . 18
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19
-
-
-
-
-
-
-
+ 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3
+ 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1 Server Considerations . . . . . . . . . . . . . . . . . . . 6
+ 3.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.2 Insecure Delegation Responses . . . . . . . . . . . . . . . 6
+ 3.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . . . . 6
+ 3.2 Client Considerations . . . . . . . . . . . . . . . . . . . 7
+ 3.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2.2 Validation Process Changes . . . . . . . . . . . . . . . . . 7
+ 3.2.3 NXT Record Caching . . . . . . . . . . . . . . . . . . . . . 8
+ 3.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . . . . 8
+ 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6. Transition Issues . . . . . . . . . . . . . . . . . . . . . 12
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . 13
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
+ References . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
+ A. Implementing Opt-In using "Views" . . . . . . . . . . . . . 18
+ B. Changes from Prior Versions . . . . . . . . . . . . . . . . 20
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . 21
-
-Arends, et al. Expires December 26, 2002 [Page 2]
+Arends, et al. Expires April 14, 2003 [Page 2]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
1. Definitions and Terminology
RR: is used to refer to a DNS resource record.
- RRset: refers to a Resource Record Set, as defined by [3].
+ RRset: refers to a Resource Record Set, as defined by [3]. In this
+ document, the RRset is also defined to include the covering SIG
+ records, if any exist.
covering NXT record/RRset: is the NXT record used to prove
- (non)existance of a particular name or RRset. This means that for
+ (non)existence of a particular name or RRset. This means that for
a RRset or name 'N', the covering NXT record has the name 'N', or
has an owner name less than 'N' and "next" name greater than 'N'.
delegation: refers to a NS RRset with a name different from the
current zone apex (non-zone-apex), signifying a delegation to a
- subzone.
+ subzone. A delegation returned in a DNS response is also called a
+ "referral".
secure delegation: refers to the NS, DS, NXT and SIG RRsets for a
non-zone-apex owner name, signifying a delegation to a DNSSEC
-
-
-
-Arends, et al. Expires December 26, 2002 [Page 3]
+Arends, et al. Expires April 14, 2003 [Page 3]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
2. Overview
-Arends, et al. Expires December 26, 2002 [Page 4]
+Arends, et al. Expires April 14, 2003 [Page 4]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
3. Protocol Additions
In RFC 2535, delegation NS RRsets are not signed, but instead are
accompanied by a NXT RRset of the same name, and possibly a ("no-
key") KEY RR [4] or DS record [7]. The security status of the
- subzone is determined by the presence or absence of the KEY or DS
- records, cryptographically proven by the NXT record. Opt-In expands
- this definition by allowing insecure delegations to exist within an
+ subzone is determined by the presence of the KEY or DS records,
+ cryptographically proven by the NXT record. Opt-In expands this
+ definition by allowing insecure delegations to exist within an
otherwise signed zone without the corresponding NXT record at the
delegation's owner name. These insecure delegations are proven
- insecure by using the covering NXT record.
+ insecure by using a covering NXT record.
Since this represents a change of the interpretation of NXT records,
resolvers must be able to distinguish between RFC 2535 NXT records
o A RFC2535 NXT type is identified by a one-valued NXT bit in the
type bit map of the NXT record.
+ and,
-3.1 Server Considerations
-
- This protocol change dictates a number of changes to the operation of
- an authoritative server:
+ o An Opt-In NXT record does not assert the non-existence of a name
+ between its owner name and "next" name, although it does assert
+ that any name in this span MUST be an insecure delegation.
- o The server MUST enforce the protocol requirement that ONLY
+ o An Opt-In NXT record does assert the (non)existence of RRsets with
-Arends, et al. Expires December 26, 2002 [Page 5]
+Arends, et al. Expires April 14, 2003 [Page 5]
\f
-Internet-Draft DNSSEC Opt-In June 2002
-
-
- insecure delegation nodes may exist between the secure nodes of
- the zone.
+Internet-Draft DNSSEC Opt-In October 2002
- o The server must be able to retrieve the proper NXT records along
- with referrals to insecure subzone.
- In the delegation signer proposal, NXT records already must be
- returned along with referrals to insecure delegations. The primary
- difference that this proposal introduces is that the appropriate NXT
- record will have a different owner name.
+ the same owner name.
-3.2 Client Considerations
-
- Opt-In imposes some new requirements on the DNS resolver (caching or
- otherwise):
-
- o Resolvers MUST be able to use Opt-In style NXT records to
- cryptographically prove the validity and security status (as
- insecure) of a referral:
-
- * In RFC 2535, this is proven by existence of a verified "no-key"
- KEY RRset.
-
- * Using Delegation Signer, this is proven by the existence of a
- verified NXT record. This NXT record has same name as the
- delegation RRset and does not have the DS bit set in the type
- map.
-
- * Using Opt-In, this is proven by the existence of a verified
- Opt-In NXT record. This NXT record does not have the NXT bit
- set in the type map (that is, it is an Opt-In style NXT record)
- and the name of the delegation RRset is lexicographically
- between the owner and next names of the NXT record.
-
- Note that using Opt-In does not substantially change the nature of
- following referrals within DNSSEC. At every delegation point, the
- resolver will have cryptographic proof that the subzone is secure
- or insecure.
-
- o Resolvers MUST reject as invalid non-NS RRsets that fall within an
- Opt-In tagged NXT record's span.
-
- o Caching resolvers must be able to retrieve the appropriate
- covering Opt-In NXT record when returning referrals that need
- them. This is only a difference when you consider that the
- covering NXT record will not have the same name as the delegation
- RRset itself.
-
-
-
-
-Arends, et al. Expires December 26, 2002 [Page 6]
-\f
-Internet-Draft DNSSEC Opt-In June 2002
+3.1 Server Considerations
- o The AD bit (as defined by [8]) MUST NOT be set in a response
- containing an Opt-In tagged NXT record in the authority section.
+ Opt-In imposes some new requirements on authoritative DNS servers.
+3.1.1 Delegations Only
+ This specification dictates that only insecure delegations may exist
+ between the owner and "next" names of an Opt-In tagged NXT record.
+ Servers and signing tools MUST enforce this restriction.
+3.1.2 Insecure Delegation Responses
+ When returning an Opt-In insecure delegation, the server MUST return
+ the covering NXT RRset in the Authority section.
+ This presents a change from RFC 2535, where the "no-key" KEY RRset
+ would be returned instead. However, in the delegation signer
+ proposal, NXT records already must be returned along with the
+ insecure delegation. The primary difference that this proposal
+ introduces is that the Opt-In tagged NXT record will have a different
+ owner name from the delegation RRset. This may require
+ implementations to do a NXT search on cached responses.
+3.1.3 Wildcards and Opt-In
+ RFC 2535, in section 5.3, describes the practice of returning NXT
+ records to prove the non-existence of an applicable wildcard in non-
+ existent name responses. This NXT record can be described as a
+ "negative wildcard proof". The use of Opt-In NXT records changes the
+ necessity for this practice. For both non-existent name (NXDOMAIN)
+ responses and Opt-In insecure delegation responses, servers MUST NOT
+ return negative wildcard proof records when the query name (qname) is
+ covered by an Opt-In tagged NXT record.
+ The intent of the RFC 2535 negative wildcard proof requirement is to
+ prevent malicious users from undetectably removing valid wildcard
+ responses. In order for this cryptographic proof to work, the
+ resolver must be able to prove:
+ 1. The exact qname does not exist. This is done by the "normal" NXT
+ record.
+ 2. No applicable wildcard exists. This is done by returning one or
+ more NXT records proving that the wildcards do not exist
+ (negative wildcard proofs).
+Arends, et al. Expires April 14, 2003 [Page 6]
+\f
+Internet-Draft DNSSEC Opt-In October 2002
+ However, if the NXT record covering the exact qname is an Opt-In NXT
+ record, the resolver will not be able to prove the first part of this
+ equation, as the qname might exist as an insecure delegation. Thus,
+ since the total proof cannot be completed, the negative wildcard
+ proof records are not useful.
+ The negative wildcard proofs are also not useful when returned as
+ part of an Opt-In insecure delegation response for a similar reason:
+ the resolver cannot prove that the qname does or does not exist, and
+ therefore cannot prove that a wildcard expansion is valid.
+ The presence of an Opt-In tagged NXT record does not change the
+ practice of returning a NXT along with a wildcard expansion. Even
+ though the Opt-In NXT will not be able to prove that the wildcard
+ expansion is valid, it will prove that the wildcard expansion is not
+ masking any signed records.
+3.2 Client Considerations
+ Opt-In imposes some new requirements on DNS resolvers (caching or
+ otherwise).
+3.2.1 Delegations Only
+ As stated in the "Server Considerations" section above, this
+ specification restricts the namespace covered by Opt-In tagged NXT
+ records to insecure delegations only. Thus, resolvers MUST reject as
+ invalid any records that fall within an Opt-In NXT record's span that
+ are not NS records or corresponding glue records.
+3.2.2 Validation Process Changes
+ This specification does not change the resolver's resolution
+ algorithm. However, it does change the DNSSEC validation process.
+ Resolvers MUST be able to use Opt-In tagged NXT records to
+ cryptographically prove the validity and security status (as
+ insecure) of a referral. Resolvers determine the security status of
+ the referred-to zone as follows:
+ o In RFC 2535, the security status is proven by existence of a
+ verified "no-key" KEY RRset. The absence of the "no-key" KEY
+ RRset indicates that the referred-to zone is secure.
+ o Using Delegation Signer, the security status is proven by the
+ existence or absence of a DS record at the same name as the
+ delegation. The absence is proven using a verified NXT record of
+ the same name that does not have the DS bit set in the type map.
+ This NXT record MAY also be tagged as Opt-In.
+Arends, et al. Expires April 14, 2003 [Page 7]
+\f
+Internet-Draft DNSSEC Opt-In October 2002
+ o Using Opt-In, the security status is proven by the existence of a
+ DS record (for secure) or the presence of a verified Opt-In tagged
+ NXT record that covers the delegation name. That is, the NXT
+ record does not have the NXT bit set in the type map, and the
+ delegation name falls between the NXT's owner and "next" name.
+ Using Opt-In does not substantially change the nature of following
+ referrals within DNSSEC. At every delegation point, the resolver
+ will have cryptographic proof that the subzone is secure or insecure.
+ When receiving either an Opt-In insecure delegation response or a
+ non-existent name response where that name is covered by an Opt-In
+ tagged NXT record, the resolver MUST NOT require proof (in the form
+ of a NXT record) that a wildcard did not exist.
+3.2.3 NXT Record Caching
+ Caching resolvers MUST be able to retrieve the appropriate covering
+ Opt-In NXT record when returning referrals that need them. This
+ requirement differs from Delegation Signer in that the covering NXT
+ will not have the same owner name as the delegation. Some
+ implementations may have to use new methods for finding these NXT
+ records.
+3.2.4 Use of the AD bit
+ The AD bit, as defined by [8], MUST NOT be set when:
+ o sending a non-existent name (NXDOMAIN) response where the covering
+ NXT is tagged as Opt-In, unless the NXT record's owner name equals
+ the qname.
+ o sending an Opt-In insecure delegation response, unless the
+ covering (Opt-In) NXT record's owner name equals the delegation
+ name.
+ This rule is based on what the Opt-In NXT record actually proves.
+ For names that exist between the Opt-In NXT record's owner and "next"
+ names, the Opt-In NXT record cannot prove the non-existence or
+ existence of the name. As such, not all data in the response has
+ been cryptographically verified, so the AD bit cannot be set.
-Arends, et al. Expires December 26, 2002 [Page 7]
+Arends, et al. Expires April 14, 2003 [Page 8]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
4. Benefits
-Arends, et al. Expires December 26, 2002 [Page 8]
+Arends, et al. Expires April 14, 2003 [Page 9]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
5. Example
In this example, a query for a signed RRset (e.g., "FIRST-
SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
- SECURE.EXAMPLE A") will result in a standard RFC 2535 response. A
- query for a nonexistent RRset will result in a response that differs
- from RFC 2535 only in the fact that the NXT record will be tagged as
- Opt-In.
+ SECURE.EXAMPLE A") will result in a standard RFC 2535 response.
+
+ A query for a nonexistent RRset will result in a response that
+ differs from RFC 2535 by: the NXT record will be tagged as Opt-In,
+ there will be no NXT record proving the non-existence of a matching
+ wildcard record, and the AD bit will not be set.
A query for an insecure delegation RRset (or a referral) will return
both the answer (in the Authority section) and the corresponding Opt-
-
-
-Arends, et al. Expires December 26, 2002 [Page 9]
+Arends, et al. Expires April 14, 2003 [Page 10]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
- Example A.1: Response to query for WWW.UNSECURE.EXAMPLE. A
+ Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A
- RCODE=NOERROR
+ RCODE=NOERROR, AD=0
Answer Section:
-Arends, et al. Expires December 26, 2002 [Page 10]
+Arends, et al. Expires April 14, 2003 [Page 11]
+\f
+Internet-Draft DNSSEC Opt-In October 2002
+
+
+6. Transition Issues
+
+ Opt-In is not backwards compatible with RFC 2535. RFC 2535 compliant
+ DNSSEC implementations will not recognize Opt-In tagged NXT records
+ as different from RFC 2535 NXT records. Because of this, RFC 2535
+ implementations will reject all Opt-In insecure delegations within a
+ zone as invalid.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 14, 2003 [Page 12]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
-6. Security Considerations
+7. Security Considerations
- Opt-In allows for unsigned delegations. All unsigned names are
- insecure, and their validity (or existence) can not be
+ Opt-In allows for unsigned names. All unsigned names are, by
+ definition, insecure, and their validity (or existence) can not be
cryptographically proven. With Opt-In, a malicious entity is able
- to: insert, modify, or delete insecure delegation RRsets within a
- secured zone. For example, if a resolver received the following
- response from the example zone above:
+ to: insert, modify, or delete insecure delegation RRsets within the
+ Opt-In spans of a otherwise secured zone. In addition, a malicious
+ entity is able to replay or delete wildcard expansions (if there is
+ an existing applicable wildcard) in the Opt-In spans of the zone.
+
+ For example, if a resolver received the following response from the
+ example zone above:
Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
-
-
-
-
-Arends, et al. Expires December 26, 2002 [Page 11]
+Arends, et al. Expires April 14, 2003 [Page 13]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
-7. IANA Considerations
+8. IANA Considerations
None.
-Arends, et al. Expires December 26, 2002 [Page 12]
+Arends, et al. Expires April 14, 2003 [Page 14]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
-8. Acknowledgments
+9. Acknowledgments
The contributions, suggestions and remarks of the following persons
(in alphabetic order) to this draft are acknowledged:
-Arends, et al. Expires December 26, 2002 [Page 13]
+Arends, et al. Expires April 14, 2003 [Page 15]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
References
December 2001.
[7] Gudmundsson, O., "Delegation Signer Resource Record", draft-
- ietf-dnsext-delegation-signer-07 (work in progress), March 2002.
+ ietf-dnsext-delegation-signer-09 (work in progress), September
+ 2002.
[8] Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit",
- draft-ietf-dnsext-ad-is-secure-05 (work in progress), March
- 2002.
+ draft-ietf-dnsext-ad-is-secure-06 (work in progress), June 2002.
Authors' Addresses
Roy Arends
- Nominum, Inc.
- 950 Charter Street
- Redwood City, CA 94063
- US
-
- Phone: +1 650 381 6000
- EMail: Roy.Arends@nominum.com
- URI: http://www.nominum.com
-
-
-
-
+ Bankastraat 41-E
+ 1094 EB Amsterdam
+ NL
-
-
-
-
-
-
-
-Arends, et al. Expires December 26, 2002 [Page 14]
-\f
-Internet-Draft DNSSEC Opt-In June 2002
+ Phone: +31206931681
+ EMail: roy@logmess.com
Mark Kosters
URI: http://www.verisignlabs.com
+
+Arends, et al. Expires April 14, 2003 [Page 16]
+\f
+Internet-Draft DNSSEC Opt-In October 2002
+
+
David Blacka
Verisign, Inc.
21355 Ridgetop Circle
-Arends, et al. Expires December 26, 2002 [Page 15]
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 14, 2003 [Page 17]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
Appendix A. Implementing Opt-In using "Views"
-Arends, et al. Expires December 26, 2002 [Page 16]
+Arends, et al. Expires April 14, 2003 [Page 18]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
-Arends, et al. Expires December 26, 2002 [Page 17]
+Arends, et al. Expires April 14, 2003 [Page 19]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
Appendix B. Changes from Prior Versions
+ Changes from version 02:
+
+ Added text on changes to validation process, use of the AD bit,
+ and interactions with wildcards. Added wildcard caveats to the
+ "Security Considerations" section. Added "Transition Issues"
+ section.
+
Changes from version 01:
Changed to "delegation only". Strengthened "Security
-
-
-
-
-
-
-
-Arends, et al. Expires December 26, 2002 [Page 18]
+Arends, et al. Expires April 14, 2003 [Page 20]
\f
-Internet-Draft DNSSEC Opt-In June 2002
+Internet-Draft DNSSEC Opt-In October 2002
Full Copyright Statement
-Arends, et al. Expires December 26, 2002 [Page 19]
+Arends, et al. Expires April 14, 2003 [Page 21]
+\f
+++ /dev/null
-
-
-DNS Extentions O. Kolkman
-Internet-Draft RIPE NCC
-Expires: March 4, 2003 September 3, 2002
-
-
- KEY RR Key Signing (KS) Flag
- draft-ietf-dnsext-keyrr-key-signing-flag-00.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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 4, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- The Introduction of the DS [1] record has introduced the concept of
- KEY signing and zone signing keys. In general, KEY signing keys are
- the keys that are pointed to by DS records and are the secure entry
- points to a zone. The key signing keys only sign the KEY RRset at
- the apex of a zone, zone signing keys sign all data in a zone. We
- propose a flag to distinguish the KEY signing key from other keys in
- the KEY RR set during DNSSEC operations.
-
- The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
- "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
- interpreted as described in RFC2119.
-
-
-
-
-Kolkman Expires March 4, 2003 [Page 1]
-\f
-Internet-Draft KEY RR Key Signing (KS) Flag September 2002
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The Key Signing flag . . . . . . . . . . . . . . . . . . . . . . 3
- 3. DNSSEC Protocol changes . . . . . . . . . . . . . . . . . . . . 3
- 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 4
- 5. Security considerations . . . . . . . . . . . . . . . . . . . . 4
- 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
- References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman Expires March 4, 2003 [Page 2]
-\f
-Internet-Draft KEY RR Key Signing (KS) Flag September 2002
-
-
-1. Introduction
-
- The Introduction of the DS record has introduced the concept of KEY
- signing keys. In general these are the keys that are pointed to by
- DS records and are the secure entry points to a zone. These key
- signing keys may also be configured in resolver systems that use
- zones as a root for a secure island.
-
- Early deployment tests have shown that during DNSSEC parent-child
- interactions it is useful to indicate which keys are to be used as
- the secure entry point to a zone. We introduce the Key Signing Key
- flag to indicate this special 'administrative' status of the key.
-
- During DNSSEC parent-child interactions it is useful to indicate
- which keys are to be used as the secure entry point to a zone.
- During key rollovers the KS-flag can be used by the parent to
- determine from which key the DS RR is to be generated from.
-
-2. The Key Signing flag
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | flags |K| protocol | algorithm |
- | |S| | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | /
- / public key /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- KEY RR Format
-
-
-
- The bit 15th bit (TBD) in the flags field is assigned to be the key
- signing flag. If set the key is intended to be used as key signing
- key. If the bit is not set then no special meaning should be
- assigned. The 15th bit is currently reserved [2].
-
-3. DNSSEC Protocol changes
-
- The use of the KS flag does NOT change the DNS resolution and
- resolution protocol. The KS flag is only used to provide a hint
- about the different administrative properties and MUST NOT be used
- during the resolving process.
-
-
-
-
-Kolkman Expires March 4, 2003 [Page 3]
-\f
-Internet-Draft KEY RR Key Signing (KS) Flag September 2002
-
-
-4. Operational Guidelines
-
- By setting the KS-flag on a particular key, zone administrators
- indicate that that key should be used as the secure entry point for
- their zone. Therefore zone administrators SHOULD set the bit only
- for zone keys that are used to sign the KEY RRset and are intended to
- act as the top of the chain of trust for their zone.
-
- Parent zone administrators and resolver administrators MAY choose to
- ignore the flag.
-
- Even with the KS-flag there is no mechanism to distinguish between
- keys that should be used by the parent to point DS records to or keys
- to be used by resolver administrators as statically configured keys.
-
- If the bit is modified during the lifetime of the key then this would
- have impact on the keytag and on the hash data in the DS RRs
- intending to point to this key. The bit SHOULD NOT be modified once
- the key has been put into use.
-
-5. Security considerations
-
- The flag MUST NOT be used in the resolution protocol or to determine
- the security status of a key. The flag is to be used for
- administrative purposes only.
-
- If the flag is used to determine which key is to be used as the
- secure entry point then the trust in the key should be inferred from
- an existing DNS chain of trust or by an out of band key exchange.
-
-6. Acknowledgments
-
- The ideas documented in this draft are inspired by communications we
- had with numerous people and ideas published by other folk, Jakob
- Schlyter and Olafur Gudmundsson and Dan Massey have been most
- substantial in providing ideas and feedback.
-
- This document saw the light during a workshop on DNSSEC operations
- hosted by USC/ISI.
-
- "Animal Farm; a Fairy Story" was first published by George Orwell in
- 1945, The version illustrated by Ralph Steadman is one we recommend (
- ISBN: 0151002177 ).
-
-References
-
- [1] Gudmundsson, "Delegation Signer Resource Record", work in
- progress draft-ietf-dnsext-delegation-signer-08.txt, June 2002.
-
-
-
-Kolkman Expires March 4, 2003 [Page 4]
-\f
-Internet-Draft KEY RR Key Signing (KS) Flag September 2002
-
-
- [2] Massey and Rose, "Limiting the Scope of the KEY Resource
- Record", work in progress draft-ietf-dnsext-restrict-key-for-
- dnssec-03, June 28 2002.
-
-
-Author's Address
-
- Olaf M. Kolkman
- RIPE NCC
- Singel 256
- Amsterdam 1016 AB
- NL
-
- Phone: +31 20 535 4444
- EMail: olaf@ripe.net
- URI: http://www.ripe.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman Expires March 4, 2003 [Page 5]
-\f
-Internet-Draft KEY RR Key Signing (KS) Flag September 2002
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman Expires March 4, 2003 [Page 6]
-\f
--- /dev/null
+
+
+DNS Extensions O. Kolkman
+Internet-Draft RIPE NCC
+Expires: March 2, 2003 J. Schlyter
+ Carlstedt Research &
+ Technology
+ September 2002
+
+
+ KEY RR Key Signing (KS) Flag
+ draft-ietf-dnsext-keyrr-key-signing-flag-01
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ 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, 2003.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ With the DS record [1] the concept of key signing and zone signing
+ keys has been introduced. Key signing keys are the keys that sign
+ the keyset only. In general, key signing keys are the keys that are
+ pointed to by DS records and are the first keys to be used when
+ following a chain of trust into the zone. The key signing keys only
+ sign the KEY RRset at the apex of a zone, zone signing keys sign all
+ data in a zone. We propose a flag to distinguish the key signing key
+ from other keys in the KEY RR set during DNSSEC operations.
+
+
+
+
+Kolkman & Schlyter Expires March 2, 2003 [Page 1]
+\f
+Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+
+
+ The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
+ "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
+ interpreted as described in RFC2119.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. The Key Signing Flag . . . . . . . . . . . . . . . . . . . . . 3
+ 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . 3
+ 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
+ 6. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 4
+ 6.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 5
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Schlyter Expires March 2, 2003 [Page 2]
+\f
+Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+
+
+1. Introduction
+
+ "All keys are equal but some keys are more equal than others" [2]
+
+ With the DS record [1] the concept of key signing and zone signing
+ keys has been introduced. In general these are the keys that are
+ pointed to by DS records and are the first keys to be used when
+ following the chain of trust into a zone ( secure entry points of the
+ zone). These key signing keys may also be configured in resolver
+ systems that use zones as a trusted root[4] for a secure island.
+
+ Early deployment tests have shown that during the key-exchange
+ between the parent and the child it is useful to indicate which keys
+ are to be used as the secure entry point to a zone. We introduce the
+ Key Signing Key flag to indicate this special 'administrative' status
+ of the key. The availability of the flag allows the key exchange to
+ be automated where, without the flag, some additional out-of-band
+ communication is needed.
+
+2. The Key Signing Flag
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | flags |K| protocol | algorithm |
+ | |S| | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | /
+ / public key /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ KEY RR Format
+
+
+
+ The bit 15th bit (TBD) in the flags field is assigned to be the key
+ signing flag. If set the key is intended to be used as key signing
+ key. If the bit is not set, no special meaning should be assigned.
+ The 15th bit is currently reserved [3].
+
+3. DNSSEC Protocol Changes
+
+ The use of the KS flag does not change the DNS resolution and
+ resolution protocol. The KS flag is only used to provide a hint
+ about the different administrative properties and MUST NOT be used
+ during the resolving process.
+
+
+
+Kolkman & Schlyter Expires March 2, 2003 [Page 3]
+\f
+Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+
+
+4. Operational Guidelines
+
+ By setting the KS flag on a particular key, zone administrators
+ indicate that that key should be used as the secure entry point for
+ their zone. Therefore zone administrators SHOULD set the bit only
+ for zone keys that are used to sign the KEY RRset and are intended to
+ act as the first link in the chain of trust for their zone.
+
+ Parent zone administrators and resolver administrators that want to
+ configure a keysigning key as their 'trusted key' MAY choose to
+ ignore the flag.
+
+ Using the flag a key rollover can be automated. The parent can use
+ an existing trust relation to verify keysets in which a new key with
+ the KS flag appears.
+
+ If the bit is modified during the lifetime of the key then this would
+ have impact on the keytag and on the hash data in the DS RRs
+ intending to point to this key. The bit SHOULD NOT be modified once
+ the key has been put into use.
+
+5. Security Considerations
+
+ The flag MUST NOT be used in the resolution protocol or to determine
+ the security status of a key. The flag is to be used for
+ administrative purposes only.
+
+ No trust in a key should be inferred from this flag - trust must be
+ inferred from an existing chain of trust or an out-of-band exchange.
+
+ Since this flag MAY be used for automating key exchanges, we think
+ the following consideration is in place.
+
+ Automated mechanisms for rollover of the DS RR may be vulnerable to a
+ class of replay attacks. This may happen after a key exchange where
+ a keyset, containing two keys with the KS flag set, is sent to the
+ parent. The parent verifies the keyset with the existing trust
+ relation and creates the new DS RR from the key that the current DS
+ is not pointing to. This key exchange may be replayed, if the parent
+ does not maintain state of which DS RRs where used previously so that
+ the new DS RR is replaced by the old DS RR again. These kinds of
+ attacks can be prevented by maintaining a registry of keys that have
+ been used to generate DS RRs from previously.
+
+6. Document Changes
+
+
+
+
+
+
+Kolkman & Schlyter Expires March 2, 2003 [Page 4]
+\f
+Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+
+
+6.1 draft version 00 -> 01
+
+ Clean up of references and correction of typos;
+
+ modified Abstract text a little;
+
+ Added explicit warning for replay attacks to the security section;
+
+ Removed the text that hinted on a distinction between a keysigning
+ key configured in resolvers and in parent zones.
+
+
+7. Acknowledgments
+
+ The ideas documented in this draft are inspired by communications we
+ had with numerous people and ideas published by other folk, Olafur
+ Gudmundsson, Daniel Karrenberg, Dan Massey and Sam Weiler have been
+ helping with providing ideas and feedback.
+
+ This document saw the light during a workshop on DNSSEC operations
+ hosted by USC/ISI.
+
+References
+
+ [1] Gudmundsson, "Delegation Signer Resource Record", work in
+ progress draft-ietf-dnsext-delegation-signer-08.txt, June 2002.
+
+ [2] Orwell, "Animal Farm; a Fairy Story"", 1945, <http://
+ www.ddc.net/ygg/etext/animal.htm#10>.
+
+ [3] Massey and Rose, "Limiting the Scope of the KEY Resource
+ Record", work in progress draft-ietf-dnsext-restrict-key-for-
+ dnssec-03, June 28 2002.
+
+ [4] Lewis, E., "DNS Security Extension Clarification on Zone
+ Status", RFC 3090, March 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Schlyter Expires March 2, 2003 [Page 5]
+\f
+Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+
+
+Authors' Addresses
+
+ Olaf M. Kolkman
+ RIPE NCC
+ Singel 256
+ Amsterdam 1016 AB
+ NL
+
+ Phone: +31 20 535 4444
+ EMail: olaf@ripe.net
+ URI: http://www.ripe.net/
+
+
+ Jakob Schlyter
+ Carlstedt Research & Technology
+ Stora Badhusgatan 18-20
+ Goteborg SE-411 21
+ Sweden
+
+ EMail: jakob@crt.se
+ URI: http://www.crt.se/~jakob/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Schlyter Expires March 2, 2003 [Page 6]
+\f
+Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Schlyter Expires March 2, 2003 [Page 7]
+\f
INTERNET-DRAFT Adam M. Costello
-draft-ietf-idn-punycode-02.txt 2002-May-23
-Expires 2002-Nov-23
+draft-ietf-idn-punycode-03.txt 2002-Oct-08
+Expires 2003-Apr-08
- Punycode: An encoding of Unicode for use with IDNA
+ Punycode: A Bootstring encoding of Unicode for IDNA
Status of this Memo
constraints. For the details of the prefix and constraints, see
[IDNA] and [NAMEPREP].
+ Punycode is an instance of a more general algorithm called
+ Bootstring, which allows strings composed from a small set of
+ "basic" code points to uniquely represent any string of code points
+ drawn from a larger set. Punycode is Bootstring with particular
+ parameter values appropriate for IDNA.
+
1.1 Features
Bootstring has been designed to have the following features:
* Uniqueness: There is at most one basic string that represents a
given extended string.
-
+\f
* Reversibility: Any extended string mapped to a basic string can
be recovered from that basic string.
extended string length is small. This is important in the
context of domain names because RFC 1034 [RFC1034] restricts the
length of a domain label to 63 characters.
-\f
+
* Simplicity: The encoding and decoding algorithms are reasonably
simple to implement. The goals of efficiency and simplicity are
at odds; Bootstring aims at a good balance between them.
An overflow is an attempt to compute a value that exceeds the
maximum value of an integer variable.
-
+\f
3. Bootstring description
Bootstring represents an arbitrary sequence of code points (the
"Bootstring algorithms" presents the algorithms as pseudocode.
Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the
algorithms for sample inputs.
-\f
+
The following sections describe the four techniques used in
Bootstring. "Basic code point segregation" is a very simple
and efficient encoding for basic code points occurring in the
code points less than initial_n are basic code points (which is true
for Punycode if code points are unsigned).
- The brace-enclosed conditions "non-basic" and "or m is basic" can be
+ The brace-enclosed conditions "non-basic" and "or c is basic" can be
omitted if initial_n exceeds all basic code points (which is true
for Punycode), because the code point being tested is never less
than initial_n.
D. Punycode sample implementation
\f
/*
-punycode.c from draft-ietf-idn-punycode-02
+punycode.c from draft-ietf-idn-punycode-03
http://www.nicemice.net/idn/
Adam M. Costello
http://www.nicemice.net/amc/
This is ANSI C code (C89) implementing
-Punycode (draft-ietf-idn-punycode-02).
+Punycode (draft-ietf-idn-punycode-03).
*/
- INTERNET-DRAFT expires 2002-Nov-23
+ INTERNET-DRAFT expires 2003-Apr-08
projects / thirdparty / bind9.git / commitdiff
