From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3755.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc3755.txt (limited to 'doc/rfc/rfc3755.txt') diff --git a/doc/rfc/rfc3755.txt b/doc/rfc/rfc3755.txt new file mode 100644 index 0000000..a9a7cf2 --- /dev/null +++ b/doc/rfc/rfc3755.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group S. Weiler +Request for Comments: 3755 SPARTA, Inc. +Updates: 3658, 2535 May 2004 +Category: Standards Track + + + Legacy Resolver Compatibility for Delegation Signer (DS) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + As the DNS Security (DNSSEC) specifications have evolved, the syntax + and semantics of the DNSSEC resource records (RRs) have changed. + Many deployed nameservers understand variants of these semantics. + Dangerous interactions can occur when a resolver that understands an + earlier version of these semantics queries an authoritative server + that understands the new delegation signer semantics, including at + least one failure scenario that will cause an unsecured zone to be + unresolvable. This document changes the type codes and mnemonics of + the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. + +1. Introduction + + The DNSSEC protocol has been through many iterations whose syntax and + semantics are not completely compatible. This has occurred as part + of the ordinary process of proposing a protocol, implementing it, + testing it in the increasingly complex and diverse environment of the + Internet, and refining the definitions of the initial Proposed + Standard. In the case of DNSSEC, the process has been complicated by + DNS's criticality and wide deployment and the need to add security + while minimizing daily operational complexity. + + A weak area for previous DNS specifications has been lack of detail + in specifying resolver behavior, leaving implementors largely on + their own to determine many details of resolver function. This, + combined with the number of iterations the DNSSEC specifications have + been through, has resulted in fielded code with a wide variety of + + + +Weiler Standards Track [Page 1] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + + behaviors. This variety makes it difficult to predict how a protocol + change will be handled by all deployed resolvers. The risk that a + change will cause unacceptable or even catastrophic failures makes it + difficult to design and deploy a protocol change. One strategy for + managing that risk is to structure protocol changes so that existing + resolvers can completely ignore input that might confuse them or + trigger undesirable failure modes. + + This document addresses a specific problem caused by Delegation + Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR + that are incompatible with the semantics in [RFC2535]. Answers + provided by DS-aware servers can trigger an unacceptable failure mode + in some resolvers that implement RFC 2535, which provides a great + disincentive to sign zones with DS. The changes defined in this + document allow for the incremental deployment of DS. + +1.1. Terminology + + In this document, the term "unsecure delegation" means any delegation + for which no DS record appears at the parent. An "unsecure referral" + is an answer from the parent containing an NS RRset and a proof that + no DS record exists for that name. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2. The Problem + + Delegation Signer (DS) introduces new semantics for the NXT RR that + are incompatible with the semantics in RFC 2535. In RFC 2535, NXT + records were only required to be returned as part of a non-existence + proof. With DS, an unsecure referral returns, in addition to the NS, + a proof of non-existence of a DS RR in the form of an NXT and + SIG(NXT). RFC 2535 didn't specify how a resolver was to interpret a + response with RCODE=0, AA=0, and both an NS and an NXT in the + authority section. Some widely deployed 2535-aware resolvers + interpret any answer with an NXT as a proof of non-existence of the + requested record. This results in unsecure delegations being + invisible to 2535-aware resolvers and violates the basic + architectural principle that DNSSEC must do no harm -- the signing of + zones must not prevent the resolution of unsecured delegations. + +2. Possible Solutions + + This section presents several solutions that were considered. + Section 3 describes the one selected. + + + + +Weiler Standards Track [Page 2] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +2.1. Change SIG, KEY, and NXT type codes + + To avoid the problem described above, legacy (RFC2535-aware) + resolvers need to be kept from seeing unsecure referrals that include + NXT records in the authority section. The simplest way to do that is + to change the type codes for SIG, KEY, and NXT. + + The obvious drawback to this is that new resolvers will not be able + to validate zones signed with the old RRs. This problem already + exists, however, because of the changes made by DS, and resolvers + that understand the old RRs (and have compatibility issues with DS) + are far more prevalent than 2535-signed zones. + +2.2. Change a subset of type codes + + The observed problem with unsecure referrals could be addressed by + changing only the NXT type code or another subset of the type codes + that includes NXT. This has the virtue of apparent simplicity, but + it risks introducing new problems or not going far enough. It's + quite possible that more incompatibilities exist between DS and + earlier semantics. Legacy resolvers may also be confused by seeing + records they recognize (SIG and KEY) while being unable to find NXTs. + Although it may seem unnecessary to fix that which is not obviously + broken, it's far cleaner to change all of the type codes at once. + This will leave legacy resolvers and tools completely blinded to + DNSSEC -- they will see only unknown RRs. + +2.3. Replace the DO bit + + Another way to keep legacy resolvers from ever seeing DNSSEC records + with DS semantics is to have authoritative servers only send that + data to DS-aware resolvers. It's been proposed that assigning a new + EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), and + having authoritative servers send DNSSEC data only in response to + queries with the DA bit set, would accomplish this. This bit would + presumably supplant the DO bit described in [RFC3225]. + + This solution is sufficient only if all 2535-aware resolvers zero out + EDNS0 flags that they don't understand. If one passed through the DA + bit unchanged, it would still see the new semantics, and it would + probably fail to see unsecure delegations. Since it's impractical to + know how every DNS implementation handles unknown EDNS0 flags, this + is not a universal solution. It could, though, be considered in + addition to changing the RR type codes. + + + + + + + +Weiler Standards Track [Page 3] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +2.4. Increment the EDNS version + + Another possible solution is to increment the EDNS version number as + defined in [RFC2671], on the assumption that all existing + implementations will reject higher versions than they support, and + retain the DO bit as the signal for DNSSEC awareness. This approach + has not been tested. + +2.5. Do nothing + + There is a large deployed base of DNS resolvers that understand + DNSSEC as defined by the standards track RFC 2535 and [RFC2065] and, + due to under specification in those documents, interpret any answer + with an NXT as a non-existence proof. So long as that is the case, + zone owners will have a strong incentive to not sign any zones that + contain unsecure delegations, lest those delegations be invisible to + such a large installed base. This will dramatically slow DNSSEC + adoption. + + Unfortunately, without signed zones there's no clear incentive for + operators of resolvers to upgrade their software to support the new + version of DNSSEC, as defined in RFC 3658. Historical data suggests + that resolvers are rarely upgraded, and that old nameserver code + never dies. + + Rather than wait years for resolvers to be upgraded through natural + processes before signing zones with unsecure delegations, addressing + this problem with a protocol change will immediately remove the + disincentive for signing zones and allow widespread deployment of + DNSSEC. + +3. Protocol changes + + This document changes the type codes of SIG, KEY, and NXT. This + approach is the cleanest and safest of those discussed above, largely + because the behavior of resolvers that receive unknown type codes is + well understood. This approach has also received the most testing. + + To avoid operational confusion, it's also necessary to change the + mnemonics for these RRs. DNSKEY will be the replacement for KEY, + with the mnemonic indicating that these keys are not for application + use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace + SIG, and NSEC (Next SECure) will replace NXT. These new types + completely replace the old types, except that SIG(0) [RFC2931] and + TKEY [RFC2930] will continue to use SIG and KEY. + + + + + + +Weiler Standards Track [Page 4] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + + The new types will have exactly the same syntax and semantics as + specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for + the following: + + 1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC + RRs MUST NOT be compressed, + + 2) Embedded domain names in RRSIG and NSEC RRs are not downcased for + purposes of DNSSEC canonical form and ordering nor for equality + comparison, and + + 3) An RRSIG with a type-covered field of zero has undefined + semantics. The meaning of such a resource record may only be + defined by IETF Standards Action. + + If a resolver receives the old types, it SHOULD treat them as unknown + RRs and SHOULD NOT assign any special meaning to them or give them + any special treatment. It MUST NOT use them for DNSSEC validations + or other DNS operational decision making. For example, a resolver + MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs. + If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive + special treatment. As an example, if a SIG is included in a signed + zone, there MUST be an RRSIG for it. Authoritative servers may wish + to give error messages when loading zones containing SIG or NXT + records (KEY records may be included for SIG(0) or TKEY). + + As a clarification to previous documents, some positive responses, + particularly wildcard proofs and unsecure referrals, will contain + NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as negative + answers merely because they contain an NSEC. + +4. IANA Considerations + +4.1. DNS Resource Record Types + + This document updates the IANA registry for DNS Resource Record Types + by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, + respectively. + + Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and + TKEY [RFC2930] use only. + + Type 30 (NXT) should be marked as Obsolete. + + + + + + + + +Weiler Standards Track [Page 5] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +4.2. DNS Security Algorithm Numbers + + To allow zone signing (DNSSEC) and transaction security mechanisms + (SIG(0) and TKEY) to use different sets of algorithms, the existing + "DNS Security Algorithm Numbers" registry is modified to include the + applicability of each algorithm. Specifically, two new columns are + added to the registry, showing whether each algorithm may be used for + zone signing, transaction security mechanisms, or both. Only + algorithms usable for zone signing may be used in DNSKEY, RRSIG, and + DS RRs. Only algorithms usable for SIG(0) and/or TSIG may be used in + SIG and KEY RRs. + + All currently defined algorithms except for Indirect (algorithm 252) + remain usable for transaction security mechanisms. Only RSA/SHA-1 + [RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and + 254) may be used for zone signing. Note that the registry does not + contain the requirement level of each algorithm, only whether or not + an algorithm may be used for the given purposes. For example, + RSA/MD5, while allowed for transaction security mechanisms, is NOT + RECOMMENDED, per [RFC3110]. + + Additionally, the presentation format algorithm mnemonics from + [RFC2535] Section 7 are added to the registry. This document assigns + RSA/SHA-1 the mnemonic RSASHA1. + + As before, assignment of new algorithms in this registry requires + IETF Standards Action. Additionally, modification of algorithm + mnemonics or applicability requires IETF Standards Action. Documents + defining a new algorithm must address the applicability of the + algorithm and should assign a presentation mnemonic to the algorithm. + +4.3. DNSKEY Flags + + Like the KEY resource record, DNSKEY contains a 16-bit flags field. + This document creates a new registry for the DNSKEY flags field. + + Initially, this registry only contains an assignment for bit 7 (the + ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF + Standards Action. + +4.4. DNSKEY Protocol Octet + + Like the KEY resource record, DNSKEY contains an eight bit protocol + field. The only defined value for this field is 3 (DNSSEC). No + other values are allowed, hence no IANA registry is needed for this + field. + + + + + +Weiler Standards Track [Page 6] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +5. Security Considerations + + The changes introduced here do not materially affect security. The + implications of trying to use both new and legacy types together are + not well understood, and attempts to do so would probably lead to + unintended and dangerous results. + + Changing type codes will leave code paths in legacy resolvers that + are never exercised. Unexercised code paths are a frequent source of + security holes, largely because those code paths do not get frequent + scrutiny. + + Doing nothing, as described in section 2.5, will slow DNSSEC + deployment. While this does not decrease security, it also fails to + increase it. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", + RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + + + + + + + + + + +Weiler Standards Track [Page 7] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +6.2. Informative References + + [RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System + Security Extensions", RFC 2065, January 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + +7. Acknowledgments + + The changes introduced here and the analysis of alternatives had many + contributors. With apologies to anyone overlooked, those include: + Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis, + Bill Manning, Paul Vixie, and Suzanne Woolf. + + Thanks to Jakob Schlyter and Mark Andrews for identifying the + incompatibility described in section 1.2. + + In addition to the above, the author would like to thank Scott Rose, + Olafur Gudmundsson, and Sandra Murphy for their substantive comments. + +8. Author's Address + + Samuel Weiler + SPARTA, Inc. + 7075 Samuel Morse Drive + Columbia, MD 21046 + USA + + EMail: weiler@tislabs.com + + + + + + + + + + + + +Weiler Standards Track [Page 8] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Weiler Standards Track [Page 9] + -- cgit v1.2.3