INTERNET DRAFT Thierry Moreau Document: draft-moreau-srvloc-dnssec-priming-00.txt CONNOTECH Category: Experimental April 20, 2007 Expires: October 20, 2007 DNSSEC Validation Root Priming Through SLP (DNSSEC-ROOTP) draft-moreau-srvloc-dnssec-priming-00 Status of this Memo 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The IETF Trust (2007). IPR Disclosure Acknowledgment By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Abstract By assigning the SLP (Service Location Protocol, [RFC2608]) UA (User Agent) role to a DNS resolver, the present document opens the door to selective deployment of DNS root nameservice substitution within an administrative domain. This SLP scheme directly addresses the DNS resolver configuration scaling issue. It is envisioned that various DNS root nameservice substitution undertakings target their respective user base, and no single one will be exposed alone to the global scaling problem. Usage is limited to DNSSEC-enabled root nameservice. Moreover, from the SLP security features, the proposed scheme expands the set of DNS root trust anchor key rollover options. Moreau Experimental [page 1] Internet-Draft DNSSEC-ROOTP April, 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview and Rationales . . . . . . . . . . . . . . . . . . . . . 3 2.1 DNS Root Nameservice Substitution and Motivations . . . . . 3 2.2 Rationale for Departure from the Single DNS Root Dogma . . . 4 2.3 Rationale for SLP Usage . . . . . . . . . . . . . . . . . . 4 2.4 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Use of Service Location Protocol for DNSSEC Priming . . . . . . . 6 3.1 SLP Service Announcement with Attributes . . . . . . . . . . 6 3.2 SLP Usage Rules . . . . . . . . . . . . . . . . . . . . . . 7 4. DNSSEC Priming Operation vs Trust Anchor Key Management . . . . . 7 4.1 Un-authenticated Priming . . . . . . . . . . . . . . . . . . 7 4.2 Priming with SLP Digital Signature Validation . . . . . . . 8 4.3 Priming with Implied TAKREM Trust Anchor Management . . . . 8 4.4 Priming and Rollover with SLP Digital Signature Validation . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Internationalization Considerations . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A - A Primer on DNSSEC Root Priming . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . . . . 11 Informative References . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 12 IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property . . . . . . . . . . . . . . . . . . . . . 12 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 12 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Moreau Experimental [page 2] Internet-Draft DNSSEC-ROOTP April, 2007 1. Introduction The present document addresses well-known DNSSEC deployment and scaling issues. DNSSEC is the DNS security protocol ([RFC4033], [RFC4034], and [RFC4035]). The Service Location Protocol version 2, or SLP ([RFC2608]), is applied to tame some of the issues. For the purpose of the present document, and at the time of writing, the DNSSEC still lacks an accepted standards-based rollover procedure for the DNS root trust anchor key. The timers- based rollover ([TIMERS-ROLL]) is submitted to the IESG wisdom for adoption, and the present author's TAKREM proposal ([SDDA-RR], [TAKREM-DNSSEC]) remains available, at least as a proprietary rollover scheme. The present document then makes contributions in a number of ways: . it discusses the opportunity to operate limited-scope DNS root authoritative nameservers for DNSSEC purposes; . it details the use of SLP to facilitate the deployment of such undertakings; . it investigates the interaction between the SLP security features and DNSSEC root trust anchor initial distribution; . in doing this investigation, it revisits the root trust anchor rollover issue, and while doing so it brings a new solution; and . it provides, in appendix A, a draft formalism for DNNSEC root priming, and while doing so it comes up with a root operational recommendation and a special validating resolver logic for root priming. 2. Overview and Rationales 2.1 DNS Root Nameservice Substitution and Motivations Recently, a model was revisited for DNSSEC deployment near the top of the DNS hierarchy. It relies on the observation that the operation of a small-scale DNSSEC-aware root nameserver is relatively easy. It can be described as DNS root nameservice substitution for DNSSEC support purposes. The technical requirements for a small scale DNS root nameservice are easily met. It is the global reachability objective that is difficult to meet. In summary, an authoritative nameserver operator 1) retrieves the root zone file contents from the Internic ftp site, 2) edits or replaces a few resource records, i.e. SOA record, authoritative NS records, and authoritative A records, and 3) serves the edited root zone contents from the nameserver(s) indicated in the edited A records. A DNS resolver may use this Moreau Experimental [page 3] Internet-Draft DNSSEC-ROOTP April, 2007 substitute nameservice if it is properly configured. If DNSSEC enters in the picture, the editing step 2) above is augmented with the addition of DNSKEY records for the digital signature keys, and DS resource records for secure delegations to TLDs that support DNSSEC. Furthermore, a step 2.1) is added for the root zone file signature operation. These DNSSEC-specific actions are required when managing any DNS zone contents. A DNS resolver using this substitute DNSSEC-aware nameservice must further be configured with the appropriate trust anchor data. The substitute DNS root nameservice may be recursively extended to lower zones when this make up for missing links in the chains of DNSSEC signatures, e.g. in the case of infrastructure zones .arpa, and in-addr.arpa. The same idea applies to the .int zone as soon as a first international organization launches DNSSEC support. These three sample zones are currently managed by IANA, and are available from the Internic ftp site. The above is a duplication of DNS zone management efforts that were anticipated from IANA. If there is added value in this duplication, it lies in early adoption of DNSSEC and in the opportunity for oversight by some decentralized management. The latter is a substitution for the global oversight management expected from IANA. Maybe the global expectations are so extensive and diversified that DNSSEC support at the root by IANA is not foreseeable. 2.2 Rationale for Departure from the Single DNS Root Dogma An explanation of arguments for a single DNS root is found in informative reference [RFC2826]. An argument is the desirability of coordinated DNS root zone updates. The present proposal for DNS root nameservice substitution is limited to DNSSEC support purposes, and aims to remain fully compliant with IANA coordinated updates of the root zone contents. The last argument for a single DNS root is the practical difficulty of relocating the root nameservers in the IP address space. This is addressed in the present proposal with the recourse to the SLP (Service Location Protocol) as explained below. 2.3 Rationale for SLP Usage The present document applies SLP to the task of priming the DNSSEC configuration in resolver systems, in the scope of an administrative domain, e.g. a medium or large organization, a government, a consortium of ISPs. See appendix A for a formalization of DNSSEC root priming prior to the introduction of SLP in the picture. It should be noted that the term "domain" in the SLP applicability Moreau Experimental [page 4] Internet-Draft DNSSEC-ROOTP April, 2007 statement refers to an administrative domain, and is encoded in the "scope" field of the SLP frame format. In the present document, we disambiguate the SLP domains from DNS domains by using the phrases "administrative domain" and "DNS domain" respectively. The SLP functionality is sometimes compared to DHCP, DNS SRV records, and out-of-band configuration, for instance see informative reference [RFC3105]. For our purpose, there are, broadly speaking, two attractive aspects of SLP: . a good fit between the SLP administrative domains, and the task of DNSSEC priming for DNS root nameservice substitution, and . the SLP security features. With the use of SLP, the control of DNSSEC priming within an administrative domain, both for caching resolvers and DNSSEC- validating resolver functionality that may appear in end-user applications in the future, potentially remains in the hands of administrative domain management. This may facilitate the phasing out of DNS root nameservice substitution once DNSSEC support is offered by the IANA root. In essence, the SLP security is an optional digital signature affixed by an SLP SA (Service Agent) on its announcement of URLs for a given service, and on service attributes associated with a given service URL. This simple SLP security scheme does not provide any public signature distribution mechanism, but it may accommodate X.509 security certificates affixed to the digital signature value. The security of SLP is considered inadequate when SLP is applied to the priming of connections for block storage protocol, see informative reference [RFC3723] where IPsec is recommended as a security scheme underlying SLP. For DNSSEC priming, somehow surprisingly, we make good use of the minimalist and optional SLP security feature, i.e. a digital signature affixed to a service announcement. Actually, the surprise would not resist a deeper analysis with the realization that DNSSEC priming is a security scheme priming, and the further recourse to any full-blown security mechanism would merely push back the perils of security bootstrap. A later section of the present document explains four security models that are not strictly mutually exclusive. It is expected that an administrative domain selects a security model and then adheres to it for a 1) initial DNSSEC priming, and 2) in the case of subsection 4.4, DNSSEC root key rollover operation. The DNS resolver operators within an administrative domain refer to it with an SLP scope identifier. The SLP scope identifier thus selects a DNSSEC-enabled root nameservice. It is strongly recommended that a DNS resolver operator be offered a very small selection of scope identifiers. E.g. only "IANA", for the ICANN accredited root nameservers, and "INTERNAL", for whatever the corporate IT department selects as a DNS root nameservice Moreau Experimental [page 5] Internet-Draft DNSSEC-ROOTP April, 2007 substitution. In the case of the rollover scheme introduced in subsection 4.4, the security foundation for trust anchor key management can be common to more than one scope identifier. But this is an exception, and furthermore it is difficult to counter the operational threat of maliciously inducing a DNS resolver operator to select a rogue SLP scope identifier. 2.4 Non-Goals The present proposal attempts to be focused on a single goal, i.e. providing end-to-end DNSSEC deployment in a context where DNSSEC support at the root is not foreseeable. Accordingly, non-goals are readily identified. . The present proposal is not intended to support alternate DNS roots nameservice where DNSSEC support is not provided. The assumed value added in the case of DNSSEC deployment support (section 2.1) is absent for insecure alternate DNS nameservice. . The present proposal is not intended to assist configuration of DNSSEC trust anchors other than for the DNS root domain. Other solutions are provided in this area. Moreover, support for DNSSEC island of trust other than the root would be hard- to-justify duplication of DNS zone management effort. 3. Use of Service Location Protocol for DNSSEC Priming Document editing note: This section is in draft form. The review of the technical details for validating the concept is nearing completion to the point where the adage "the evil is in the details" has been addressed. Part of the specification refinement exercise is a template per [RFC2609] to be submitted for IANA registration. A SLP UA (User Agent) entity is co-located with the DNSSEC-aware resolver. It is expected that existing SLP SA and DA software and systems can be readily applied to the proposed use, except when the use is made of the recommended addition of algorithm RSA with SHA-1. 3.1 SLP Service Announcement with Attributes Each IPv4 or IPv6 addresses of authoritative root nameservers should be encoded in a URL, with the respective nameserver DNS domain names encoded as the later part of the url, e.g. "service:dnssec://193.0.14.129/k.root-servers.net." (the reader should not yet take this example for granted). The set of DNSSEC trust anchors for the DNSSEC root nameservice at this URL is an SLP attribute by the name "TA" containing an opaque value for SLP service selection or filtering purposes. Three SLP attributes are used to convey the type of trust anchor Moreau Experimental [page 6] Internet-Draft DNSSEC-ROOTP April, 2007 rollover support: . a presence-only attribute by the name "TIMERS" for a DNS root nameservice compliant to [TIMERS-ROLL], . a presence-only attribute by the name "TAKREM" for a DNS root nameservice compliant to [SDDA-RR] and [TAKREM-DNSSEC], and . a string attribute by the name "SLP-ROLL" for a DNS root nameservice announced an SLP SA compliant with the rollover scheme in subsection 4.4, where the attribute value is the SLP SPI (Security Parameter Index). These are not mutually exclusive. The present document specifies the addition of the algorithm selection RSA plus SHA-1 in the protocol option set in the SLP deployment, for sake of consistency with the mandatory algorithm in DNSSEC. This is reflected in the IANA considerations section. 3.2 SLP Usage Rules The SLP attribute request protocol feature is used only in its variant where an explicit service URL is provided by the SLP UA (this is required whenever an attribute signature is to be validated, so we make it a general rule). A simple SLP UA (User Agent) implementation is required. The basic DNSSEC priming service discovery uses the SLP request messages "Multicast SrvRqst" and "Unicast SrvRqst". The latter is available if the SLP DA (Directory Agent) address is known, which can be obtained via DHCP ([RFC2610]), or through the SLP service discovery itself as indicated in the SLP specification. The expected answer is a SLP response message "Unicast SrvRply" containing the service URL(s) indicated above. 4. DNSSEC Priming Operation vs Trust Anchor Key Management Unless otherwise specified herein, the DNSSEC root nameservice service discovery operation should not be triggered without operator intervention by a DNSSEC-aware resolver system. In addition, the operator should be fully aware of the SLP scope used by the SLP UA for priming the DNSSEC-aware resolver. This is recommended so that a DNSSEC root nameservice substitution has a well-known name. 4.1 Un-authenticated Priming The unauthenticated SLP service discovery may be an option for an administrative domain management, or it may be the only option available because the DNS resolver system that needs DNSSEC priming lacks the appropriate SLP SPI public key or the functionally analogue TAKREM TAK-i configuration data. In either case the security implications of un-authenticated priming should be weighted against the alternatives. Moreau Experimental [page 7] Internet-Draft DNSSEC-ROOTP April, 2007 4.2 Priming with SLP Digital Signature Validation This is a straightforward application of SLP security features. The public signature key to be used for signature must be configured in the DNS resolver prior to the priming operation. The public signature key is identified by the SLP SPI protocol field. If SLP is already deployed in the system hosting the DNS resolver, an SPI value and the corresponding public key may already be available for authenticating the DNSSEC priming. 4.3 Priming with Implied TAKREM Trust Anchor Management No SLP attribute is defined for distributing the TAKREM TAK-i configuration data to DNSSEC-aware resolver. However, if TAKREM TAK-i configuration data pre-exists in a DNSSEC- aware resolver, priming with SLP need not use the SLP security option. 4.4 Priming and Rollover with SLP Digital Signature Validation If DNSSEC priming becomes "easy" and adequately secured with the SLP security option, a spontaneous trust anchor key rollover scheme emerges: repeat the DNSSEC priming operation whenever a trust anchor key rollover is deemed required. Indeed, this is an instance of this classical security scheme: the long-term signature key periodically endorses a fresh operational key. In this instance, the rollover scheme catastrophic failure mode is a compromise of the SLP signature verification key. The rollover scheme implementation guidelines are obvious to deduce: use a larger key size for SLP than for DNSSEC, and restrict the key usage as much as possible. Inherited from the notion of SLP administrative domain, this rollover scheme is born with a flexible security authority management capability: the administrative domain that "controls" rollover may be separate from the DNS root zone operator. The SLP administrative domain may indeed migrate the DNSSEC service from a root operator to another one without DNS resolver operator involvement, e.g. upon a scheduled trust anchor rollover operation. 5. Security Considerations The DNSSEC priming operation is a security critical operation subject to "social engineering" attacks (e.g. induce the DNS resolver operator to perform priming using a bogus procedure). This is especially true when the operator is expected to select an SLP SPI identifier. In deploying the scenario of section 4.4, confidence in the overall security would be increased with no operator selection of SLP SPI identifier, i.e. if there is a single one. Moreau Experimental [page 8] Internet-Draft DNSSEC-ROOTP April, 2007 6. Internationalization Considerations No internationalization consideration has been identified at the time of writing the initial revision of the present document. It is expected that the final version will restrict the SLP usage to the English language. 7. IANA Considerations No IANA consideration arises from the SLP notion of an administrative domain, including the namespaces for SLP scope field values and SLP SPI (Security Parameter Index). In a later revision, the present document would require an allocation for a service scheme registration per [RFC2609], for reference to the DNSSEC root nameservice. Then a template per [RFC2609] would be filled. In a later revision, the present document would require a allocation for a Cryptographic BSD (Block Structure Descriptor) Codes per [RFC2608] for the digital signature specifications that is mandatory in DNSSEC, i.e. RSA with SHA-1. This is justified by the avoidance of implementation burden of the DSA digital signature scheme in the SLP UA software that would typically be embedded in DNSSEC resolver software. The whole DNSSEC deployment effort is based on RSA with SHA-1. In the DNSSEC specification, the RSA signature with MD5 is not allowed for DNS zone signing. No IANA consideration arises in relation with DNS or DNSSEC specifications. Appendix A - A Primer on DNSSEC Root Priming The present appendix contains a preliminary specification for DNSSEC root priming. Such a specification seems to lack from the DNSSEC document set. If the initial configuration of a DNS resolver can be seen as a local matter with respect to protocol standardization, it is nonetheless a significant impediment to DNSSEC deployment. Indeed, in bringing up the following specification, an operational issue came up, with a related recommendation, about DNS root zone management in the context of DNSSEC deployment. The specifications language used in the present appendix is both technical and high-level. In a later document revision, it should be complemented with more specific references to the DNSSEC protocol features. DNSSEC is about validating digital signatures for data retrieved from the DNS, e.g. authoritative A RRsets for a domain name, so that name-to-address translation is trustworthy. Moreau Experimental [page 9] Internet-Draft DNSSEC-ROOTP April, 2007 Let's refine by adaptation to the authoritative nameservers for a DNS domain name that is a DNS zone apex: DNSSEC is sometimes applied to validate the digital signatures for A and AAAA RRsets from DNS domain names that are listed in the NS RRset in the zone apex, the latter RRset deserving signature validation as well. Let's further refine to DNSSEC priming for an island of trust: when the above process for validation of authoritative nameservers is applied to an island of trust, validation of signatures stops at the KSK(s) found and self-validated in the DNSKEY RRset in the zone apex. Some or all of these KSK(s) may need to be backed by an authentication procedure outside of DNSSEC, either a priori or a posteriori. Oops, this introduces a potential corner case: the DNSSEC priming process for an island of trust may encounter a different island of trust for the authoritative nameserver addresses than for the zone apex. This suggests an original DNSSEC operational recommendation for an island of trust: if the DNS domain name of an authoritative nameserver is neither within the zone itself nor within a descendant zone for which a chain of trust exists, the zone containing the authoritative nameserver should have the same public key value as the trust anchor in its DNSKEY RRset, and the DNSKEY RRset should be signed with it. It is the signature public keys that should match, not the DNSSEC RR itself. The following refinement it then made: in the DNSSEC priming process for an island of trust, when the DNS domain name of an authoritative nameserver is within neither the zone itself nor a descendant zone for which a chain of trust exists, the DNSKEY RRset at this other zone apex deserves special validation with the same signature public key as found in at least one of the KSK(s) for the original zone. Now, we can formulate the two requirements for DNSSEC root priming: . The DNS root zone management should follow the above recommendation about signature public key. In practice for the IANA root nameservice, this would be done by adding an appropriate DNSKEY RR in the DNSKEY RRset of the DNS zone "root-servers.net.", signing the resulting RRset with the private key counterpart, and serving the DNS zone "root- servers.net." with the RRSIG RR included. . For a resolver, the DNSSEC root zone priming is the above process applied to the root zone. In summary, DNSSEC root priming starts with an IP address for a root nameserver; the end-result of DNSSEC root priming is the validated list of DNS domain names and addresses for root nameservers; this validation is trustworthy to the extent that the KSK(s) on which it relies are backed by an authentication procedure outside of DNSSEC. Moreau Experimental [page 10] Internet-Draft DNSSEC-ROOTP April, 2007 The DNSSEC root priming process should occur in the following cases: . upon installation of a DNSSEC-aware resolver entity, . on a timer expiry basis, as implied by the smallest TTL value observed in DNS RRsets relied upon in the previous instance of root priming, and . in relation with root trust anchor key rollover, whenever a change occurs in the set of trusted KSK root keys. Normative References [RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Location Protocol, Version 2", RFC2608, June 1999 [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005 [RFC4034] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005 [RFC4035] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005 [TIMERS-ROLL] M. StJohns, "Automated Updates of DNSSEC Trust Anchors", internet draft draft-ietf-dnsext-trustupdate-timers-05.txt, November 29, 2006 [SDDA-RR] T. Moreau, "The SEP DNSKEY Direct Authenticator DNS Resource Record (SDDA-RR)", work-in-progress, Internet Draft draft-moreau-dnsext-sdda-rr-02.txt, April 2006 [TAKREM-DNSSEC] T. Moreau, "The Trust Anchor Key Renewal Method Applied to DNS Security (TAKREM-DNSSEC)", work-in- progress, Internet Draft draft-moreau-dnsext-takrem-dns-02.txt, April 2006 [RFC2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, June 1999 Informative References [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", May 2000 [RFC3105] J. Kempf, G. Montenegro, "Finding an RSIP Server with SLP", RFC3105, October 2001 [RFC3723] B. Aboba, J. Tseng, J. Walker, V. Rangan, F. Travostino, "Securing Block Storage Protocols over IP", RFC3723, April 2004 Moreau Experimental [page 11] Internet-Draft DNSSEC-ROOTP April, 2007 Author's Address Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc, Canada Tel.: +1-514-385-5691 e-mail: thierry.moreau@connotech.com IPR Notices 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 ISOC's procedures with respect to rights in ISOC 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. Copyright Notice Copyright (C) The IETF Trust (2007). 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. Disclaimer 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, THE IETF TRUST 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. Moreau Experimental [page 12]