Network Working Group M. StJohns Internet-Draft Nominum, Inc. Intended status: Standards Track October 16, 2006 Expires: April 19, 2007 Signature-Only DNSSEC: A Simplified Approach draft-stjohns-dnssec-sigonly-00 Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Work on the DNS Security Extensions (DNSSEC)( [RFC4033] et al) has been in progress for close to 15 years and DNSSEC is still not "mature" enough to be considered complete. A substantial issue is the complexity of the system. This document describes a simplified version of DNSSEC that can co-exist with the current protocols, but with characteristics such that the author believes it can be implemented and deployed with much less effort. StJohns Expires April 19, 2007 [Page 1] Internet-Draft signature-only-dnssec October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Back Story . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Design Implications for Provable Non-Existence . . . . . . 4 1.3. Theory of Operation - Signature-Only DNSSEC . . . . . . . 6 2. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 2.1. Differences from PNE Base . . . . . . . . . . . . . . . . 7 2.2. New Record Types . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Off-Tree Signature (OSIG) Record . . . . . . . . . . . 7 2.2.2. Delegation Signer - Signature-only (DSSO) Record . . . 12 2.3. Differences from PNE Protocol . . . . . . . . . . . . . . 15 2.3.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . 15 2.3.2. Serving . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.3. Resolving . . . . . . . . . . . . . . . . . . . . . . 17 2.3.4. Authenticating DNS Data . . . . . . . . . . . . . . . 18 2.4. Off-tree Signature Hint . . . . . . . . . . . . . . . . . 18 2.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 19 2.6. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Normative References . . . . . . . . . . . . . . . . . . . 20 5.2. Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 StJohns Expires April 19, 2007 [Page 2] Internet-Draft signature-only-dnssec October 2006 1. Introduction Author's Note: Most of the introductory material is a description of the "why" of this Internet Draft. The author expects that it will be removed after a few rounds of ID review, or at least relegated to a non-standards track RFC as informational material. Acknowledgement: In various locations, especially within the description of new RR types, the author has extracted and used text verbatim from the existing set of DNSSEC documents. 1.1. The Back Story One of the original design constraints for DNSSEC was that it be possible to deploy DNSSEC without requiring changes to all of the end resolvers. In other words, the intermediate recursive resolver needed to be able to proxy DNSSEC resolution and validation for the end system. The current model for proxy DNSSEC passes or drops DNS responses to the end resolver based on validation status and some notion of whether or not the data should have been signed. Intermediate validation seems like a reasonable idea, especially as it means that not all end-systems need to understand DNSSEC for them to benefit from DNSSEC. But, is it possible to do useful policy enforcement at an intermediate resolver without understanding to what use an end-system will put any given DNS answer? We've learned in the last few years that a synthesized DNS answer which might be appropriate for one application such as a web browser may not be appropriate as a response to different application such as an SSH client asking the same question. Relating that principle to DNSSEC suggests that trying to decide whether or not to pass data from an intermediate resolver to an end or stub resolver based on DNSSEC status may actually be harmful. There's a simple example of this: You may want to prevent end users from connecting to a web site where the DNS data isn't validated. You may want to allow those self-same users to connect to an SSH daemon on the same server (and at the same name) (or for that matter using "https") regardless of DNS validation because of the alternate validation mechanism. The intermediate validating resolver doesn't have enough information to decide whether or not it should pass an answer to the stub resolver. To provide meaningful policy enforcement based on DNSSEC status requires the intermediate resolver also be told "why" (i.e. for what application) the DNS question is being asked - and that's not currently part of the DNS or DNSSEC protocols. If we limit where DNSSEC validation is done to the resolver on the end-system, the application requesting a secure DNS answer can make a decision of whether to proceed or not based on its own validation StJohns Expires April 19, 2007 [Page 3] Internet-Draft signature-only-dnssec October 2006 requirements. In each case this author has considered, an application will only care about whether or not it can validate the DNS retrieved data. If the application can validate the data, it can take a "secure" action. If it can't validate the data, for ANY reason, it will generally take the "unsecure" action - however "secure" and "unsecure" are defined for that application. The application will generally NOT care about the reasons why an answer was not validated in making its "secure" vs "unsecure" choices. If this really is the case, it follows that a validation system with this set of outputs may be sufficient for most needs. It is possible that a system or network administrator may care why a particular response failed validation. It's unclear from 14 years of discussion how often this will be the case. The author believes it's probable that the cost of providing such capabilities may outweigh any benefit that DNSSEC could otherwise provide. 1.2. Design Implications for Provable Non-Existence A side effect of the design constraint which required validation support at the intermediate resolver was a requirement to be able to prove a particular piece of data didn't exist. Specifically, that a secure delegation did or didn't exist. We'll call this "Provable Non-Existence" (PNE) (aka "authenticated denial of existence"). PNE is also useful in dealing with Wildcards and determining when to stop trying to validate, but these appear to be a "nice to have" requirements rather than absolutes. A PNE-capable DNSSEC has 4 outputs from the validation algorithm for any given piece of data in the DNSSEC tree: Unknown There is no superior or enclosing trust anchor for the queried name so there is no way of knowing whether or not the data should be or is signed. Secure There is a superior trust anchor AND we were able to validate the complete chain of trust for the data. (Note: there is a sub- state - "Secure but out of policy" for things that can be cryptographically validated, but might not be acceptable due to expiration times, etc). Unsecure There is a superior trust anchor, and a secure delegation to an unsecure zone (e.g. PNE of a DS record to that zone). Bogus There is a superior trust anchor and we were not able to validate the complete chain of trust for one reason or another. E.g. we expect the data to be signed and validated, but for some reason that expectation wasn't met. [Note: The above differs slightly from the 4 validation outputs described in [RFC4033], but the author believes the above more correctly describes the actual provable security output state.] StJohns Expires April 19, 2007 [Page 4] Internet-Draft signature-only-dnssec October 2006 The general policy of a PNE-capable intermediate resolver is to block Bogus DNS data, but to pass all other data. The author would expect that most implementations of a PNE resolver would have some additional policy knobs (e.g. allow all data from .MIL, allow all data to a specific machine, allow all MX records - all regardless of validation), but that's not described in any of the DNSSEC documents nor otherwise required. End-users will encounter large variances in PNE intermediate resolver capabilities. The requirement to implement PNE capabilities was solved by figuring out how to sign the empty spaces in the DNS tree. That is the purpose of the NXT, NSEC and eventually, the NSEC3 records. Side effects of the requirements for PNE: o There is no ability to do off-tree signatures. Each DNSSEC- validatable piece of data requires a trust anchor with a name equal or superior to the name on the data. [Note: DNSSEC Look- Aside Validation (DLV) [RFC4431] is an attempt to provide limited off-tree capabilities, but it has a number of characteristics, especially scalability, that the author believes make it problematic to use.] Without an easy and scalable way of doing off-tree signatures, DNSSEC will require substantial parts of the top of the DNS tree to be signed to be useful. Few lower level domains will be signed if their parents aren't already signed. This in turn inhibits deployment of DNSSEC and may be the greatest argument for finding another approach. o We've had to develop increasingly complex and expensive ways of signing the blank space to mitigate side effects of the first attempts (e.g. zone walking). One recent email published about NSEC3 suggested that calculating the NSEC3 hash was going to be more expensive than validating the signature over the NSEC3. Another set of emails are debating how to deal with mixes of hash algorithms. o There is a "requirement" (or at least a strong bias) which keeps a signing key online to deal with DNS dynamic updates of signed data. The issue here is that creation and deletion of data within a signed zone may also require creation, deletion or updating of NSEC or NSEC3 records which aren't under the name being created, deleted or modified. That limits the amount of protection that can be applied to any given private key in a dynamic zone. o There are some fairly arcane rules for the contents of the zones and what gets signed by which keys - all designed to prevent downgrade attacks. This is problematic as the rules for which keys and algorithms have to sign which data may require human intervention for proper behavior. In general, trusting a human to behave properly as a protocol element tends to be a no-win situation. StJohns Expires April 19, 2007 [Page 5] Internet-Draft signature-only-dnssec October 2006 o Zones must be signed on an "all or nothing" basis. It's impossible to sign just a portion of the data in the zone. 1.3. Theory of Operation - Signature-Only DNSSEC Signature-Only DNSSEC (SO) is based on the idea that all an end- application cares about is whether or not the data it receives can be cryptographically verified. Morphing PNE DNSSEC into SO DNSSEC is mostly a matter of cutting away extraneous material - specifically NSEC/NSEC3 records and validation at intermediate resolvers. The verification procedure for SO is similar to that for PNE. Basically, the data is part of an RRSet that can be cryptographically verified as being signed by a specific DNSKEY. That DNSKEY is either a trust anchor, is signed by a trust anchor, or chains upwards via the DS, DSSO (see Section 2.2.2) or OSIG (see Section 2.2.1) records to one or more superior zones and DNSKEYs. A valid chain ultimately ends at a DNSKEY RRSet signed by a known trust anchor (or, if the off-tree certificate technique is adopted, at a digital certificate). An SO-capable DNSSEC validator has only 2 outputs: Validated The data in question was signed, the signatures could be validated, and a chain of signatures could be traced back to a known trust anchor. Unvalidated It was impossible to validate the data in question for any of a number of reasons: missing signatures, invalid signatures, broken chain of trust, etc. An SO validator can fail to verify an RRSet if it finds a bad signature, can't retrieve an RRSIG, can't find a DNSKEY pointed to by an RRSIG, doesn't understand an indicated signature algorithm, can't find a DS or DSSO at a delegation point or for other reasons - some transitory and some permanent. There are some additional considerations with respect to signatures. A signature is considered valid by the resolver if and only if the resolver has configured that signature algorithm as being acceptable (e.g. "strong enough"). An SO DNSSEC has no concept of a "downgrade attack" - if the resolver believes a signature algorithm is sufficient it can use it as a link in the chain. See below for a more complete discussion of the validation process. 2. Protocol Description StJohns Expires April 19, 2007 [Page 6] Internet-Draft signature-only-dnssec October 2006 2.1. Differences from PNE Base SO uses the same formats for DNSKEY, DS and RRSIG Records and the same mechanisms for forming the contents of the records, especially the signature portion of the RRSIG record. SO has two additional record types (described below) - the DSSO record - which provides a mechanism for doing a secure delegation into a Signature-Only DNSSEC zone, and the OSIG record which provides a mechanism for off-tree signatures. SO differs from [RFC4033] in a number of ways. First, SO provides only data origin authentication and data integrity and does not provide for authenticated denial of existence (section 3.2 of [RFC4033] is not applicable). Second, SO has only two output states - validated (i.e. secure) and unvalidated (section 5 is not applicable). Third, SO has no role for intermediate resolvers in the validation process (section 6 is not applicable - see below for specific intermediate resolver considerations). Fourth, the end resolver (stub or otherwise) does its own validation (section 7 is applicable only with respect to the end resolver setting the CD bit). There may be other differences from [RFC4033] described either implicitly or explicitly later in this document. SO is compliant with [RFC4034] with the exception that NSEC records are neither generated during the signature process nor used during the validation process. NSEC (and NSEC3 if/when) records are considered extraneous information and ignored. 2.2. New Record Types 2.2.1. Off-Tree Signature (OSIG) Record This record is used to provide a signature on a single DNSKEY record located within an apex DNSKEY RRSet by a key (DNSKEY or other method) located elsewhere. Logically, it is the combination of a DNSKEY RRSet with one DNSKEY and an RRSIG over that RRSet. The type number for the OSIG record is TBD. The OSIG record is class independent. The OSIG record has no special TTL requirements. The TTL is independent of the Signature Inception and Expiration values. Design Note: This record allows the creation of a signature over a single DNSKEY, rather than the RRSIG approach which signs an entire RRSet. This permits the zone owner to modify the set of DNSKEYs (except for the OSIG-signed DNSKEY) in the RRSet without requiring StJohns Expires April 19, 2007 [Page 7] Internet-Draft signature-only-dnssec October 2006 the external entity to sign each change. 2.2.1.1. OSIG RDATA Wire Format The RDATA for an OSIG RR consists of a 2 octet Key Tag field, a 1 octet Signature Algorithm field, a 1 octet Name Type field, a 4 octet Signature Inception field, a 4 octet Signature Expiration field, a 2 octet Signer Key Tag, the Signer Name field and the Signature. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signed Key Tag | Sig Algorithm | Name Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Inception | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signer Key Tag | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / Signer Name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2.1.1.1. The Signed Key Tag Field The Signed Key Tag field identifies the single DNSKEY at the ownername of this OSIG record to which this signature applies. 2.2.1.1.2. The Signature Algorithm Field The Signature Algorithm field identifies the cryptographic algorithm used to create the signature. This is a standard DNSSEC algorithm identifier. 2.2.1.1.3. The Name Type Field The Name Type field is used to indicate which type of key material was used to form the signature. The acceptable values are: StJohns Expires April 19, 2007 [Page 8] Internet-Draft signature-only-dnssec October 2006 0 Reserved 1 DNSKEY. The public key used to form the signature is located in a DNSKEY record in the DNS tree at the point indicated by the Signer Name field and with the tag equal to the Signer Key Tag field. 2 Certificate Hash. The public key used to form the signature is contained in a public key certificate. The Signer Name field contains the least significant 60 bits of the SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bit string bits) expressed as an upper-case encoded hex string encoded as a single component domain name. E.g. "AB55623FC1A73C21." This is the same method used to create one form of a SubjectKeyIdentifier extension in an X509 certificate - see section 4.2.1.2 of [RFC3280]. The Signer Key Tag field is ignored and should be 0. 3-254 Unassigned 255 Reserved 2.2.1.1.4. The Signature Inception and Expiration Fields The Signature Expiration and Inception fields specify a validity period for the signature. The OSIG record MUST NOT be used for authentication prior to the inception date and MUST NOT be used for authentication after the expiration date. The Signature Expiration and Inception field values specify a date and time in the form of a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The longest interval that can be expressed by this format without wrapping is approximately 136 years. An OSIG RR can have an Expiration field value that is numerically smaller than the Inception field value if the expiration field value is near the 32- bit wrap-around point or if the signature is long lived. Because of this, all comparisons involving these fields MUST use "Serial number arithmetic", as defined in [RFC1982]. As a direct consequence, the values contained in these fields cannot refer to dates more than 68 years in either the past or the future. 2.2.1.1.5. Signer Key Tag Field If the Name Type is 1 (DNSKEY), the Signer Key Tag field identifies the DNSKEY at the Signer Name of this OSIG which was used to form the signature. This field is ignored and should be set to 0 for any Name Type other than 1. 2.2.1.1.6. Signer Name Field The Signer Name field is always encoded as a domain name, but has different meanings depending on the setting of the Name Type field. StJohns Expires April 19, 2007 [Page 9] Internet-Draft signature-only-dnssec October 2006 See that description above for more detail. 2.2.1.1.7. Signature Field The Signature field contains the cryptographic signature that covers the Signature Inception and Expirations fields as well as the DNSKEY RR specified by the Signed Key Tag field. The format of this field depends on the algorithm in use, and these formats are described in the documents used to describe the signature method. 2.2.1.1.7.1. Signature Calculation A signature covers the inception and expiration times of the signature as well as the data in the DNSKEY RR specified by the owner name of the OSIG and the Signed Key Tag field. The signature is formed as follows: signature = sign (Sig Inception | Sig Expire | DNSKEY RR ) DNSKEY RR = owner | type | class | TTL | RDATA length | RDATA where "|" denotes concatenation Sig Inception and Sig Expire are the wire formats of the Signature Inception and Signature Expiration fields respectively; "owner" is the fully qualified owner name in canonical form of both this OSIG and the DNSKEY being signed; The type MUST be DNSKEY; The class MUST have the same class as the DNSKEY RR being signed; The TTL is set to zero for the purposes of calculating and verifying the signature; 2.2.1.2. Processing of OSIG When Validating Responses If the Name Type is 1 (DNSKEY), the OSIG MUST be ignored if the Signer Name is not one of the resolver's configured trust points. If the Signer Name matches the name of one of the configured trust points, the Signer Key Tag either points to one of the trust anchors at that trust point, to one of the DNSKEY's signed by one of the trust anchors, or is missing from that DNSKEY RRSet. If not otherwise available, the resolver MUST retrieve the Signer Name DNSKEY RRSet and any associated RRSIGs prior to proceeding with validation. Further signature chaining from that RRSet upwards or off-tree is PROHIBITED. StJohns Expires April 19, 2007 [Page 10] Internet-Draft signature-only-dnssec October 2006 If the Name Type is 2 (Certificate Hash), the OSIG MUST be ignored if a certificate containing the referenced key is not present in the local certificate store or if the certificate is not trusted (for any reason - policy, expiration, bad signature) for use as a DNSSEC trust anchor. For any Name Type, the OSIG MUST be ignored if: o The Signature Algorithm of the OSIG is not one of those understood by the validator, or the algorithm is configured as unacceptable (e.g. because the validator or client policy considers it too weak); o The signature doesn't validate; o No DNSKEY at the ownername of the OSIG has a tag value which matches the Signed Key Tag field; 2.2.1.3. The OSIG RR Presentation Format The presentation formation of the RDATA portion is as follows: o The Signed Key Tag field MUST be represented as an unsigned decimal integer. o The Signature Algorithm field MUST be represented either as an unsigned decimal integer, or as a DNSSEC algorithm mnemonic. o The Name Type field MUST be represented as an unsigned decimal integer. o The Signature Expiration Time and Inception Time field values MUST be represented either as an unsigned decimal integer indicating seconds since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC, where: YYYY is the year (0001-9999, but see Section 3.1.5); MM is the month number (01-12); DD is the day of the month (01-31); HH is the hour, in 24 hour notation (00-23); mm is the minute (00-59); and SS is the second (00-59). Note that it is always possible to distinguish between these two formats because the YYYYMMDDHHmmSS format will always be exactly 14 digits, while the decimal representation of a 32-bit unsigned integer can never be longer than 10 digits. o The Signer Key Tag field MUST be represented as an unsigned decimal integer. o The Signers Name field MUST be represented as a domain name. o The Signature field is represented as a Base64 encoding of the signature. Whitespace is allowed within the Base64 text. 2.2.1.4. OSIG RR Example The following OSIG RR stores the signature by an off-tree DNSKEY located at auth.offtree.com over a DNSKEY located at example.com: StJohns Expires April 19, 2007 [Page 11] Internet-Draft signature-only-dnssec October 2006 example.com. 86400 IN OSIG 61521 5 1 { 20060330123000 20070330123000 7314 auth.offtree.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) 2.2.2. Delegation Signer - Signature-only (DSSO) Record Note: This section is substantially identical to the definition of the DS RR in [RFC4035] and was lifted almost verbatim from that document. The RR name was changed and the processing description is slightly modified. The DSSO RR is used to refer to a DNSKEY RR at the apex of a Signature-Only zone. A Signature-Only zone is one which does not necessarily contain either NSEC nor NSEC3 records and for which Provably Non-Existent (PNE) validation is neither required nor possible. The DSSO Resource Record refers to a DNSKEY RR and is used in the DNS DNSKEY authentication process. A DSSO RR refers to a DNSKEY RR by storing the key tag, algorithm number, and a digest of the DNSKEY RR. Note that while the digest should be sufficient to identify the public key, storing the key tag and key algorithm helps make the identification process more efficient. By authenticating the DSSO record, a resolver can authenticate the DNSKEY RR to which the DSSO record points. The key authentication process described in [RFC4035] is also applicable to the DSSO record. The DSSO RR and its corresponding DNSKEY RR have the same owner name, but they are stored in different locations. The DSSO RR appears only on the upper (parental) side of a delegation, and is authoritative data in the parent zone. For example, the DSSO RR for "example.com" is stored in the "com" zone (the parent zone) rather than in the "example.com" zone (the child zone). The corresponding DNSKEY RR is stored in the "example.com" zone (the child zone). This simplifies DNS zone management and zone signing but introduces special response processing requirements for the DSSO RR; these are described later in this document. The type number for the DSSO record is TBD. The DSSO resource record is class independent. StJohns Expires April 19, 2007 [Page 12] Internet-Draft signature-only-dnssec October 2006 The DSSO RR has no special TTL requirements. 2.2.2.1. DSSO RDATA Wire Format The RDATA for a DSSO RR consists of a 2 octet Key Tag field, a 1 octet Algorithm field, a 1 octet Digest Type field, and a Digest field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | Algorithm | Digest Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2.2.1.1. The Key Tag Field The Key Tag field lists the key tag of the DNSKEY RR referred to by the DSSO record, in network byte order. The Key Tag used by the DSSO RR is identical to the Key Tag used by RRSIG RRs. Appendix B of [RFC4035] describes how to compute a Key Tag. 2.2.2.1.2. The Algorithm Field The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the DSSO record. The algorithm number used by the DSSO RR is identical to the algorithm number used by RRSIG and DNSKEY RRs. Appendix A.1 of [RFC4035] lists the algorithm number types. 2.2.2.1.3. The Digest Type Field The DSSO RR refers to a DNSKEY RR by including a digest of that DNSKEY RR. The Digest Type field identifies the algorithm used to construct the digest. Appendix A.2 of [RFC4035] lists the possible digest algorithm types. StJohns Expires April 19, 2007 [Page 13] Internet-Draft signature-only-dnssec October 2006 2.2.2.1.4. The Digest Field The DSSO record refers to a DNSKEY RR by including a digest of that DNSKEY RR. The digest is calculated by concatenating the canonical form of the fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, and then applying the digest algorithm. digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); "|" denotes concatenation DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. The size of the digest may vary depending on the digest algorithm and DNSKEY RR size. At the time of writing, the use of SHA-256 [RFC4509] in the DSSO record is MANDATORY. 2.2.2.2. Processing of DSSO RRs When Validating Responses The DSSO RR links the authentication chain across zone boundaries, so the DSSO RR requires extra care in processing. The DNSKEY RR referred to in the DSSO RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC zone key, the DSSO RR (and the DNSKEY RR it references) MUST NOT be used in the validation process. 2.2.2.3. The DSSO RR Presentation Format The presentation format of the RDATA portion is as follows: o The Key Tag field MUST be represented as an unsigned decimal integer. o The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic specified in Appendix A.1 of [RFC4035] or successors. o The Digest Type field MUST be represented as an unsigned decimal integer. o The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text. 2.2.2.4. DSSO RR Example The following example shows a DNSKEY RR and its corresponding DSSO RR. StJohns Expires April 19, 2007 [Page 14] Internet-Draft signature-only-dnssec October 2006 dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw== ) ; key id = 60485 dskey.example.com. 86400 IN DSSO 60485 5 1 ( 2BB183AF5F22588179A53B0A 98631FAD1A292118 ) The first four text fields specify the name, TTL, Class, and RR type (DSSO). Value 60485 is the key tag for the corresponding "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm used by this "dskey.example.com." DNSKEY RR. The value 1 is the algorithm used to construct the digest, and the rest of the RDATA text is the digest in hexadecimal. 2.3. Differences from PNE Protocol This section covers differences from [RFC4035]. If this ID gets accepted as a working group draft, the author expects this section may be extracted into its own document and expanded to the level of detail present in [RFC4035]. For now, this section should be taken as imprecise and possibly incomplete changes to that document rather than a completely formed protocol specification. 2.3.1. Zone Signing An SO signed zone includes DNSKEY and RRSIG records and may include DSSO and OSIG records. DSSO records are always placed on the parent side of a zone cut. The OSIG records are always placed at the apex of a zone. RRSIG records are OPTIONAL for any give RRset. The lack of an RRSIG simply means the RRset may not be validated. RRSIGs that are present are constructed as described in [RFC4034]. There are no requirements that any given RRSIG be signed using a specific set of algorithms. An SO zone does not contain NSEC (or NSEC3) records. If present, they are considered extraneous and are ignored by an SO-compliant resolver. Section 2.4 of [RFC4035] is applicable both to DS and DSSO records. StJohns Expires April 19, 2007 [Page 15] Internet-Draft signature-only-dnssec October 2006 An SO zone may be subordinate to a PNE zone. The PNE zone includes a signed DSSO at the delegation point and does not include a signed DS. A PNE-only compliant resolver will see only the signed absence of any DS records and will consider the SO zone "Unsecure". 2.3.2. Serving An SO zone without further delegations (e.g. one that does not contain DSSO records) may potentially be served on an PNE compliant authoritative server, depending on specific implementation approaches for the server software. The non-delegation SO zone contains DNSSEC- type records as defined in [RFC4034], and may additionally contain OSIG records. The standard DNSSEC records require no special handling over and above that defined in [RFC4035]. The presence of an OSIG record, if any, is signalled by the presence of a special RRSIG record over the apex DNSKEY RRSet of the SO zone. See Section 2.4 below for details. If a resolver sees such RRSIG record and does not see the related OSIG record, it MUST query directly for that record. 2.3.2.1. Authoritative Server A fully SO compliant authoritative server will generally be compliant with sections 3 and 3.1 of [RFC4035] with following additions and changes: o OSIG records are treated identically to RRSIG RRs as described in section 3.1.1 of [RFC4035] and MUST be included in any responses where the apex DNSKEY RRSet is returned. o NSEC records are never provided, nor served for an SO zone (section 3.1.3 of [RFC4035] is not applicable). o DSSO records are treated identically to DS records as described in section 3.1.4 of [RFC4035] and are included in responses where the DO bit is set. Section 3.1.4.1 applies with respect to direct queries for the DSSO record. o A SO-only compliant security aware name server MUST NOT set the AD bit in any response. A server which is both SO and PNE complaint MAY set the bit for data from a PNE zone in compliance with section 3.1.6 of [RFC4035] and SHOULD NOT set the bit for data from an SO zone. 2.3.2.2. Recursive Server The major difference between a PNE-compliant DNSSEC resolver and an SO-compliant resolver is support for the two new record types, and the optional removal of support for intermediate validation. The following changes to section 3.2 of [RFC4035] apply: StJohns Expires April 19, 2007 [Page 16] Internet-Draft signature-only-dnssec October 2006 o If the recursive name server is only SO compliant and not also PNE compliant, the resolver side MUST only set the DO bit when sending queries if and only if the initiating query had the DO bit set. o Differing from 3.2.2, when the CD bit is set in the query, the SO recursive nameserver MUST, if possible, return the requested data to the originating resolver regardless of any local authentication policy. o The resolver side MUST also set the CD bit when sending queries when the CD bit is set in the initiating query. [Note: The current behavior for a PNE recursive resolver may be in error.] o If the recursive name server is only SO compliant and not also PNE compliant, the AD bit MUST be ignored on input and cleared on output. o If the recursive name server is only SO compliant and not also PNE compliant, the name server MUST process queries with the DO bit set and the CD bit cleared as if it were a non-DNSSEC recursive server. 2.3.3. Resolving Section 4 of [RFC4035] does not entirely apply to SO-compliant resolvers. In general, the signature verification function exists only in the end or client resolver which is querying on behalf of a specific application or server. Also, there is no requirement for authenticated denial of existence. Section 4 is partially applicable as follows only to the end-resolver: o Section 4.1 applies. o Section 4.2 does not apply except that the resolver MAY query for missing security RRs as described, and the description of retrieving missing DS records applies both to DS and DSSO records. o Section 4.3 does not apply. An SO-compliant resolver emits either "Validated" for data for which it is able to verify a chain of trust or "Unvalidated" for all other data. o Section 4.4 applies, but is extended to include support both for off-tree trust anchors and for certificate trust anchors. o Section 4.5 applies with respect to caching. o Section 4.6 does not apply. A SO-compliant resolver MUST set both the DO and CD bits on each query. o Section 4.7 - TODO: This probably shouldn't be any different than how most data is treated, and may be only applicable to an intermediate resolver. For further study. o Section 4.8 is applicable. o Section 4.9 is applicable. o Section 4.9.1 is not entirely applicable. An SO-compliant resolver MUST set the DO bit. o Section 4.9.2 is not entirely applicable. An SO-compliant resolver MUST set the CD bit. StJohns Expires April 19, 2007 [Page 17] Internet-Draft signature-only-dnssec October 2006 o Section 4.9.3 is not applicable. An SO-compliant resolver MUST ignore the setting of the AD bit in a response and MUST NOT set it in a query. 2.3.4. Authenticating DNS Data 2.3.4.1. Chain of Trust An SO DNSSEC chain of trust can have one of three different structures. The structures differ only at the top in how trust is traced from three different types of trust anchors: standard DNSSEC with a superior (to the data) DNSKEY; off-tree DNSKEY; off-tree certificates. The various chains look like this: Standard Chain o A signature by a trust anchor over the trust point DNSKEY RRSet o Zero or more delegations consisting of: 1. A signature by a DNSKEY in the signed RRSet over either a delegation DS or delegation DSSO RRSet within the zone. 2. A signature by the child zone apex DNSKEY to which a DS or DSSO refers over the child zone apex DNSKEY RRSet. o A signature by a DNSKEY from the apex DNSKEY RRSet over a data (e.g. A, MX) RRSet within the zone. Off-Tree DNSKEY o Signature by an off-tree DNSKEY trust anchor over its DNSKEY RRSet. o An OSIG signature by a DNSKEY in the off-tree DNSKEY RRSet over an apex DNSKEY. o A signature by the OSIG-signed DNSKEY over the apex DNSKEY RRSet. o Zero or more delegations as above. o A signature by a DNSKEY in the final apex DNSKEY RRSet over a data RRSet. Off-Tree Certificate o An OSIG signature by a public key embedded in a certificate identified as a DNSSEC trust anchor over an apex DNSKEY. o A signature by the OSIG-signed DNSKEY over the apex DNSKEY RRSet. o Zero or more delegations as above. o A signature by a DNSKEY in the final apex DNSKEY RRSet over a data RRSet. 2.4. Off-tree Signature Hint The OSIG record is used to provide an authenticated link between a trust anchor and a DNSKEY which is not subordinate to that trust anchor. In other words, it embodies the secure portion of an off- tree-signature. The presence of one or more OSIG records at the apex StJohns Expires April 19, 2007 [Page 18] Internet-Draft signature-only-dnssec October 2006 of a zone is signaled by placing an RRSIG at the apex where the type covered is DNSKEY, the algorithm is TBD, the label count is appropriate to the owner name, the key tag is 0, and the signature field consists of a single octet of zero. The presence of an RRSIG with this specific algorithm type is a hint which tells the resolver to retrieve the OSIG record if not otherwise provided. The RRSIG should be included by the zone administration for any zone served by a server which is not fully SO compliant. The RRSIG may be omitted if the zone is served by a server that is fully implements SO capabilities (e.g. includes the OSIG RRSet for any query which would also return the apex DNSKEY RRSet RRSIG record(s)). [Note: "should" and "may" are correct here vs "SHOULD" and "MAY" - the contents of a zone cannot be prescribed as protocol elements.] 2.5. Dynamic Update TODO: Basically, each RRSet plus the covering RRSIG(s) are atomic. Changes to an RRSet can be accomplished simply by re-signing the RRSet and providing the RRSet and RRSIG(s) for upload to the zone. No requirement to deal with NSEC/NSEC3 records. 2.6. Wildcards [TODO: Validate the following - may need some tweaking.] One of the corner cases for both PNE and SO DNSSEC is the processing of Wildcard records. In SO DNSSEC, a DNS node that is covered by a wild card (e.g. "foo.example.com" is covered by "*.example.com" may be validated by both an RRSIG over the specific record and over the wildcard. This is a limitation, but in general not a problematic one. SO zone operators should avoid creating records that are covered by wildcards, but if they choose to do so, they should be aware of the implications. 3. Security Considerations [On hold pending WG discussion.] 4. IANA Considerations The following allocations will be required by this document: 1. A DNS RR Type Code allocation for the OSIG Resource Record. 2. A DNS RR Type Code allocation for the DSSO Resource Record. Potentially, a type code registry may be require for future values for the Name Type field of the OSIG Resource Record. StJohns Expires April 19, 2007 [Page 19] Internet-Draft signature-only-dnssec October 2006 5. References 5.1. Normative References [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006. 5.2. Informative References [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC4431] Andrews, M. and S. Weiler, "The DNSSEC Lookaside Validation (DLV) DNS Resource Record", RFC 4431, February 2006. Author's Address Michael StJohns Nominum, Inc. 2385 Bay Road Redwood City, CA 94063 USA Phone: +1-301-528-4729 Email: Mike.StJohns@nominum.com StJohns Expires April 19, 2007 [Page 20] Internet-Draft signature-only-dnssec October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). StJohns Expires April 19, 2007 [Page 21]