INTERNET DRAFT Thierry Moreau Document: draft-moreau-srvloc-dnssec-priming-01.txt CONNOTECH Category: Experimental May 9, 2007 Expires: November 9, 2007 DNSSEC Validation Root Priming Through SLP (DNSSEC-ROOTP) draft-moreau-srvloc-dnssec-priming-01 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 within an administrative domain. This SLP scheme directly addresses the DNS resolver configuration scaling issue. 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. Early DNSSEC support at the rot is made possible with DNSSEC root nameservice substitution, as well as later transparent migration to a unique DNSSEC root. Moreau Experimental [page 1] Internet-Draft DNSSEC-ROOTP May, 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview and Rationales for SLP Usage . . . . . . . . . . . . . . 3 3. Use of Service Location Protocol for DNSSEC Priming . . . . . . . 4 3.1 Service Announcements and Related Attributes . . . . . . . . 4 3.2 SLP Usage Rules . . . . . . . . . . . . . . . . . . . . . . 6 3.3 SLP Service Type Template . . . . . . . . . . . . . . . . . 7 4. DNSSEC Root Trust Anchor Key Management . . . . . . . . . . . . . 8 4.1 SLP Service Agent Behavior . . . . . . . . . . . . . . . . . 8 4.2 SLP User Agent Behavior . . . . . . . . . . . . . . . . . . 11 4.2.1 Initial DNSSEC Root Key Distribution . . . . . . . . . . . 12 4.2.2 DNSSEC Root Key Rollover . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Internationalization Considerations . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 8.2 Informative References . . . . . . . . . . . . . . . . . . . 15 Appendix A - A Primer on DNSSEC Root Priming . . . . . . . . . . . . 16 Appendix B - DNS Root Nameservice Substitution and Motivations . . . 17 B.1 What Is DNS Root Nameservice Substitution . . . . . . . . . 17 B.2 Added Value in DNS Root Nameservice Substitution . . . . . . 18 B.3 Departure from the Single DNS Root Dogma . . . . . . . . . . 18 B.4 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix C - Document revision history . . . . . . . . . . . . . . . 19 C.1 Changes from revision -00 to revision -01 . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 19 IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property . . . . . . . . . . . . . . . . . . . . . 20 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 20 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Moreau Experimental [page 2] Internet-Draft DNSSEC-ROOTP May, 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. The body of the present document makes the following two contributions: o it details the use of SLP to facilitate the deployment of DNSSEC in DNS resolver entities; and o it suggests related DNSSEC root trust anchor key management operations for . initial distribution of root trust anchors, and . root trust anchor rollover. The appendix A provides a suggested formalization for DNNSEC root priming. The informative appendix B discusses the opportunity to operate limited-scope DNS root authoritative nameservers for DNSSEC purposes; the intent is to bridge the gap for the period when a unique DNS root nameservice is not available with DNSSEC support. 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]. 2. Overview and Rationales 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 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: o a good fit between the SLP administrative domains, and the task of DNSSEC priming, and o the SLP security feature. Moreau Experimental [page 3] Internet-Draft DNSSEC-ROOTP May, 2007 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, rests in the hands of administrative domain management. As explained in appendix B, 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 key distribution mechanism. 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 host security bootstrap. 3. Use of Service Location Protocol for DNSSEC Priming It is fairly simple to define the usage scenario for applying SLP to the task of service announcements for DNSSEC-enabled DNS root nameservice: a SLP UA (User Agent) entity is co-located with a DNSSEC-aware resolver entity; it uses the SLP for the discovery (or confirmation) of an address of a DNS root nameserver and the required trust anchor keys; one or more SLP SA (Service Agent) entities provide the required service announcements. The scope of protocol provisions in the present document is limited to the Service Location Protocol and further limited to the service:dnssec service URL scheme defined below. It is expected that existing SLP SA and DA software and systems can be readily applied to the proposed use, except for the additional support of enhanced digital signature algorithms in SLP service announcements. The other implementation issue is the required integration of the SLP UA services in the configuration control portion of a DNS resolver implementation. Neither of these implementation issues should pose special difficulties. 3.1 Service Announcements and Related Attributes An SLP administrative domain, identified by an SLP scope value, MUST NOT announce more than a single DNSSEC root nameservice at a time, where such a root nameservice may be provided at different Moreau Experimental [page 4] Internet-Draft DNSSEC-ROOTP May, 2007 network addresses having in common a current set of trust anchor keys. In practice, transient conditions are unavoidable due to the distributed nature of SLP entities, and the single nameservice rule may not apply during these transient conditions. An SLP administrative domain SHOULD minimize the duration of such transient inconsistencies. Subject to the same transient inconsistency exception, each SLP service attributes MUST have the same value for every URL announced by an SLP administrative domain. The SLP service discovery for DNSSEC root nameservice is intended to provide the configuration data listed below to a DNS resolver entity. An SLP template ([RFC2609]) is provided in subsection 3.3 for the exact mapping of configuration data to SLP URL fields and SLP service attributes. Root Nameserver Addressing Information The network address of each authoritative root nameserver is encoded as a numeric IPv4 or IPv6 address in the announced service URL. The respective nameserver DNS domain name is encoded as the later part of the url. The abstract syntax is service: URL = "service:dnssec://" hostnumber "/" domain-name hostnumber = ipv4-number / ipv6-addr ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) ipv6-addr = "[" num-addr "]" num-addr = ; Text represented IPv6 address syntax is as ; specified in [RFC4291], Section 2.2, domain-name = ; The domain-name URL part is the absolute ; domain name of the DNS root nameserver. See ; section 5.1 in [RFC1035] for the character ; representation of domain-name. An example is "service:dnssec://193.0.14.129/k.root-servers.net.". DNS Root Trust Anchors The set of DNSSEC trust anchors for the DNSSEC root nameservice at this URL is a mandatory SLP attribute by the name "ta" containing an opaque value for SLP service selection or filtering purposes. See the subsection 3.3 template for specifics. See also the work-in-progress informative reference [TAS-ARE-DS]. Trust Anchor Rollover Support Announcements Two optional SLP attributes are used to convey the type of trust anchor rollover support: o a presence-only attribute by the name "timers" for a DNS root nameservice compliant to work-in-progress reference [TIMERS-ROLL], and Moreau Experimental [page 5] Internet-Draft DNSSEC-ROOTP May, 2007 o a string attribute by the name "slp-roll" for a DNS root nameservice announced an SLP SA compliant with the trust anchor management scheme in subsection 4.1, where the attribute value is the SLP SPI (Security Parameter Index). These are not mutually exclusive. See the subsection 3.3 template for specifics. Note: vendor defined attributes (defined in [RFC3224]) may be used to convey other DNS root nameservice characteristics that are needed in the priming context. The SLP SA entity MUST set the FRESH flag in its SAAdvert messages for the service:dnssec. 3.2 SLP Usage Rules For DNSSEC root nameservice discovery, an SLP UA SHOULD accept any single service URL for the service:dnssec when it receives the service URL with a level of confidence satisfying local policy. A possible local policy is compliance with subsection 4.2, in which case the SLP UA entity will require out-of-band trusted configuration of a digital signature public key. Also dependent on local policy, the SLP UA entity MAY use the contents of the "ta" service attribute as a source of trusted configuration for the DNNSEC-aware resolver entity. Again, a possible local policy is compliance with subsection 4.2. The SLP UA entity SHOULD NOT send SLP attribute request messages without a full URL or with a non-empty list of attribute tags (this is mandatory in [RFC2608] whenever an attribute signature is to be validated). Once a service URL is known for the DNSSEC root nameservice, the DNSSEC-aware resolver entity SHOULD perform the priming queries in the DNS system in order to learn the complete set of network addresses for primary and secondary root nameservers. Implementation-wise, 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. When the "ta" service attribute is of interest, the SLP UA must issue an "AttrRqst" message and expect an "AttrRply" response. In the case of compliance with subsection 4.2, digital signatures must be validated for SLP response authentication. Moreau Experimental [page 6] Internet-Draft DNSSEC-ROOTP May, 2007 3.3 SLP Service Type Template Name of submitter: Thierry Moreau, CONNOTECH Language of service template: English Security Considerations: See this document section 5. Template Text: ----------------------template begins here----------------------- template-type=dnssec template-version=0.0 template-description= A concrete service type associated with DNSSEC root nameservice discovery, where SLPv2 UAs are assisting DNSSEC-aware DNS resolver entities in locating the DNSSEC-aware root nameservice. template-url-syntax= url-path = "/" domain-name domain-name = ; The domain-name URL part is the absolute domain ; name of the DNS root nameserver. See section 5.1 ; in [RFC1035] for the character representation of ; domain-name. ta=opaque M L # The list of DNS root trust anchor keys. Each opaque value is the # DNS wire encoding of the DS RDATA field (including a key tag, a # protocol indication, a digest type, and a digest value per # [RFC4034] or [RFC4509]) that would be prepared for a DNSKEY RR # present in the DNSKEY RRset at the root zone apex in the DNS root # nameservice. timers=keyword # When present in a service registration, the DNS root nameservice # supports the trust anchor rollover specified in # work-in-progress reference [TIMERS-ROLL]. slp-roll=string O L # When present in a service registration, the SLPv2 SA entity # supports the DNS root trust anchor key rollover method specified # in this document subsection 4.2. The string value is the SLP SPI # string, and MUST NOT be empty if present, thus making a signed # slp-roll attribute a self-referencing signature for this SPI # value. -----------------------template ends here------------------------ Moreau Experimental [page 7] Internet-Draft DNSSEC-ROOTP May, 2007 4. DNSSEC Root Trust Anchor Key Management This section specifies the use of the SLPv2 security feature for the purpose of DNSSEC root trust anchor key management. This scheme is based on a long-term single digital signature key pair, hopefully handled by a managing organization that can and does monitor the DNSSEC-aware DNS root nameservice advertized through SLP. This monitoring should be focused on the set of DNSKEY resource records in the DNS root zone file, and more specifically to the DNSKEY resource records that qualify as a "DNS rot trust anchor key" for inclusion in the "ta" service attribute. However, this section focuses on interoperability provisions, generally leaving operational guidelines as out of scope. Furthermore, no attempt is made to define the semantic of a digital signature in this usage scenario. Formally, the present document section contains provisions for DNSSEC root trust anchor key management using the SLP version 2 security capabilities. Compliance to this section is OPTIONAL, and indicated by the presence of an "slp-roll" attribute in service advertizement in the case of an SLP SA entity; but if it is used in a DNSSEC deployment environment the imperative [RFC2119] key words ("MUST", "MUST NOT", "REQUIRED", "SHALL", and "SHALL NOT") are to be obeyed by an SLP SA entity (subsection 4.1) or an SLP UA entity associated with a DNSSEC-aware resolver entity (subsection 4.2). 4.1 SLP Service Agent Behavior The present subsection specifies mandatory and recommended SLP SA behavior provisions applicable when the service advertizement includes the service attribute "slp-roll". These provisions are intended primarily to provide cryptographic assurance for the service attribute "ta", using the SLPv2 authentication block mechanism. Note: The SLPv2 security scheme has been criticized for its lack of key management facilities. In a broader view of host security bootstrapping, DNSSEC may be envisioned as a public key distribution mechanism for other security protocols, and DNSSEC would thus need bootstrapping without recourse to any of these other security protocols. In this broader perspective, the SLPv2 security scheme is a good fit for bootstrapping purposes. When an SLP SA entity includes the "slp-roll" service attribute in its service advertizement, it MUST include authentication blocks using the indicated SPI string in its SLP messages according to the following rules: o in any service registration message, both for URL authentication and attribute authentication, sent to an SLP DA entity from which a directory agent advertizement message has been received indicating support for the SLP SPI value, o in any service agent advertizement message, unless sent as a Moreau Experimental [page 8] Internet-Draft DNSSEC-ROOTP May, 2007 response to a service request message with an SLP SPI string other than the one in the "slp-roll" service attribute, and o in any attribute reply message according to the rules of [RFC2608]. Note that off-line signature preparation should anticipate the attribute reply messages for the SA entity itself (the URL returned by a service request for "service:service-agent"), and the two variants of the SA advertizement message, i.e. with or without an attribute list. For the SLP SPI value found in the service attribute "slp-roll", the SLP SA entity MUST use a digital signature algorithm having a claimed cryptographic strength greater than the current (i.e. first quarter 2007) assessment of SHA-1. To comply to this requirement, the SLP SA entity SHOULD set the BSD field to 1 in the authentication block of its messages, with an ASN.1 OID in an AlgorithmIdentifier value that selects the RSASSA-PSS signature scheme, for which the OID usage is specified in [RFC4055], and where the AlgorithmIdentifier value SHOULD select a hashAlgorithm OID for either id-sha256, id-sha384, or id-sha512. Note: This is both a security provision, and an implied mandatory interoperability provision, i.e. the mandatory support for digital signature algorithm selection other than the SLPv2 default BSD=2. The recommended algorithm selection is based on an OID value found in AlgorithmIdentifier value. See IANA considerations in section 7. When the SLP SA entity transmits an authentication block with the BSD field set to 1, the structured authentication block SHALL include two ASN.1 BER encoded strings, respectively holding an AlgorithmIdentifier value and the ASN.1 BER encoding of a digital signature value in an ASN.1 bit string encoding, where the OID value found in the AlgorithmIdentifier value selects the signature encoding rules. The ASN.1 AlgorithmIdentifier structure has been imported from X.509 specifications to Internet RFCs in [RFC2459]. For the SLP SPI value found in the service attribute "slp-roll", the organization managing the SLP SA entity SHOULD detect changes in the set of trust anchor keys in use by the DNSSEC-enabled DNS root nameservice advertized by the SLP SA, and update accordingly, and on a timely manner, its service advertizement. Obviously, this recommendation applies upon initialization of SLP SA services, and upon a change in DNSSEC nameservice as MAY be decided by the organization managing the SLP SA entity. The managing organization should fill the authentication block timestamp field to reflect its understanding of the validity period for the set of trust anchor keys in use by the DNSSEC-enabled DNS root nameservice. The SLP SA entity SHALL NOT issue authentication block timestamp values in the past. Hence, a timestamp value before the detailed design of the service:dnssec scheme (Aril-May 2007) Moreau Experimental [page 9] Internet-Draft DNSSEC-ROOTP May, 2007 will never be used to represent absolute times before the first use of service:dnssec, hence postponing the epoch rollover more than 37 years if modulo arithmetic is used for timestamp verification. In this context, the managing organization should handle security breach events, or suspected ones. o If the managing organization sees a need to advertize an emergency rollover of one or more DNS root trust anchor key(s), it SHOULD advertize a "ta" service attribute with the new set of valid DNS root trust anchor key(s) in use by the DNSSEC-enabled DNS root nameservice. o If the managing organization sees a need to advertize a complete revocation of every trust anchor keys, it SHOULD advertize a "ta" service attribute with a single trust anchor key that is unrelated to any DNSKEY present in the root zone apex in the DNSSEC-enabled DNS root nameservice. o If the managing organization experiences a security breach of the private signature key indicated by the SLP SPI indicated in the "slp-roll" service attribute, it SHOULD advertize the service either without the "slp-roll" attribute or with an "slp-roll" attribute with a different SLP SPI string value. Note: The last two security breaches are hard-to-recover, system-wide serious cryptographic failures. Usually, operational guidelines and protocol provisions do not cover these cases. In contrast, the above recommendations make the failure mode more explicit, allowing more predictable handling of these failures in DNSSEC-aware resolver implementations. Some SLP usage recommendations are useful to limit the number of times when, or the number of systems for which, a digital signature operation is needed with the private key counterpart of the digital public signature key. o The SLP SPI string SHOULD NOT be used by any SLP SA entity other than the ones advertizing the "service:dnssec"; this avoids signature operations unrelated to DNSSEC priming facilitation. o The SLP SA entity SHOULD NOT include any service other than "service:dnssec" in its service-type attribute; this avoids signature operations for SAAdvert messages (and for attribute reply messages for the SA entity itself, i.e. the URL returned by a service request for "service:service-agent") when other services are added or removed from the list of supported services. o The SLP SA entity SHOULD attempt to minimize the data turnover for the list of SLP scope values it supports; this avoids signature operations for SAAdvert messages when SLP scopes are added or removed from the list. o The SLP SPI string SHOULD NOT be used by any SLP DA entity as its first SLP SPI in any DAAdvert message authentication bock; this avoids signature operations for DAAdvert messages. Moreau Experimental [page 10] Internet-Draft DNSSEC-ROOTP May, 2007 4.2 SLP User Agent Behavior The previous subsection 4.1 specifies a disciplined use of SLPv2 authentication blocks for the purpose of authenticating the DNSSEC root trust anchor keys. The relying parties are SLP UA entities associated with a DNSSEC-aware DNS resolver entity. These SLP UA entities must be configured with the key material referenced by the SLP SPI value found in the service attribute "slp-roll". Such SLP UA configuration is deemed to occur out-of-band and is outside the scope of the present specification. It is nonetheless a requirement for the effectiveness of the present security scheme. Generally, the SLP UA behavior should follow the SLP rules, and the rules of subsection 3.2, for to locate an URL for the DNSSEC root nameservice and to acquire the current set of DNSSEC root trust anchors. In recapitulation, the following principles are involved: a) the SLP provides the basic service discovery functionality to the DNS resolver entity through the associated SLP UA entity and the service:dnssec service URL, b) the SLP authentication block mechanism provides standards- based integration of simple digital signature for service advertizement authentication, c) the provisions of this document section 4 support the special security requirements of DNSSEC root nameservice priming application, and d) the trusted managing organization for the service:dnssec advertizement is independent from the DNSSEC root nameservice organization. Whenever an SLP UA entity completes a service request operation for the service:dnssec, it SHOULD immediately attempt an attribute request for one of the advertized URL. From a security perspective, a single mandatory provision codifies the ultimate goal of the whole procedure, i.e. to maintain confidence in the current local set of trust anchors. Here is this security requirement: For DNSSEC root trust anchor key management purposes, the SLP SA entity SHALL trust the timestamp and list of trust anchor keys ("ta" service attribute) from the most recently received valid SLP attribute reply message having an "slp-roll" service attribute matching a locally configured trusted public key. The present security scheme is expected to provide end-to-end security, and thus be independent of intermediate host systems, notably SLP DA (directory Agents). Hence, the SLP UA entity SHOULD NOT rely on any SLP DA entity for the purpose of validating SLP authentication blocks. Moreau Experimental [page 11] Internet-Draft DNSSEC-ROOTP May, 2007 4.2.1 Initial DNSSEC Root Key Distribution The present scheme offers integral support for the initial distribution of DNSSEC root trust anchor keys to DNS resolver entities, i.e. trust anchor key configuration is established through a DNSSEC priming assisted with SLP according to the present document. Furthermore, the DNSSEC root nameservice can be migrated from a service provider to another one, as part of a regular DNSSEC priming operation for an update of the DNS resolver trusted configuration. This graceful migration support is made possible because no element of procedure applies differently to the initial distribution of trust anchors than to the trust anchor rollover operation described in the following subsection 4.2.2. 4.2.2 DNSSEC Root Key Rollover 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 the following classical security model: a long-term signature key periodically endorses a shorter-term operational key. Accordingly, 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. Such a rollover security model justifies some of the provisions of subsection 4.1. Given the above explanation, the remaining necessary protocol provisions relate to the triggering conditions, including timeout expiry, for a DNSSEC priming operation assisted with SLP. The DNSSEC root priming process should occur, starting with the SLP service discovery operation, in the following cases: o upon installation of a DNSSEC-aware resolver entity, o whenever the DNS resolver entity sees an updated DNSKEY RRset at the root either with a removed trust anchor key, or with an additional DNSKEY RR that is used to sign the DNSKEY RRset, o at the timestamp expiry for the most recently received valid SLP attribute message (i.e. signature expiry for the "ta" service attribute), o when the SLP UA entity performs a service request and an attribute request due to SLP URL entry lifetime expiry, if either any new URL is advertized (i.e. it is not in the current DNS configuration) or the "ta" service attribute changes from its previous value, and o upon a manual request from an operator. Moreau Experimental [page 12] Internet-Draft DNSSEC-ROOTP May, 2007 5. Security Considerations The DNSSEC priming operation is a security critical operation subject to "social engineering" attacks, e.g. by inducing the DNS resolver operator to perform priming using a bogus procedure. Within an administrative domain, if the intended policy is to rely on the scheme of section 4, the threat of social engineering attacks may be mitigated by offering no other option for DNSSEC priming to DNS resolver entity managers and users. The DNSSEC trust anchor key management scheme of section 4 is based on a single long-term digital signature public key. While this makes the implementation simpler, and the security deployment more self-evident, this signature key pair is a single point of failure. In the absence of the required trusted public key configuration for the scheme of section 4, the DNSSEC priming operation assisted with SLP is vulnerable to integrity attacks, e.g. from a rogue SLP DA entity. This issue is handled either with a leap of faith approach, which leaves the vulnerabilities unaddressed, or with reliance on another security scheme, e.g. IPSEC or TAKREM (work-in-progress informative references [SDDA-RR] and [TAKREM-DNSSEC]), which inescapably requires some form of security bootstrapping. 6. Internationalization Considerations No internationalization consideration has been identified at the time of writing the current revision of the present document. It is expected that the final version will restrict the SLP usage to the English language. 7. IANA Considerations The present document requires a service scheme registration per [RFC2609], for reference to the service URL "service:dnssec". The template in subsection 3.3 fulfills the registration requirements. No IANA consideration arises from the use, in subsection 4.1, of the code point BSD=1 as a cryptographic BSD (Block Structure Descriptor) code per [RFC2165] and [RFC2608]. The BSD=1 code value allows an ASN.1 OID in an AlgorithmIdentifier to select a standards-based digital signature algorithm in an SLP authentication block. Although this BSD=1 code point is often described as the single scheme RSASSA-PKCS1-v1_5 with MD5 in the deprecated SLPv1 usage context, this designation is misleading since it is only a special case of the BSD=1 code value in the version 1 of the service location protocol and with the AlgorithmIdentifier encoded value literally specified in the SLPv1 document [RFC2165]. Actually, irrespective of the SLP version, the BSD=1 code point introduces an SLP structured authentication block made of a first Moreau Experimental [page 13] Internet-Draft DNSSEC-ROOTP May, 2007 ASN.1 BER encoding holding an AlgorithmIdentifier value e.g. chosen among [RFC3279] or [RFC4055], followed by a second ASN.1 BER encoding of a digital signature value in an ASN.1 bit string encoding (since [RFC3280] mandates the use of an ASN.1 bit string encoding for a digital signature value, each standardized algorithm specifies the necessary conversion). 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). No IANA consideration arises in relation with DNS or DNSSEC specifications. 8. References 8.1 Normative References [RFC1035] P. Mockapetris, "Domain Names - Implementation and Specification", rfc1035, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2165] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, "Service Location Protocol", RFC2165, June 1997 [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC2459, January 1999 [RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Location Protocol, Version 2", RFC2608, June 1999 [RFC2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC2609, June 1999 [RFC2610] C. Perkins, E. Guttman, "DHCP Options for Service Location Protocol", RFC2610, June 1999 [RFC3111] E. Guttman, "Service Location Protocol Modifications for IPv6", RFC3111, May 2001 [RFC3224] E. Guttman, "Vendor Extensions for Service Location Protocol, Version 2", RFC3224, January 2002 [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 Moreau Experimental [page 14] Internet-Draft DNSSEC-ROOTP May, 2007 [RFC4035] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005 [RFC4055] J. Schaad, B. Kaliski, R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC4055, June 2005 [RFC4291] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC4291, February 2006 [RFC4509] W. Hardaker, "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC4509, May 2006 [TIMERS-ROLL] M. StJohns, "Automated Updates of DNSSEC Trust Anchors", internet draft draft-ietf-dnsext-trustupdate-timers-05.txt, November 29, 2006 [PRIMING] P. Koch, "Initializing a DNS Resolver with Priming Queries", work-in-progress, Internet draft draft-koch-dnsop-resolver-priming-00, February 26, 2007 8.2 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 [RFC3279] W. Polk, R. Housley, L. Bassham, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC3279, April 2002 [RFC3280] R. Housley, W. Polk, W. Ford, D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC3280, April 2002 [RFC3723] B. Aboba, J. Tseng, J. Walker, V. Rangan, F. Travostino, "Securing Block Storage Protocols over IP", RFC3723, April 2004 [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 Moreau Experimental [page 15] Internet-Draft DNSSEC-ROOTP May, 2007 [TAS-ARE-DS] M. Larson, O. Gudmundsson, "DNSSEC Trust Anchor Configuration and Maintenance", work-in-progress, Internet draft draft-larson-dnsop-trust-anchor-01, February 2007 Appendix A - A Primer on DNSSEC Root Priming The present appendix contains a very preliminary specification for DNSSEC root priming. If the work-in-progress reference [PRIMING] is advanced to RFC publication prior to the resent Internet draft, the contents of the latter should take precedence, to the extent it creates no serious incompatibilities with the body of the present document. The present appendix provides a technical narration for DNSSEC root priming, and while doing so it comes up with a root operational recommendation and a special validating resolver logic for root priming. The 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. 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. 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. 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. We suggest the following DNSSEC operational recommendation for the DNS root: if the DNS domain name of an authoritative root nameserver is neither within the root zone itself nor within a zone for which a chain of trust to the root exists, the zone containing Moreau Experimental [page 16] Internet-Draft DNSSEC-ROOTP May, 2007 the authoritative nameserver should have a public key value in its DNSKEY RRset that is also present in the root DNSKEY RRset, and the authoritative root nameservers' A and/or AAAA RRset(s) should be signed with it. It is the signature public keys that should match, not necessarily the DNSSEC RR itself. The following refinement is then made on the resolver side: in the DNSSEC priming process for the DNS root, when the DNS domain name of an authoritative root nameserver is within a zone for which there is no chain of trust to the root, the authoritative root nameservers' A and/or AAAA RRset(s) may nonetheless be validated with a signature public key found in the DNS root DNSKEY RRset. 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. A special zone publication procedure, and a modified validator procedure for DNSSEC priming, are suggested to care for the possible lack of a chain of trust for DNS data specific to the authoritative root nameservers. Appendix B - DNS Root Nameservice Substitution and Motivations This appendix is informative. B.1 What Is DNS Root Nameservice Substitution 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 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. Moreau Experimental [page 17] Internet-Draft DNSSEC-ROOTP May, 2007 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. B.2 Added Value in DNS Root Nameservice Substitution 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. B.3 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). B.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. o 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 (this appendix B section B.2) is absent for insecure alternate DNS nameservice. o 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. Moreau Experimental [page 18] Internet-Draft DNSSEC-ROOTP May, 2007 Appendix C - Document revision history [Editor's note: this appendix to be removed upon publication as an Internet RFC] C.1 Changes from revision -00 to revision -01 Major document reorganization, focusing on putting specific protocol standardization provisions up-front and relegating rationales and usage scenarios in an appendix, including: o moved coverage of DNS root nameservice substitution to informative appendix B; o made a separate section (i.e. section 4) for the single trust anchor rollover scheme added by the present document; o removed explanations about relationships with TA rollover methods and TAKREM; and o added reference [PRIMING] as a concurrent draft for the same subject area as Appendix A. Changes in technical contents: o different approach to selection of a stronger digital signature algorithm: re-use of BSD code point already allocated in SLPv1 and recommendation for RSASSA-PSS cipher suite; o in looking at the SLP detailed specifications, the SLP scope field was found unrelated to SLP authentication blocks for service URL and attribute advertizement, and was thus almost completely omitted from the specifications; o made an intentional design limitation with a single SLP SPI value allowed in the "slp-roll" service attribute; o in Appendix A, refined the recommendation for handling authentication of A and AAAA RRsets for authoritative root nameservers. 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 Moreau Experimental [page 19] Internet-Draft DNSSEC-ROOTP May, 2007 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 20]