mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 22:15:20 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2010-03-08 22:17:03 +00:00
parent 2c244f981f
commit 39158a4c93
1 changed files with 273 additions and 160 deletions
Download Patch File Download Diff File Expand all files Collapse all files

433
doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt → doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt
View File

@@ -5,12 +5,18 @@ Network Working Group S. Weiler
Internet-Draft SPARTA, Inc.
Updates: 4033, 4034, 4035, 5155 D. Blacka
(if approved) VeriSign, Inc.
Intended status: Standards Track September 5, 2009
Expires: March 9, 2010
Intended status: Standards Track March 8, 2010
Expires: September 9, 2010
Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-09
draft-ietf-dnsext-dnssec-bis-updates-10
Abstract
This document is a collection of technical clarifications to the
DNSSECbis document set. It is meant to serve as a resource to
implementors as well as a repository of DNSSECbis errata.
Status of this Memo
@@ -33,32 +39,30 @@ 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 March 9, 2010.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document is a collection of technical clarifications to the
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Weiler & Blacka Expires March 9, 2010 [Page 1]
Weiler & Blacka Expires September 9, 2010 [Page 1]
Internet-Draft DNSSECbis Implementation Notes September 2009
Internet-Draft DNSSECbis Implementation Notes March 2010
DNSSECbis document set. It is meant to serve as a resource to
implementors as well as a repository of DNSSECbis errata.
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
@@ -68,56 +72,54 @@ Table of Contents
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3
2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3
2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 3
2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 4
3. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4
3.2. Validating Responses to an ANY Query . . . . . . . . . . . 4
3.2. Validating Responses to an ANY Query . . . . . . . . . . . 5
3.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5
3.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5
4. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
4.1. Errors in Canonical Form Type Code List . . . . . . . . . 5
4.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 5
4.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6
4.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
4.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7
4.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
4.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7
4.7. Setting the AD bit on Replies . . . . . . . . . . . . . . 7
4.8. Setting the CD bit on Requests . . . . . . . . . . . . . . 8
4.9. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8
5. Minor Corrections and Clarifications . . . . . . . . . . . . . 8
5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 8
5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 9
5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 9
5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8
4.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8
4.9. Setting the CD bit on Requests . . . . . . . . . . . . . . 8
4.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8
4.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9
4.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 9
4.10.3. Preference Based on Source . . . . . . . . . . . . . 10
5. Minor Corrections and Clarifications . . . . . . . . . . . . . 10
5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 10
5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 10
5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 11
5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Weiler & Blacka Expires March 9, 2010 [Page 2]
Weiler & Blacka Expires September 9, 2010 [Page 2]
Internet-Draft DNSSECbis Implementation Notes September 2009
Internet-Draft DNSSECbis Implementation Notes March 2010
1. Introduction and Terminology
This document lists some additions, clarifications and corrections to
the core DNSSECbis specification, as originally described in
[RFC4033], [RFC4034], and [RFC4035].
[RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
(See section Section 2 for more recent additions to that core
document set.)
It is intended to serve as a resource for implementors and as a
repository of items that need to be addressed when advancing the
@@ -139,8 +141,9 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
2. Important Additions to DNSSSECbis
This section updates the set of core DNSSEC protocol documents
originally specified in Section 10 of [RFC4033].
This section lists some documents that should be considered core
DNSSEC protocol documents in addition to those originally specified
in Section 10 of [RFC4033].
2.1. NSEC3 Support
@@ -154,24 +157,30 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
[RFC5155] should be considered part of the DNS Security Document
Family as described by [RFC4033], Section 10.
Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
SHA1 and RSASHA1-NSEC3-SHA1) signal that a zone MAY be using NSEC3,
rather than NSEC. The zone MAY indeed be using either and validators
supporting these algorithms MUST support both NSEC3 and NSEC
Weiler & Blacka Expires September 9, 2010 [Page 3]
Internet-Draft DNSSECbis Implementation Notes March 2010
responses.
2.2. SHA-256 Support
[RFC4509] describes the use of SHA-256 as a digest algorithm for use
with Delegation Signer (DS) RRs. [I-D.ietf-dnsext-dnssec-rsasha256]
describes the use of the RSASHA256 algorithm for use in DNSKEY and
RRSIG RRs. Validator implementations are strongly encouraged to
include support for this algorithm for DS, DNSKEY, and RRSIG records.
[RFC4509] describes the use of SHA-256 as a digest algorithm in
Delegation Signer (DS) RRs. [RFC5702] describes the use of the
RSASHA256 algorithm in DNSKEY and RRSIG RRs. Validator
implementations are strongly encouraged to include support for this
algorithm for DS, DNSKEY, and RRSIG records.
Weiler & Blacka Expires March 9, 2010 [Page 3]
Internet-Draft DNSSECbis Implementation Notes September 2009
Both [RFC4509] and [I-D.ietf-dnsext-dnssec-rsasha256] should also be
considered part of the DNS Security Document Family as described by
[RFC4033], Section 10.
Both [RFC4509] and [RFC5702] should also be considered part of the
DNS Security Document Family as described by [RFC4033], Section 10.
3. Security Concerns
@@ -205,6 +214,17 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
(original) owner name.
Weiler & Blacka Expires September 9, 2010 [Page 4]
Internet-Draft DNSSECbis Implementation Notes March 2010
3.2. Validating Responses to an ANY Query
[RFC4035] does not address how to validate responses when QTYPE=*.
@@ -217,14 +237,6 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
QNAME and QCLASS MUST be validated. If any of those RRsets fail
validation, the answer is considered Bogus. If there are no RRsets
matching QNAME and QCLASS, that fact MUST be validated according to
Weiler & Blacka Expires March 9, 2010 [Page 4]
Internet-Draft DNSSECbis Implementation Notes September 2009
the rules in [RFC4035] Section 5.4 (as clarified in this document).
To be clear, a validator must not expect to receive all records at
the QNAME in response to QTYPE=*.
@@ -261,6 +273,14 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
[RFC4034] Section 6.2 item 3 has a list of resource record types for
which DNS names in the RDATA are downcased for purposes of DNSSEC
canonical form (for both ordering and signing). That list
Weiler & Blacka Expires September 9, 2010 [Page 5]
Internet-Draft DNSSECbis Implementation Notes March 2010
erroneously contains NSEC and RRSIG. According to [RFC3755], DNS
names in the RDATA of NSEC and RRSIG should not be downcased.
@@ -273,14 +293,6 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
Section 5.2 of [RFC4035] includes rules for how to handle delegations
to zones that are signed with entirely unsupported public key
algorithms, as indicated by the key algorithms shown in those zone's
Weiler & Blacka Expires March 9, 2010 [Page 5]
Internet-Draft DNSSECbis Implementation Notes September 2009
DS RRsets. It does not explicitly address how to handle DS records
that use unsupported message digest algorithms. In brief, DS records
using unknown or unsupported message digest algorithms MUST be
@@ -317,6 +329,14 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
If no private algorithms appear in the DS set or if any supported
algorithm appears in the DS set, no special processing will be
needed. In the remaining cases, the security status of the zone
Weiler & Blacka Expires September 9, 2010 [Page 6]
Internet-Draft DNSSECbis Implementation Notes March 2010
depends on whether or not the resolver supports any of the private
algorithms in use (provided that these DS records use supported hash
functions, as discussed in Section 4.2). In these cases, the
@@ -329,14 +349,6 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
discussed in [RFC4035].
This clarification facilitates the broader use of private algorithms,
Weiler & Blacka Expires March 9, 2010 [Page 6]
Internet-Draft DNSSECbis Implementation Notes September 2009
as suggested by [RFC4955].
4.4. Caution About Local Policy and Multiple RRSIGs
@@ -369,14 +381,27 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
4.6. Setting the DO Bit on Replies
[RFC4035] does not provide any instructions to servers as to how to
set the DO bit. Some authoritative server implementations have
chosen to copy the DO bit settings from the incoming query to the
outgoing response. Others have chosen to never set the DO bit in
responses. Either behavior is permitted. To be clear, in replies to
queries with the DO-bit set servers may or may not set the DO bit.
As stated in [RFC3225], the DO bit of the query MUST be copied in the
response. At least one implementation has done something different,
so it may be wise for resolvers to be liberal in what they accept.
4.7. Setting the AD bit on Replies
Weiler & Blacka Expires September 9, 2010 [Page 7]
Internet-Draft DNSSECbis Implementation Notes March 2010
4.7. Setting the AD Bit on Queries
The use of the AD bit in the query was previously undefined. This
document defines it as a signal indicating that the requester
understands and is interested in the value of the AD bit in the
response. This allows a requestor to indicate that it understands
the AD bit without also requesting DNSSEC data via the DO bit.
4.8. Setting the AD Bit on Replies
Section 3.2.3 of [RFC4035] describes under which conditions a
validating resolver should set or clear the AD bit in a response. In
@@ -385,27 +410,29 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
conditions listed in RFC 4035, section 3.2.3, and the request
contained either a set DO bit or a set AD bit.
4.9. Setting the CD bit on Requests
When processing a request with the CD bit set, a resolver SHOULD
attempt to return all responsive data, even data that has failed
DNSSEC validation. RFC4035 section 3.2.2 requires a resolver
processing a request with the CD bit set to set the CD bit on its
upstream queries.
The guidance in RFC4035 is ambiguous about what to do when a cached
response was obtained with the CD bit not set. In the typical case,
no new query is required, nor does the cache need to track the state
of the CD bit used to make a given query. The problem arises when
the cached response is a server failure (RCODE 2), which may indicate
that the requested data failed DNSSEC validation at an upstream
validating resolver. (RFC2308 permits caching of server failures for
up to five minutes.) In these cases, a new query with the CD bit set
is required.
Weiler & Blacka Expires March 9, 2010 [Page 7]
Internet-Draft DNSSECbis Implementation Notes September 2009
For efficiency, a validator may wish to set the CD bit on all
upstream queries when it has a trust anchor at or above the QNAME
(and thus can reasonably expect to be able to validate the response).
Note that the use of the AD bit in the query was previously
undefined. This document defines it as a signal indicating that the
requester understands and is interested in the value of the AD bit in
the response. This allows a requestor to indicate that it
understands the AD bit without also requesting DNSSEC data via the DO
bit.
4.8. Setting the CD bit on Requests
When processing a request with the CD bit set, the resolver MUST set
the CD bit on its upstream queries.
4.9. Nested Trust Anchors
4.10. Nested Trust Anchors
A DNSSEC validator may be configured such that, for a given response,
more than one trust anchor could be used to validate the chain of
@@ -414,13 +441,95 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
When the validator is asked to validate a response to
"www.sub.zone.example.", either trust anchor could apply.
When presented with this situation, DNSSEC validators SHOULD try all
applicable trust anchors until one succeeds.
There are some scenarios where different behaviors, such as choosing
the trust anchor closest to the QNAME of the response, may be
desired. A DNSSEC validator MAY enable such behaviors as
configurable overrides.
Weiler & Blacka Expires September 9, 2010 [Page 8]
Internet-Draft DNSSECbis Implementation Notes March 2010
When presented with this situation, DNSSEC validators have a choice
of which trust anchor(s) to use. Which to use is a matter of
implementation choice. It is possible and perhaps advisable to
expose the choice of policy as a configuration option. The rest of
this section discusses some possible policies. As a default, we
suggest that validators implement the "Accept Any Success" policy
described below in Section 4.10.2 while exposing other policies as
configuration options.
4.10.1. Closest Encloser
One policy is to choose the trust anchor closest to the QNAME of the
response. In our example, that would be the "zone.example." trust
anchor.
This policy has the advantage of allowing the operator to trivially
override a parent zone's trust anchor with one that the operator can
validate in a stronger way, perhaps because the resolver operator is
affiliated with the zone in question. This policy also minimizes the
number of public key operations needed, which may be of benefit in
resource-constrained environments.
This policy has the disadvantage of possibly giving the user some
unexpected and unnecessary validation failures when sub-zone trust
anchors are neglected. As a concrete example, consider a validator
that configured a trust anchor for "zone.example." in 2009 and one
for "example." in 2011. In 2012, "zone.example." rolls its KSK and
updates its DS records, but the validator operator doesn't update its
trust anchor. With the "closest encloser" policy, the validator gets
validation failures.
4.10.2. Accept Any Success
Another policy is to try all applicable trust anchors until one gives
a validation result of Secure, in which case the final validation
result is Secure. If and only if all applicable trust anchors give a
result of Insecure, the final validation result is Insecure. If one
or more trust anchors lead to a Bogus result and there is no Secure
result, then the final validation result is Bogus.
This has the advantage of causing the fewer validation failures,
which may deliver a better user experience. If one trust anchor is
out of date (as in our above example), the user may still be able to
get a Secure validation result (and see DNS responses).
This policy has the disadvantage of making the validator subject to
compromise of the weakest of these trust anchors while making its
relatively painless to keep old trust anchors configured in
Weiler & Blacka Expires September 9, 2010 [Page 9]
Internet-Draft DNSSECbis Implementation Notes March 2010
perpetuity.
4.10.3. Preference Based on Source
When the trust anchors have come from different sources (e.g.
automated updates ([RFC5011]), one or more DLV registries
([RFC5074]), and manually configured), a validator may wish to choose
between them based on the perceived reliability of those sources.
The order of precedence might be exposed as a configuration option.
For example, a validator might choose to prefer trust anchors found
in a DLV registry over those manually configured on the theory that
the manually configured ones will not be as aggressively maintained.
Conversely, a validator might choose to prefer manually configured
trust anchors over those obtained from a DLV registry on the theory
that the manually configured ones have been more carefully
authenticated.
Or the validator might do something more complicated: prefer a sub-
set of manually configured trust anchors (based on a configuration
option), then trust anchors that have been updated using the RFC5011
mechanism, then trust anchors from one DLV registry, then trust
anchors from a different DLV registry, then the rest of the manually
configured trust anchors.
5. Minor Corrections and Clarifications
@@ -438,23 +547,20 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
does not already have the parent's NS RRset. Section 4.2 of
[RFC4035] specifies a mechanism for doing that.
Weiler & Blacka Expires March 9, 2010 [Page 8]
Internet-Draft DNSSECbis Implementation Notes September 2009
5.2. Clarifications on DNSKEY Usage
Questions of the form "can I use a different DNSKEY for signing this
RRset" have occasionally arisen.
The short answer is "yes, absolutely". You can even use a different
Weiler & Blacka Expires September 9, 2010 [Page 10]
Internet-Draft DNSSECbis Implementation Notes March 2010
DNSKEY for each RRset in a zone, subject only to practical limits on
the size of the DNSKEY RRset. However, be aware that there is no way
to tell resolvers what a particularly DNSKEY is supposed to be used
@@ -498,18 +604,19 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
However, the same section contains a regular expression:
Weiler & Blacka Expires March 9, 2010 [Page 9]
Internet-Draft DNSSECbis Implementation Notes September 2009
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
The plus sign in the regular expression indicates that there is one
or more of the preceding element. This means that there must be at
least one window block. If this window block has no types, it
Weiler & Blacka Expires September 9, 2010 [Page 11]
Internet-Draft DNSSECbis Implementation Notes March 2010
contradicts with the first statement. Therefore, the correct text in
RFC 5155 3.2.1 should be:
@@ -538,29 +645,19 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
8.1. Normative References
[I-D.ietf-dnsext-dnssec-rsasha256]
Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC",
draft-ietf-dnsext-dnssec-rsasha256-14 (work in progress),
June 2009.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
RFC 1034, STD 13, November 1987.
STD 13, RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, December 2001.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
Weiler & Blacka Expires March 9, 2010 [Page 10]
Internet-Draft DNSSECbis Implementation Notes September 2009
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
@@ -569,6 +666,13 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Weiler & Blacka Expires September 9, 2010 [Page 12]
Internet-Draft DNSSECbis Implementation Notes March 2010
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006.
@@ -576,6 +680,10 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702,
October 2009.
8.2. Informative References
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
@@ -587,6 +695,12 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
[RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
July 2007.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007.
[RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
November 2007.
Appendix A. Acknowledgments
@@ -607,22 +721,22 @@ Appendix A. Acknowledgments
contributed text for Section 4.5.
The bug relating to delegation NSEC RR's in Section 3.1 was found by
Roy Badami. Roy Arends found the related problem with DNAME.
Weiler & Blacka Expires March 9, 2010 [Page 11]
Weiler & Blacka Expires September 9, 2010 [Page 13]
Internet-Draft DNSSECbis Implementation Notes September 2009
Internet-Draft DNSSECbis Implementation Notes March 2010
Roy Badami. Roy Arends found the related problem with DNAME.
The errors in the [RFC4035] examples were found by Roy Arends, who
also contributed text for Section 5.3 of this document.
The editors would like to thank Ed Lewis, Danny Mayer, Olafur
Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive
comments on the text of this document.
The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
Olafur Gudmundsson, Suzanne Woolf, and Scott Rose for their
substantive comments on the text of this document.
Authors' Addresses
@@ -666,7 +780,6 @@ Authors' Addresses
Weiler & Blacka Expires March 9, 2010 [Page 12]
Weiler & Blacka Expires September 9, 2010 [Page 14]