Received: from sol.tis.com by magellan.TIS.COM id aa07227; 16 Mar 94 10:03 EST Received: from magellan.TIS.COM by tis.com (4.1/SUN-5.64) id AA23057; Wed, 16 Mar 94 10:03:37 EST Received: from localhost.tis.com by magellan.TIS.COM id aa07220; 16 Mar 94 10:03 EST Reply-To: James M Galvin To: dns-security@tis.com Subject: [IESG Secretary: WG Action: DNS Security (dnssec)] Date: Wed, 16 Mar 1994 10:03:36 -0500 From: James M Galvin Message-Id: <9403161003.aa07220@magellan.TIS.COM> I just realized this message did not make it to this mailing list. So, just in case you're not on the IETF Announce mailing list, here you go. Jim ------- Forwarded Message Message-ID: <9403041541.aa10990@IETF.CNRI.Reston.VA.US> Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: IESG Secretary To: IETF-Announce:;@tis.com Date: Fri, 04 Mar 94 15:40:56 -0500 Subject: WG Action: DNS Security (dnssec) A new working group has been formed in the Service Application Area of the IETF. For more information, please contact the working group's chair(s) or the Area Director. IESG Secretary DNS Security (dnssec) - --------------------- Chair(s): James Galvin Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:dns-security@tis.com To Subscribe: dns-security-request@tis.com Archive: ftp.tis.com:/pub/dns-security Description of Working Group: The Domain Name System (DNS) Security Working Group (dnssec) will specify enhancements to the DNS protocol to protect the DNS against unauthorized modification of data and against masquerading of DNS data origin. That is, it will add data integrity and authentication capabilities to the DNS. The specific mechanism to be added to the DNS protocol will be a digital signature. The digital signature service will be added such that the DNS resource records will be signed and, by distributing the signatures with the records, remote sites can verify the signatures and thus have confidence in the accuracy of the records received. There are at least two issues to be explored and resolved. First, should the records be signed by the primary or secondary (or both) servers distributing the resource records, or should they be signed by the start of authority for the zone of the records. This issue is relevant since there are servers for sites that are not IP connected. Second, the mechanism with which to distribute the public keys necessary to verify the digital signatures must be identified. Two essential assumptions have been identified. First, backward compatibility and co-existence with DNS servers and clients that do not support the proposed security services is required. Second, data in the DNS is considered public information. This latter assumption means that discussions and proposals involving data confidentiality and access control are explicitly outside the scope of this working group. Goals and Milestones: Mar 94 Submit proposal for adding Security enhancements to DNS as an Internet-Draft Jul 94 Update Internet-Draft on adding security enhancements to DNS Nov 94 Submit proposal for adding security enhancements to the DNS to the IESG for consideration as a Proposed Standard ------- End of Forwarded Message   Received: from sol.tis.com by magellan.TIS.COM id aa12831; 23 Mar 94 13:05 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02665; Wed, 23 Mar 94 13:05:22 EST Received: by relay.tis.com; id AA19897; Wed, 23 Mar 94 13:04:54 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.3mjr) id sma019883; Wed Mar 23 13:04:01 1994 Received: from skidrow.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA20595; Wed, 23 Mar 94 09:49:06 -0800 Received: by skidrow.lkg.dec.com (5.65/DEC-Ultrix/4.3) id AA02754; Wed, 23 Mar 1994 03:43:38 -0500 Message-Id: <9403230843.AA02754@skidrow.lkg.dec.com> To: Internet Drafts Cc: dee@skidrow.lkg.dec.com, Charlie Kaufman , dns-security@tis.com Subject: Revised dns-secext draft Date: Wed, 23 Mar 94 03:43:38 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Hi, Here is an improved of our DNS Security Extensions drafts. Sorry to get this in so close to IETF... Donald --------------------------------------------------------------------------- Donald E. Eastlake, III DTN: 226-6577(w) dee@lkg.dec.com 550 King St, LKG2-1/BB3 1-508-486-6577(w) dee@ranger.enet.dec.com Littleton, MA 01460 USA 1-508-486-7417(fax) 1-508-287-4877(h) INTERNET-DRAFT DNS Protocol Security Extensions 23 March 1994 Expires 22 September 1994 Domain Name System Protocol Security Extensions ------ ---- ------ -------- -------- ---------- Donald E. Eastlake 3rd & Charles W. Kaufman Status of This Document This draft, file name draft-ietf-dnssec-secext-01.txt, is intended to be become a standards track RFC. Distribution of this document is unlimited. Comments should be sent to the DNS Security Working Group mailing list or to the authors. This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions Abstract The Domain Name System has become a critical operational part of the Internet infrastructure yet it has no security mechanisms to assure data integrity or authentication. Extensions to the DNS protocol are proposed to provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are added to secured zones as resource records. They can be most efficiently handled by security aware servers but security can still be provided to security aware resolvers or applications even by non-security aware secondary or caching servers. In addition, the extensions provide for the storage of authenticated keys in the DNS, so that a security aware resolver can learn the authenticating key of zones in addition to those for which it is initially configured, and for other purposes. Finally, the extensions optionally provide for authentication of DNS protocol transactions for additional security. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................5 2. Overview of the Protocol...............................5 2.1 Data Origin Authentication.............................5 2.1.1 Security Provided...................................5 2.1.2 The SIG Resource Record..............................6 2.1.3 The RSA Resource Record..............................7 2.1.4 Signers Other Than The Zone..........................7 2.1.5 Special Problems With Time-to-Live...................7 2.1.6 Improved Performance At The Expense Of Compatibility.8 2.2 DNS Transaction Authentication.........................9 3. Services, Requirement, and Non-Requirements............10 3.1 Requirements..........................................10 3.2 Non-Requirements......................................12 4. The Security Desired & Security Available Bits.........13 5. The SIG Resource Record................................14 5.1 SIG RDATA Format......................................14 5.1.1 SIG Flag Bits.......................................15 5.1.2 Signature Format....................................15 5.1.3 Signet Format.......................................16 5.1.3.1 Direct Resource Record Signets....................17 5.1.3.2 Direct Glue Record Signet.........................18 5.1.3.3 Hashed Resource Record(s) Signet..................18 5.1.3.4 Partial RR Set Flag Signet........................19 5.1.3.5 Partial SIG Set Flag Signet.......................20 5.1.3.6 AXFR Signets......................................20 5.1.3.7 Message Hashed Signets............................21 5.1.3.8 Reserved Signet Prefixes..........................21 5.2 SIG RRs in the Construction of Responses..............22 5.3 Processing Responses with SIG RRs.....................23 5.4 File Representation of SIG RRs........................24 5.4.1 Size of Data........................................24 5.4.2 RR Numbering........................................24 5.4.3 SIG RR Scope........................................25 5.4.4 RRs Supressed by a SIG RR...........................25 5.4.5 Indicating Revocation...............................25 6. The RSA Resource Record................................27 6.1 RSA RDATA format......................................27 6.2 Types of DNS Names and Keys...........................27 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions 6.3 RSA RR Flag Bits......................................28 6.4 RSA RRs in the Construction of Responses..............29 6.5 File Representation of RSA RRs........................29 7. How to Resolve Securely................................31 7.1 Boot File Format......................................31 7.2 Chaining Through Zones................................31 7.3 Secure Time...........................................32 8. Operational Considerations.............................34 8.1 Modulus Size Considerations...........................34 8.2 Key Storage...........................................34 8.3 Key Generation........................................35 8.4 Key Lifetimes.........................................35 8.5 Key Revocation........................................35 8.6 Root..................................................36 9. Conformance............................................37 9.1 Server Conformance....................................37 9.2 Resolver Conformance..................................37 10. Security Considerations...............................38 References................................................38 Authors Addresses.........................................39 Expiration and File Name..................................39 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 4] INTERNET-DRAFT DNS Protocol Security Extensions 1. Introduction [To be written] 2. Overview of the Protocol These DNS protocol extensions provide two distinct services: data origin authentication, described in section 2.1 below, and message authentication, described in section 2.2 below. In addition, the resource records added to support these authentication services permit the association of keys with DNS names. These keys could be used in support of other security services such as IP level security in addition to supporting DNS zone security. 2.1 Data Origin Authentication There are two distinct aspects to the data origin authentication service. The purpose of the first is to add security; the purpose of the second is to improve performance when the first is used. Adding security requires no changes to the "on-the-wire" DNS protocol beyond the addition of two new resource types: signatures and keys. This service could be supported by existing resolver and server implementations so long as they could support the additional resource types. If signatures are always retrieved and verified when retrieving the information they authenticate, there will be more trips to the server and performance will suffer. The revisions to the DNS wire protocol for security aware servers are an attempt to mitigate that degradation by automatically sending exactly the signatures needed and by skipping the sending of the data if it can be derived from the signature. 2.1.1 Security Provided Security is provided by associating with each item of information in DNS a cryptographically generated digital signature. Commonly, there will be a single RSA key that signs for an entire zone. If the resolver reliably learns the public RSA key of the zone, it can verify that all the data read was properly authorized and is reasonably current. The expected implementation is for the zone private key to be kept off-line and used to re-sign all of the records in the zone periodically. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 5] INTERNET-DRAFT DNS Protocol Security Extensions The data origin authentication key belongs to the zone and not to the servers that store copies of the data. That means compromise of a server will not affect the degree of assurance that a resolver has that the data is genuine. However, such a server can (except in the case of a zone transfer) claim that a name does not exist and a resolver may not be able to determine otherwise. A resolver can learn the public key of a zone either by having it manually configured or by reading it from DNS. To reliably learn the public key by reading it from DNS, the key itself must be signed. Thus to provide a reasonable degree of security, the resolver must be configured with at least the public key of one zone. From that, it can securely read the public keys of other zones. It is in principle more secure to have the resolver manually configured with the public keys of multiple zones, since then the compromise of a single zone would not permit the faking of information from other zones. It is also more administratively cumbersome, however, particularly when public keys change. 2.1.2 The SIG Resource Record The syntax of a SIG resource record (signature) is described in Section 5. It includes the name of the signer, the time at which the signature was created, the time it expires (when it is no longer to be believed), its original time to live (which may be longer than its current time to live but cannot be shorter), some flags, and an RSA (Rivest, Shamir, and Adelman [RSA]) signature. There are a number of unusual aspects to the construction of the RSA signature that are intended to maximize performance in this application. Unlike some other digital signature schemes like El Gamal or DSS, RSA signatures have the property that when a signature is verified, it produces a message that is almost the size of the signature itself. In most uses, for example Privacy Enhanced Mail, the message to be signed is much larger than the signature (which is generally 64-256 bytes long), so a message digest of the message is computed (a 16-20 byte "fingerprint") and that quantity is signed. For DNS, however, it will be common that the messages being signed, will be very short - sometimes shorter than 16-20 bytes - particularly with the abbreviation techniques used herein. Further, there are commonly multiple resource records associated with a DNS name, and it should be efficient to verify a signature on a single one of those records or any subset of them. If a 64-256 byte signature record were created for every resource record, there would be an unacceptable explosion of data. The SIG resource record syntax proposed therefore has two unusual Donald E. Eastlake 3rd & Charles W. Kaufman [Page 6] INTERNET-DRAFT DNS Protocol Security Extensions properties: (1) when it signs a resource record, it may contain either the resource record itself or a message digest of the resource record; and (2) a single signature may sign multiple multiple resource records associated with a single name. Every name in a zone supporting signed data will have associated with it one or more SIG resource records - as many as required to sign all of the non-SIG resource records. A security aware server supporting the performance enhanced version of the DNS protocol security extensions will return with all records retrieved the corresponding SIG records. If a server does not support the protocol, the resolver must retrieve all the SIG records for a name, verify them all, and find the one or ones that sign the resource records that resolver is interested in. As a further optimization, a server supporting the performance enhanced version of the protocol will return only the signature - and skip the requested data - in the case where the signature contains enough information to reconstruct the data in full. Because of this, in some cases the authenticated data being sent via SIG records can be shorter than the plain data would have been. 2.1.3 The RSA Resource Record The syntax of an RSA resource record (key) is described in Section 6. It is present for two reasons: to support the DNS infrastructure itself so that a resolver that is manually configured with the public keys of one or more zones can securely learn the public keys of other zone; and to allow the storing of RSA public keys of DNS-named entities other than zones for applications like IP-Security. 2.1.4 Signers Other Than The Zone There are two cases where a signature is generated by other than the zone private key. One is for future support of dynamic update where an entity is permitted authenticate/update its own record. The public key of the entity must be present in the DNS and signed with the zone key, but the other RRs may be signed with the entity's key. The other is for support of message authentication as described in 2.2 below. 2.1.5 Special Problems With Time-to-Live A digital signature will fail to verify if any change has occurred to the data between the time it was originally signed and the time the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 7] INTERNET-DRAFT DNS Protocol Security Extensions signature is verified. This conflicts with our desire to have the time-to-live field tick down when resource records are cached. This could be avoided by leaving the time-to-live out of the digital signature, but that would allow unscrupulous secondaries to set arbitrarily long time to live values undetected. Instead, we include the "original" time-to-live in the signature and communicate that data in addition to the current time-to-live. Unscrupulous servers under this scheme can fail to decrement time to live, but they cannot increase it beyond its original value. Separately, signatures include a time signed and an expiration time. A resolver that knows an absolute time can determine securely whether a signature has expired. In order to keep the data as compressed as possible, we don't want to have to include the original TTL for every resource record included in a SIG when usually they are all the same. We therefore assume that the original TTL is equal to the original TTL of the SIG resource record (which is sent for every SIG resource record), and in the rare case where the TTL on the other resource record differs we permit it to be explicitly included. 2.1.6 Improved Performance At The Expense Of Compatibility To run the high performance version of the protocol, the server should remember for each resource record: (1) which SIG record includes the signature for that record and (2) whether the SIG record contains the resource record in full or in digested form. When the server is responding to a request, it should for each record requested return the corresponding SIG (removing duplicates) and also it should suppress the sending of the record itself if it is present in the signature in undigested form. Since a resolver running the secure protocol will not believe any record that is not signed, there would be no point in returning the record without the SIG. And if the resolver is going to see the RR in full in the course of verifying the signature there is no point in wasting bandwidth by sending the RR being authenticated. The high performance version of the protocol can only be used if both resolver and server understand it. Negotiation is done via some DNS message header bits we believe that existing servers will ignore and existing resolvers will not set. If signature verification is not done by the DNS resolver code but rather by some application that is retrieving resource records through that resolver, the standard protocol must be used. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 8] INTERNET-DRAFT DNS Protocol Security Extensions 2.2 DNS Transaction Authentication The data origin authentication service described above protects resource records but provides no protection for message headers and limited protection against resource record addition to or deletion from a message. If header bits or, in some cases, the resource record set in a response, are falsely set by a server, there is little that can be done. However, it is at least possible to add transaction authentication. Such authentication means that a resolver can be sure it is getting messages from the server it thinks it queried and that the response if from the query it sent and that these messages have not been diddled in transit. This is accomplished by adding a SIG resource record to end of the reply which digitally signs the message by the server and includes a hash code of the query. The private key used belongs to the host composing the reply, not to the zone being queried. The corresponding public key is stored in and retrieved from the DNS. Because replies are highly variable, message authentication SIGs can not be precalculated. Thus it will be necessary to keep the key on- line, for example in software or in a directly connected piece of hardware. The best way to get the security provided by the transaction authentication service would be to use a good IP level security protocol. The authors of this draft decry the every growing number of IP application level security protocols such as Telnet, NTP, FTP, etc., etc. when a single IP-security protocol could secure most of these applications. Unfortunately, an IP-security standard has not yet been adopted. And even if it had, there will be many systems for many years where it will be hard to add IP security but relatively easy to replace the DNS components. Furthermore, the data original authentication service requires the implementation of essentially all the mechanisms needed for a rudamentary message authentication service. Thus a simple transaction authentication service using mechanisms already required by DNS security is included as a strictly optional part of these extensions. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 9] INTERNET-DRAFT DNS Protocol Security Extensions 3. Services, Requirement, and Non-Requirements This section is based on the 19 November 1993 email message from James M. Galvin summarizing the Houston IETF meeting of the DNS Security BoF. At this meeting a list of requirements, shown in 3.1 below, and non-requirement shown in 3.2 below, were arrived at. The security services desired were set at the following: data integrity, and data origin authentication. It was noted at that meeting that these services can be provided by digital signatures. 3.1 Requirements The numbered items below were determined to be "requirements", not in the sense of being mandatory but in the sense of all being highly desirable. A comment appears after each requirement as to if/how it is met by this proposal. <1> Sites must be able to support at least their internal users in the presence of external network failures. Security aware resolvers can be configured with the public key of their local apex zone. The needed SIG RRs can be added to that zone and any desired lower level zones either off-line or on-line. Thus this requirement is met. <2> it should be possible for a site to pre-configure other authoritative servers without having to query the "system" to find the server. Security aware resolvers can be configured with the public key of any other zones and the IP address of their servers. <3> It should be possible to request services only from security enhanced servers, only from non-security enhanced servers, or a indicate that either is acceptable. These proposed protocol extensions do not provide any enhancement to the NS RR or otherwise to indicate whether or not a server is security aware without actually querying it. It is believed that this additional complexity is not warranted. Non-security aware servers can still support security aware resolvers, although less efficiently. It is possible to tell if a server is security aware by the SA (Security Available) bit in the header of its responses. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 10] INTERNET-DRAFT DNS Protocol Security Extensions <4> It should be possible to recognize security enhanced responses. Security enhanced responses can be recognized by the presence of SIG RRs. <5> It should be possible to assign cryptographic keys (make use of the security services) to leaf nodes in the DNS tree, i.e., fully qualified domain names. The proposed extensions allow RSA key RRs to be associated with any node in the DNS tree. Indeed, more than one key can be associated with a node whose name serves multiple functions. <6> It should be possible to not trust secondary servers. The proposed extensions can be implemented so that the zone private key is never on line on the network. Thus, ignoring denial of service threats, it is possible to have untrusted secondaries and even untrusted primaries. <7> A mechanism must exist for revoking cryptographic keys that works within the DNS time-to-live framework. A bit is defined in the SIG RR to indicate if it is an assertion or revocation. This applies to keys (RSA RRs) and such key revocations are opportunisticly flooded as additional information on every query to their zone if the resolver and server are security aware. However, an additional mechanism may be necessary to notify secondaries, caching servers, etc. to assure that a revocation is noticed within the TTL. This is really just a special case of a change in zone information and a general mechanism such as the NOTIFY operation described in draft-ietf-dns-ixfr-01.txt could be used. However, guaranteed revocation is not possible (for example in a partitioned network) without introducing unacceptable denial of service risks (such as having to wait "forever" to get a current "key revocation list" for a zone if the network is partitioned). <8> Security services should be supported with no additional DNS queries beyond what would be required if security was not supported. No additional queries are required, barring possible UDP truncation problems, to obtain authentication from or to securely learn the public key for a zone when its names servers are being obtain if a security enhanced server is being used by a security aware resolver. <9> It must be possible to ensure that cached data expires according to its TTL. A security aware resolver has both the TTL for an RR and the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 11] INTERNET-DRAFT DNS Protocol Security Extensions expiration time of the SIG covering the RR. Cached data is always invalid after the SIG expiration time plus the original TTL. 3.2 Non-Requirements It was explicitly decided by the DNS Security BoF at the Houston IETF meeting that the following were not requirements: <1> Confidentiality: DNS data is "public" and no effort need be made to provide encryption of queries/responses. (This service may be available via an IP level security protocol which is currently being worked on by the IP Security Working Group of the IETF .) <2> Access control: DNS data is "public" and no effort need be made to provide access control lists, or similar mechanisms, as part of this DNS security effort. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 12] INTERNET-DRAFT DNS Protocol Security Extensions 4. The Security Desired & Security Available Bits The header section of DNS messages is modified to define bits 9 and 10 in the second word (fourth octet). These were formerly the top two bits of the Z field defined as "Reserved for future use." [RFC1035] These bits are defined as security desired, labeled SD, and security available, labeled SA. With the definition of these bits, the header looks like the following: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | QR| Opcode | AA| TC| RD| RA| SD| SA| Z | RCODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | QDCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ANCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | NSCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ARCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ All fields are as before except that the Z field is reduced to one bit and SD and SA are defined as follows: SD Security Desired - this bit may be set in a query. If the server to which the query is sent does not support the DNS security protocol, the bit should be ignored except that it may be copied into the response. If the server does support this protocol, the bit MUST copied into the response and, if the bit is set, the server MUST provide any SIG and RSA RRs as described in the sections below concerning these RRs. SA Security Available - this is to be set or cleared in a response. If set, it indicates that the server fully supports this security protocol. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 13] INTERNET-DRAFT DNS Protocol Security Extensions 5. The SIG Resource Record The SIG or "signature" resource record (RR) is the fundamental way that resource records (and optionally message) are authenticated. The SIG RR unforgably binds one or more other RRs (or a DNS message) to a time and the signer's fully qualified domain name using cryptographic techniques and the signer's private key. The signer is the owner of the zone the RR originated from (or the composer of the authenticated DNS message). 5.1 SIG RDATA Format The RDATA portion of a SIG RR is as shown below. The integrity of the RDATA information and that of the SIG RRs owner, type, and class are protected by the signature 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signer's name | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time signed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key footprint | flags | sig length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of the SIG type is xxx. The "signer's name" field is the fully qualified domain name of the signer generating the SIG RR. This is the zone which contained the RR(s) being authenticated (or the host which is the source of a DNS reply that is being authenticated). The "original TTL" field is included in the RDATA portion to avoid authentication problems that caching servers would otherwise cause by decrementing the real TTL field and security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field. This original TTL is protected by the signature while the real TTL field is not. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 14] INTERNET-DRAFT DNS Protocol Security Extensions The "time signed" field is an unsigned number of seconds since the start of 1 January 1970. The SIG is valid until the signature expiration time which is a field of the same format as the time signed. The "key footprint" is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the lest significant 24 bits of this quantity. In cases where multiple keys may be applicable, it can be used to efficiently pick the right one in most cases. The "flags" octet is described below. The "sig length" field is an unsigned 8 bit count of the number of octets in the signature field. The structured of the "signature" field is described below. [It would be possible to allow additional optional fields after the above in the SIG RR as described in draft-ietf-dns-ixfr-01.txt] 5.1.1 SIG Flag Bits Bits 0 to 6 are reserved and must be zero. Bit 7 (the least significant bit) a zero means the SIG RR asserts the validity of the RR it signs from the start to the end time, inclusive. If it is a one, the RSA RR is a revocation of the RR as above. 5.1.2 Signature Format The actual signature portion of the SIG RR binds the owner, signer, class, original TTL, time signed, and expiration time of the RR to one or more RRs (or DNS messages) being authenticated. To accomplish this, it contains at least one "signet", as defined in the following section, and a "self-hash" field covering the above items. The structure of signets is described in section 5.1.2 below. The signature is then calculated using the RSA public key system as follows s = ( 01 | FF* | 00 | signets | self-hash ) ** e (mod n) where "|" is concatenation. "signets" is the concatenation of the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 15] INTERNET-DRAFT DNS Protocol Security Extensions signets included in this signature. "self-hash" is the 20 octet hash using the Secure Hash Standard [SHS] of the SIG RR name, class, signer name, original TTL, time signed, expiration time, key footprint, and flags. "e" is the secret key exponent of the signer, and "n" is the public modulus that is the signer's public key. 01, FF, and 00 are fixed octets of the corresponding hexadecimal value. The FF octet is repeated the maximum number of times such that the value of the quantity being exponentiated is less than the value of n. No FF octets need occur if "signets" is long enough. The order of the signets is not significant. The size of n, including most and least significant bits (which will be 1) SHALL be at least 641 and not more than 2040. n and e MUST be chosen such that the public exponent is less than 2**24 - 1 and SHOULD be chosen such that the public exponent is small. The above specifications are similar to PKCS #1 [PKCS1] except that, under most circumstances, one additional byte of data is allowed. (A public exponent of 3 minimizes the effort needed to decode a signature. Use of 3 as the public exponent may be weak for confidentiality uses since, if the same data can be collected encrypted under three different keys with an exponent of 3 then, using the Chinese Remainder Theorem [ref], the original plain text can be easily recovered. This weakness is not significant for DNS because we seek only authentication, not confidentiality.) 5.1.3 Signet Format Each signet consists of a prefix octet, with which the length of the signet can be unambiguously determined, followed by the signet data. Signet's are of three basic types: hashed, direct, and flag. A hashed signet consists of the prefix octet, some additional data, and a 20 bit hash of the data covered using the Secure Hash Standard [SHS]. Since this hash algorithm is not invertible, the data, such as RRs, covered by a hashed signet must also be included in the reply to a query if it was requested. A direct signet includes all of the data it covers. Some of the data may be implicit or compressed but it is all unambiguously recoverable. If a direct signet is present covering an RR, then that RR SHOULD be supressed from the reply message if the SD bit is on in the query and the server is security aware. Flag signets occur with direct signets and multiple SIG RRs. They are used to determine if a complete set of RRs of a particular Donald E. Eastlake 3rd & Charles W. Kaufman [Page 16] INTERNET-DRAFT DNS Protocol Security Extensions variety are present. Signet prefix octets are as follows: 0000000* Illegal 0LLLLLLL Direct Resource Record - type & rdata 10LLLLLL Direct Glue Record - name, type, & rdata 110***** (reserved) 1110**** (reserved) 11110NHT Hashed RR(s) - N, type, T, & hash 11111000 Partial SIG Set Flag 11111001 Partial RR Set Flag 11111010 Hashed query message 11111011 Hashed response message 1111110* (reserved) 1111111* Illegal In the above table, "*" represents 0 or 1 and L, N, H, and T are bits whose meaning is defined in the signet descriptions below. The illegal prefixes should never occur. Any signature that appears to include one should be considered invalid. 5.1.3.1 Direct Resource Record Signets This signet is an actual RR but with some fields supressed. In order to avoid inconsistencies, all RRs of the same type and class have to have the same TTL, at least for currently defined RRs. SIG RRs need not survive beyond the RRs they authenticate but must live as long as the covered RRs do. Thus SIG RRs may be constrained to having the same TTL as the RRs they cover in most cases. The SIG RR will always have the same class and name as the RRs it covers (except for glue RRs as described in 5.1.3.2 and 5.1.3.3 below). Finally, the signet data length in the prefix octet can be used to calculate the RDSIZE. Thus RRs directly represented by this variety of signet are compressed by omitting their name, class, TTL, and RDLENGTH fields. Only the type, and RDATA are present. For example, the direct signet for a type A record in the IN (Internet) class would be seven octets as follows: 06 00 01 xx yy zz ww where 06 is the prefix indicating a direct RR signet with six data octets, 00 01 is hex for the type code for type A, and xx yy zz ww is the 32 bit IP address from the RR. These 7 octets in a SIG RR completely represent the 15+ (1+ name, 2 type, 2 class, 4 TTL, 2 rdlength, 4 ip address) octets of the original type A RR. The class, name, and TTL are all recoverable from the same fields of the SIG RR whose signature field includes this signet. Thus the original type A RR can be supressed from the answer if given to a security aware Donald E. Eastlake 3rd & Charles W. Kaufman [Page 17] INTERNET-DRAFT DNS Protocol Security Extensions resolver. Note that any names in the RDATA area of this type of signet can not be abbreviated by pointers outside of the reconstructed RR. That is because the SIG RR and its signets are frozen at the time the signature is encrypted under the signer's private key and this frozen SIG may then be used in a variety of DNS messages. The RDATA area may, however, if it has multiple names, abbreviate them by references to earlier names within the reconstructed RR. The direct representation of RRs makes maximum use of the relatively large size of RSA digital signatures for common cases. The direct representation also avoids the computational effort of calculating a hash code. Because the original RR's type field must always be present, the minimum length of the data after this type of signet prefix is 2, thus prefixes of 00 and 01 hex are illegal. The maximum size direct RR signet is 128 octets. All RRs need not be included within a signature using this direct signet. If the data portion of a direct RR signet exceeds 22 octets (i.e., a total signet size of 23 octets including the prefix count octet), space inside the signature can be saved by going to the hashed RR signet described below. If an RR compressed for a direct signet exceeds 127 bytes or the amount of space available for signets in the signature part of a SIG RR, then it must appear separately and be authenticated by a hashed RR signet. 5.1.3.2 Direct Glue Record Signet Glue records must be handled a little differently. These are currently always A records with a name which usually isn't even in the zone being handled but are associated with an RR in the zone. This type of signet allows such glue RRs to be included within a SIG. The direct glue record signet is just like the direct resource record signet described above except that the name is included right after the prefix and before the type and RDATA. If the Glue Record signet won't fit, a hashed RR signet, described below, must be used. Note that names in the DNS can be up to 256 bytes long which would not fit inside a SIG RR signature field. 5.1.3.3 Hashed Resource Record(s) Signet RRs can also be protected by a signet with a hash code. If a hashed signet is used, all RRs of the same name, type, class, and TTL MUST Donald E. Eastlake 3rd & Charles W. Kaufman [Page 18] INTERNET-DRAFT DNS Protocol Security Extensions be hashed into a single signet. To avoid inconsistencies, RRs of the same name, type, class, and TTL must either all be present or all be absent. Thus a single hash code covering such multiple RRs is all that is required. The signet is then formed by a single octet 11110NHT (binary) prefix followed by a possible name field depending on "N" and "H" as described below, the two octet type for the RRs covered, a possible TTL field depending on the values of "T" described below, and then the 20 octet hash code. The hash is calculated by concatenating the full RRs, with all names fully expanded and any required RDLENGTH adjustments made, in a canonical order, and applying the Secure Hash Standard [SHS]. The canonical order for RRs is to sort them in ascending order as left justified unsigned octet sequences where a missing octet sorts before a zero octet. Thus the hex sequences FE 01 02, 07, FF 03, FE FD, FF, and 01 01 01 01 would sort and be concatenated into the sequence 01 01 01 01 07 FE 01 02 FE FD FF FF 03. The "N" bit in the prefix stands for Name. It is normally zero because almost all RRs associated with a name in a zone have that name. The exception is glue records. These are currently A records with owner names outside the zone. To be able to cover these in a SIG for a different name where they cannot be included as a direct glue record signet as discussed in the section above, the N bit makes it possible to include the different name in the signet immediately after the prefix. If the N bit is a one but the H bit is zero, the name is included in full. Because names in DNS can be up to 256 bytes long, the 20 byte hash of the full name, using the Secure Hash Standard, can be used instead of the actual name and is indicated by turning on the H (or "hash") bit. To match this against RRs in the reply, their names must be hashed and compared. The "T" bit in the prefix stands for TTL. It is normally zero. For the presently defined RRs, all RRs of the same type, class, and name should have the same TTL. Future RRs may be defined for which it is useful for such RRs to have different TTL's. In that case the T bit must be one in the signet prefix octet, and the TTL of the hashed RR(s) included after the two octet type and before the hash code. If both the N and T bits are on, the name appears immediately after the prefix byte followed by the type, then the TTL, then the 20 byte hash code. This is the standard order for these fields in an RR. 5.1.3.4 Partial RR Set Flag Signet Verification of a hashed RR signet against the RRs included in the hash provides a guarantee that none have been omitted. The same Donald E. Eastlake 3rd & Charles W. Kaufman [Page 19] INTERNET-DRAFT DNS Protocol Security Extensions assurance is not provided by the direct RR signet unless all of the direct RR signets of the same type and class are included in one SIG RR. If direct RR signets are split over more than one RR, they MUST be covered by a partial RR set flag signet in each RR. The partial RR set flag signet is indicated by a hex F8 prefix followed a two octet type and then by a count octet. The most significant 4 bits (nibble) of this count octet indicates one less than the total number of SIG RRs that include all of the direct signets for the variety of RRs in question. The least significant nibble is used to distinguish the different SIG RRs required and varies from zero through the value of the first nibble. It is permissible, but unnecessary, to include a partial RR set flag signet prefix followed by the type and a zero byte (i.e., 1 of 1) in the SIG RR containing direct signets for all RRs of a particular varient. For example, an signet of F8000131 (hex) means the SIG RR is the 2nd of the 4 SIG RRs covering A type RRs. Should there be a case where more than 16 SIG RRs could be required to hold the direct signets for a particular variety of RR, direct signets may not be used. The RRs must appear directly in the DNS answer and a hashed signet must be used for authentication. 5.1.3.5 Partial SIG Set Flag Signet Since the SIG RRs for an owner name are not in themselves covered by yet another SIG (except for the case of zone transfers), a malicious server might choose to provide only some of them in response to a query for SIG RRs. The partial RR set flag signet defined above is not guaranteed to help here. The signet prefix of hex F9 is followed by an unsigned byte which is one less than the total number of SIG RRs associated with the name and a second unsigned byte which varies from zero through the value of the first byte. It is permissible, but unnecessary, to include a partial SIG set flag signet prefix followed by two zero bytes (i.e, 1 of 1) if only one SIG RR is associated with a name. More than 256 SIGs many not be associated with the same name and class. 5.1.3.6 AXFR Signets To secure zone transfers, a SIG under the zone name will have a hashed RR signet with the AXFR type. It will be calculated by Donald E. Eastlake 3rd & Charles W. Kaufman [Page 20] INTERNET-DRAFT DNS Protocol Security Extensions hashing together all other static zone RRs, including SIGs. The RRs are ordered and concatenated for hashing as described in Section 5.1.3.3. This SIG, other than having to be calculated last of all zone key signed SIGs in the zone, is the same as any other SIG. It can contain non-AXFR signets, be numbered with the partial SIG set flag signet along with other zone level SIGs, if any, etc. Dynamic zone RRs which might be added by some future dynamic zone update protocol and signed by an end entity key rather than a zone key (see Section 6.2) are not included. They originate in the network and will not, in general, be migrated to the recommended off line zone signing procedure (see Section 8.2). Thus such dynamic RRs are not directly signed by the zone and are not generally protected against omission during zone transfers. 5.1.3.7 Message Hashed Signets The response message signet consists of the FA (hex) prefix followed by the 20 byte SHS hash of the entire response message before the SIG, including the header. The query signet consists of the FB (hex) prefix followed by the 20 byte SHS has of the entire query that produced this response, including the query's header. Verification of the transaction authentication SIG, which is signed by the server host key, not the zone key, and the message signets within it by the requesting resolver show that the query and response were not tampered with in transit, that the response corresponds to the intended query. 5.1.3.8 Reserved Signet Prefixes A number of signet prefixes are reserved for future allocation by the Internet Assigned Numbers Authority (IANA). All such signets will have an unsigned length octet immediately following their prefix code. This will be the length of the signet data not including the prefix or length octets. Thus their length can be unambiguously determined. Such signets are not to be generated by any implementation except for a use for which they have been allocated by IANA. Such signets are to be ignored on receipt by any implementation which does not understand them. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 21] INTERNET-DRAFT DNS Protocol Security Extensions 5.2 SIG RRs in the Construction of Responses SIG RRs MUST NOT be sent in response to a query where the SD header bit is clear unless the query specifically requests the SIG type. When the SD header bit is set, the DNS server MUST, for every RR the query will return, attempt to send the available SIG RRs which authenticate the requested RR. If multiple such SIGs are available, there may be insufficient space in the response to include them all. In this case, SIGs whose signer is the zone containing the RR MUST be given highest priority and retained even if SIGs with other signers must be dropped. Furthermore, this automatic inclusion of SIGs in a response is NOT additional information RR processing. To minimize possible truncation problems, if a SIG covers any RR that would be in the answer section of the response, it MUST appear in the answer section. If it covers an RR that would appear in the authority section and does not cover any answer section RR, it MUST appear in the authority section. If it covers an RR that would appear in the additional information section and does not cover any answer or authority section RR, it MUST appear in the additional information section. In many cases, as described below, the full authenticated RR will be included inside the SIG RR. In such cases, the DNS server SHOULD send only the SIG and supress the directly requested RR. The server should assume that the inquirer has the necessary public key to authenticate RRs with the SIG and that, in general, an RR not covered by a SIG may be considered worthless by the inquirer. However, if a SIG including a full RR or an RR and its authenticating SIG will not fit in a response, but the RR alone will, a server MAY send the unauthenticated RR notwithstanding the set SD bit in the query header. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section. Such SIG RRs are signed by the DNS server originating the response. The transaction authentication SIG contains a response message hashed signet and a query message hashed signet. Although the signer field must be the name of the originating server host, the name, class, TTL, and original TTL, are meaningless. To save space, the name should be root (a single zero byte) and the class and TTL fields can be zero. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 22] INTERNET-DRAFT DNS Protocol Security Extensions 5.3 Processing Responses with SIG RRs If SIG RRs are received in response to a query specifying the SIG type, no special processing is required but a security aware client may wish to authenticate them by decoding the signature and applying consistency checks. If SIG RRs are received in any other response, a security aware client should decoded them using the public key of the signer and the data coded into the signature should be carefully examined. It should start with a 01 FF* 00 octet sequence (a 01 octet, zero or more FF octets, and a 00 octet) followed immediately by one or more concatenated signets and ending with the 20 byte self hash field matching the hash of the relevant SIG RR fields outside of the signature. If the decoded signature can not be parsed or the self hash check fails, the SIG RR is invalid and should be ignored. The time of receipt of the SIG RR must be in the inclusive range of the time signed and the signature expiration but the SIG can be retained and remains locally valid until the expiration time plus the range authenticated TTL. Next, the contents of the one or more direct, hashed, or flag signets present should be examined. For all direct RR signets, the original RR should be reconstructed if they are of a type that should have been retrieved by the query. If they are of another type, they can be optionally reconstructed or ignored. For all reconstructed RRs, there must be a complete set of partial set flag signets or all must be included in one SIG. For hashed RR signets, the hash should be computed from RRs present in the response and compared for authentication. Hashed RR signets for a type not requested in the query must be ignored. If the SIG RR is the last RR in a response in the additional information section, it may contain hashed response and query message signets covering the preceding data in the response and the query that produced the response. These should be checked and the message rejected if the checks fails. But even it the check succeeds, such a transaction authentication SIG it does NOT authenticate any RRs in the message. Only proper direct or hashed RR signets signed by the zone can authenticate RRs. If all reasonable checks indicate that the SIG RR is valid then RRs reconstructed or verified by hash should be considered authenticated and all other RRs in the response should be considered with suspicion. The probability that a SIG RR that has been tampered with (without knowledge of the secret key) will pass reasonable checks is vanishingly small (less than 1 in 2**150). Donald E. Eastlake 3rd & Charles W. Kaufman [Page 23] INTERNET-DRAFT DNS Protocol Security Extensions 5.4 File Representation of SIG RRs A SIG RR covering RRs can be represented as a single logical line in a zone data file [RFC1033] but there are some special problems as described below. (It does not make sense to include a transaction authenticating SIG RR in a file as it is a transient authentication that must be calculated in real time by the DNS server.) 5.4.1 Size of Data There is no particular problem with the signer and times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59). The original TTL and flags fields appears as unsigned integers. The key footprint appears as an eight digit unsigned hexadecimal number. However, the signature itself can be up to 255 octets. It is the last data field and is represented in hex and may be divided up into any number of white space separated substrings, down to single hex digits, which are concatenated to obtain the full signature. These hex substrings can be split between lines using the standard parenthesis. 5.4.2 RR Numbering A SIG RR stored in a zone file covers and in some cases supresses a number of resource records via one or more direct or hashed signets. In order to represent this, RRs can be numbered by an integer field enclosed in curly braces "{}". For compatibility with earlier DNS zone file implementations, this field can occur after all data fields but before any comments, and can be optionally preceded by a single pound sign ("#") immediately before the open curly brace ("{"). This "#" will cause the RR number to be treated as a comment by non- security aware servers but the "#{ number }" will be recognized by security aware servers. [give example] Actually, the RR number is the first subfield of three within the curly braces. As described below additional fields can occur separated by semi-colons (";"). Donald E. Eastlake 3rd & Charles W. Kaufman [Page 24] INTERNET-DRAFT DNS Protocol Security Extensions 5.4.3 SIG RR Scope The RRs that are covered by a SIG RR are represented by a second sub-field inside the curly brace field which must be present for SIG RRs. This subfield consists of a comma and/or white space separated list of RR numbers, or ranges of the form n-m to indicates all integers from n through m inclusive. As an abbreviation, an asterisk ("*") appearing in this subfield means all RRs appearing before the SIG RR in the zone file back to but not include the immediately previous SIG RR or the beginning of the file, whether or not such covered RRs are numbered. The SIG RR should also be considered to cover any RRs that it supresses as explained in the section below. The SIG RR itself need not be numbered unless it needs to be referred to. For example [give examples here] 5.4.4 RRs Supressed by a SIG RR Where a SIG RR includes direct RR signets, the RRs being authenticated should normally be supressed when the SIG RR appears in a response. This is indicated in the zone data file by a third sub- field inside the curly brace field that may be present with SIG RRs and must be present if they have direct RR signets. As with the scope subfield, this subfield consists of a comma and/or white space separated list of RR numbers or ranges of the form n-m to indicate all integers from n through m inclusive. As an abbreviation, an asterisk ("*") appearing in this subfield means all RRs appearing before the SIG RR in the zone file back to but not include the immediately previous SIG RR or the beginning of the file, whether or not such supressed RRs are numbered. An RR that is supressed is implicitly covered and may, but need not, also be listed in the scope sub-field described in 5.4.2. [give example] 5.4.5 Indicating Revocation In many cases, a zone file will be maintained and SIG RRs will be added to the zone file by a separate operation. To indicate that Donald E. Eastlake 3rd & Charles W. Kaufman [Page 25] INTERNET-DRAFT DNS Protocol Security Extensions such a generated SIG should be a revocation, include the word "revoke", or any word (contiguous string of letters) beginning with a lower or upper case R within the "{}" field for the RR as described above. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 26] INTERNET-DRAFT DNS Protocol Security Extensions 6. The RSA Resource Record The RSA RR is used to document a public key that is associated with a DNS name. This can be a zone owner, the name of a DNS host for transaction authentication, etc., or any DNS name. An RSA RR is, like any other RR, authenticated by a SIG RR. Security aware DNS implementations should be designed to handle at least two simultaneously valid keys associated with a name. The type number for the RSA RR is xxx. 6.1 RSA RDATA format The RDATA for a RSA RR consists of an octet of flags, the public exponent, and the public modulus. The format is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | public key exponent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulus length| | +---------------+ public key modulus -+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The public key exponent is an unsigned 24 bit integer. The modulus length is an unsigned octet. This limits keys to a maximum of 255 bytes. A zero modulus length is special and indicates the specific assertion that there is no key associated with the owner. The public key modulus field is a multiprecision unsigned integer. The bits in the flag octet are described in Section 6.3 belows. [It would be possible to allow additional optional fields after the above in the SIG RR as described in draft-ietf-dns-ixfr-01.txt] 6.2 Types of DNS Names and Keys The same DNS name may refer to up to three things at present. For example, dee.lkg.dec.com could be (1) a zone, (2) a host, and (3) the mapping into a DNS name of the user dee@lkg.dec.com . Thus, the flag byte in the RSA RR has bits to indicate with which of these roles a Donald E. Eastlake 3rd & Charles W. Kaufman [Page 27] INTERNET-DRAFT DNS Protocol Security Extensions public key is associated as described below. It is possible to use the same key for these different things with the same DNS name but this is discouraged. In addition, there are two control bits, the "mandatory" bit and the "authority" bit, as described in 6.3 below. It would be desirable for the growth of DNS to be managed so that additional possible simultaneous uses for names are NOT added. New uses should be distinguished by exclusive domains. For example, all telephone numbers in the world have been mapped into the tpc.int domain of the operational DNS system. This is preferable to having the same name possibly be a telephone number and a host as well as a zone and a user, depending on the RRs present. 6.3 RSA RR Flag Bits Bits 0 is the "mandatory" bit. Keys may be associated with zone or entities for experimental, trial, or optional use, in which case this bit will be zero. If this bit is a one, it means that the use or availability of security based on the key is "mandatory". Thus, if this bit is on for a zone, the zone should be assumed secured by SIG RRs and any responses indicating the zone is not secured should be considered bogus. Similarly, if this bit were on for a host key and attempts to negotiate IP-security with the host produced indications that IP-security was not supported, it should be assumed that the host has been compromised or communications with it are being spoofed. On the other hand, if this bit were a zero, the host might very well sometimes operate in a secure mode and at other times operate without the availability of IP-security. The mandatory bit is only effective if the key is appropriately signed. Bit 1 is the "authority" bit. It indicates that the key can validly sign RRs of the same name. This bit is meaningless for zone keys which always have authority to sign any RRs in the zone. The bit is only effective if the key is signed by a valid zone key. Bits 2-4 are reserved and must be zero. If they are found non- zero, they should be ignored and the RSA RR used as indicated by the other flags. Bit 5 on indicates that this is a zone key for the zone whose name is the RSA RR owner name. This is the fundamental type of data origin authentication public key. Bit 6 on indicates that this is a key associated with the end entity whose name is the RR owner name. This will commonly be a host but could, in some part of the DNS tree, be some other type of Donald E. Eastlake 3rd & Charles W. Kaufman [Page 28] INTERNET-DRAFT DNS Protocol Security Extensions entity. This is the public key used in connection with the optional transaction authentication service defined in this draft. It could also be used in an IP-security protocol where authentication of a host was desired. This would be useful in IP or other security for host level services such as DNS, NTP, routing, etc. Bit 7 on indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. The coding of the owner name is that used for the responsible individual in the SOA record: The owner name is the user name as the name of a node under the entity name. For example, "j.random_user" on host.subdomain.domain could have a public key associated then through an RSA RR with name j\.random_user.host.subdomain.domain. It could be used in an IP-security protocol where authentication of a user was desired. This key would be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc. 6.4 RSA RRs in the Construction of Responses A request for RSA RRs does not cause any additional information process because of these RSA RRs except, of course, for SIG RRs if security is requested and available. Security aware DNS servers will include RSA RRs as additional information in responses where security is requested under appropriate conditions as follows: On the retrieval of NS RRs, the zone key RSA RR(s) for the zone served by these name servers will be included. If not all additional info will fit, the RSA RR(s) have higher priority than type A RRs. On retrieval of type A RRs, the end entity RSA RR(s) for the host named will be included. On inclusion of A RRs as additional information, they will also be included but with lower priority than the relevant A RRs. On any retrieval with security requested and available from a zone, any revoked RSAs that fit with their revoking SIG will be included as additional information with low priority. 6.5 File Representation of RSA RRs RSA RRs may appear as lines in a zone data file. The flags field is represented as an unsigned integer. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 29] INTERNET-DRAFT DNS Protocol Security Extensions The public key exponent appears as an unsigned integer from 3 to 16777215. The public key modulus can be quite large, up to 255 octets. It is the last data field and is represented in hex and may be divided up into any number of white space separated substrings, down to single hex digits, which are concatenated to obtain the full signature. These hex substrings can span lines using the standard parenthesis. The special case of a null key is indicated by a single zero digit. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 30] INTERNET-DRAFT DNS Protocol Security Extensions 7. How to Resolve Securely Retrieving or resolving authentic data from the DNS involves starting with one or more trusted public keys and, in general, progressing securely from them through the DNS structure to the zone of interest. Such trusted public keys would normally be configured in a manner similar to that described in section 7.1. However, as a practical matter, a security aware resolver would still gain some confidence in the results it returns even if it was not configured with any keys but trusted what it got from a local well known server as a starting point. 7.1 Boot File Format The recommended format for a boot file line to configure starting keys is as follows: zonekey f.q.d.n exponent modulus for a zone public key or hostkey f.q.d.n exponent modulus for a host public key. f.q.d.n is the domain name of the zone or host, exponent is the public key exponent between 3 and 16777215, and modulus is the public key modulus in hex. While it might seem logical for everyone to start with the key for the root zone, this has problems. The logistics of updating every DNS resolver in the world when the root key changes would be excessive. It may be some time before there even is a root key. And furthermore, some organizations may explicitly wish their "interior" DNS implementations to trust only their own zone. These interior resolvers can then go through the organization's zone server to access data outsize the organization's domain. If desired, the IP address for the f.q.d.n's with configured keys can generally also be configured via an /etc/hosts or similar local file. 7.2 Chaining Through Zones Starting with one trusted zone key, it is possible to retrieve signed keys for subzones which have them. Every secure zone (except root) should also include the RSA record for its super-zone signed by the secure zone. This makes it possible to climb the tree of zones if one starts below root. A secure sub-zone is generally indicated by Donald E. Eastlake 3rd & Charles W. Kaufman [Page 31] INTERNET-DRAFT DNS Protocol Security Extensions an RSA RR appearing with the NS RRs for the sub-zone. These make it possible to descend within the tree of zones. A resolver should keep track of the number of successive secure zones traversed from a starting point to any secure zone it can reach. In general, the lower such a distance number is, the greater the confidence in the data. Data configured via a boot file should be given a distance number of zero. Should a query encounter different data with different distance values, that with a larger value should be ignored. A security conscious resolver should completely refuse to step from a secure zone into a non-secure zone unless the non-secure zone is certified to be non-secure or only optionally secure by the present of an authenticated RSA RR for the non-secure zone with a zero length modulus or the presence of a non-zero length modulus RSA RR without the mandatory bit set. Otherwise the resolver is probably getting completely bogus or spoofed data. If legitimate non-secure zones are encountered in traversing the DNS tree, then no zone can be trusted as secure that can be reached only via information from such non-secure zones. Since the non-secure zone data could have been spoofed, the "secure" zone reach via it could be counterfeit. The "distance" to data in such zones or zones reached via such zones could be set to 512 or more as this exceeds the largest possible distance through secure zones in the DNS. Never the less, continuing to apply secure checks within "secure" zones reached via non-secure zones will, as a practical matter, provide some increase in security. 7.3 Secure Time Coordinated interpretation of the time fields in SIG RRs requires that secure consistent time be available to the hosts implementing the DNS security extensions. The Network Time Protocol (NTP) [RFC1305] provides an excellent means for coordinating consistent time. It also includes strong security but has no key management provisions. It just assumes that symmetric keying material will be on each pair of communicating nodes. In the absence of security, NTP or other time synchronization protocols could be spoofed. A solution to this would be to do NTP over IP-security. This may seem circular, where the security system is used to protect the synchronization of time needed for the security system. In practice, manual set up of approximate time would be adequate to bootstrap the system which could then securely synchronize itself more accurately. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 32] INTERNET-DRAFT DNS Protocol Security Extensions To accommodate the secure time requirement, all DNS servers should also be NTP servers. NTP assumes that time servers are organized into numbered strata where the servers at each strata are clients to a lower numbered strata and servers to higher numbered strata. This can be accomplished in the DNS context by have each primary or secondary DNS server be an NTP client to the servers up the DNS tree from those zones they provide (ignoring zones that are subzones of other zones the server carries). Stub resolvers or the like could look to their default server for NTP service. Special arrangements would have to been made for the root primary and its secondaries to either have reliable hardware time sources or be secure clients to machines with such sources. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 33] INTERNET-DRAFT DNS Protocol Security Extensions 8. Operational Considerations This section discusses a variety of operational considerations in secure operation of DNS using these proposed protocol extensions. 8.1 Modulus Size Considerations There are a number of factors that effect modulus (key) size choice for use in the DNS security extension. Unfortunately, these factors do not all point in the same direction. Choice of a modulus size should be made by the zone administrator depending on their local conditions. Larger moduluses are more secure but slower. The recommended minimum modulus size, 641 bit, is believed by the authors to be secure at this time and for some years but high level nodes in the DNS tree may wish to set a higher minimum, perhaps 1000 bits, for security reasons. (Since the United States National Security Agency generally permits export of encryption systems using an RSA modulus of up to 512 bits, use of that small a modulus, i.e. n, must be considered weak.) Because this protocol packs information inside an RSA signature, larger moduluses also increase the efficiency of use of space with SIG RRs. There is a 22 byte overhead (prefix and self hash) within the signature plus all the SIG RR fields outside of the signature. However, larger moduluses also lead to larger SIG RRs which may lead to lower packing density of SIG RRs in a maximum length DNS UDP packet. With the minimum modulus size required by this protocol, the signature before RSA encoding is 80 octets (usually resulting in 81 octets after encoding). After deducting 2 octets for the minimum 01 00 signature prefix and 20 octets for a hashed self signet, 56 octets would be available for other signets. With the maximum modulus size permitted by this protocol, the signature is usually 255 octets which leaves 233 bytes for other signets. Zones may wish to adopt policies on the size of host, user, or even subzone keys within them such that the RSA RRs for these keys will fit within a zone signed SIG for efficiency. 8.2 Key Storage It is strongly recommended that zone private keys and the zone file master copy be kept and used in off-line non-network connected Donald E. Eastlake 3rd & Charles W. Kaufman [Page 34] INTERNET-DRAFT DNS Protocol Security Extensions physically secure machines only. Periodically an application can be run to re-sign the RRs in a zone by adding SIG RRs and then the SIG augmented file transferred, perhaps by sneaker-net, to the networked server machine. The idea is to have a one way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. The master copy of the zone file should also be off net and should not be updated based on a solely network mediated communication. 8.3 Key Generation Careful key generation is a sometimes over looked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Suggestions will be found in draft-ietf-security-randomness-01.txt. 8.4 Key Lifetimes No key should be used forever. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. No DNS security extensions key should have a lifetime significantly over five years. The recommended lifetime for zone keys that are kept off-line and carefully guarded is 13 months with the intent that they be replaced every year. The recommended maximum lifetime for host keys that are used for IP-security or the like and are kept on line is 35 days with the intent that they be replaced monthly or more often. 8.5 Key Revocation In cases where an erroneous signed key exists in the DNS system, it is useful to be able to propagate a revocation. In most cases, the natural refresh processes of DNS will eventually obtain valid, up to date key information for secondaries. However, there could be stale information out in caching servers or the like for a long time, particularly since accident or malicious action could have cause RRs, Donald E. Eastlake 3rd & Charles W. Kaufman [Page 35] INTERNET-DRAFT DNS Protocol Security Extensions including SIGs, RSAs, etc., with very long TTLs and/or distant end- times to be distributed. There are limits to how much can be done about this problem. The DNS security extensions provide for revocation of keys. The revocation information is provided when current key information is retrieved. In addition, security aware servers opportunisticly flood revocation information by including it with low priority in the additional information section of any retrieval from the zone containing the revoked key. It is a matter of server policy how to choose which extra revocations to include as additional information. Some revocations may be "more important" than others or it may be best to simply pick as much as will fit at random. On receipt of an authenticated revocation, a resolver should expunge all RRs authenticated by the revoked key. It is a matter of resolver policy what revocations, if any, to cache and for how long. Resolvers can not keep an indefinite number of revocations for an indefinite time. The possibility of denial of service attacks based on fabricating many revocations must be considered. It should be noted that like assertions, revocations have start and end times. Thus, for example, a valid key validly generated but accidentally given an excessive lifetime in a SIG can be revoked for just the later part of that lifetime by setting appropriate times in the revocation SIG RR. 8.6 Root The root zone RSA key is self-signed. It should also be noted that in DNS the root is a zone unto itself. Thus the root key should only be see signing itself or signing RRs with names one level below root, such as .aq, .edu, or .arpa. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 36] INTERNET-DRAFT DNS Protocol Security Extensions 9. Conformance [this section needs work ...] 9.1 Server Conformance Security aware servers MUST respond normally to requests that do not have the Security Desired bit set. Three levels of server conformance are defined as follows: Zilch server compliance is (1) the ability to ignore the Security Requested bit in queries, (2) ability to store and retrieve (incluidng zone transfer) SIG and RSA RRs, and (3) always clearing the Security Available bit in responses. It is believed that almost all current servers meet this level of compliance. Minimal server compliance adds the following to zilch compliance: (1) ability to read SIG and RSA RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG RRs, possibly via a separate application. Primary servers for secure zones must be at least minimally compliant. Full server compliance is ability to handle the Security Desired bit in inquiries, automatically including SIG and RSA RRs in responses as appropriate, as well as meeting the minimal compliance except that only item 2 of zilch criteria should be met. In addition, fully compliant servers MUST turn on the Security Available bit in responses. 9.2 Resolver Conformance - Resolver compliance... Donald E. Eastlake 3rd & Charles W. Kaufman [Page 37] INTERNET-DRAFT DNS Protocol Security Extensions 10. Security Considerations The entirety of this document concerns extensions to the Domain Name System (DNS) protocol to provide data origin authentication, DNS transaction authentication, and key storage. References [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 June 1991, Version 1.4. [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 [RFC1033] - Domain Administrators Operations Guide, M. Lottor, November 1987 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987 [RFC1035] - Domain Names - Implementation and Specifications [RFC1305] - Network Time Protocol (v3), D. Mills, April 9 1992 [SHS] - NIST FIPS PUB 180, Secure Hash Standard, National Institute of Science and Technology, U.S. Department of Commerce, April 1993. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 38] INTERNET-DRAFT DNS Protocol Security Extensions Authors Addresses Donald E. Eastlake 3rd Digital Equipment Corporation 550 King Street, LKG2-1/BB3 Littleton, MA 01460 Telephone: +1 508 486 6577(w) +1 508 287 4877(h) EMail: dee@lkg.dec.com Charles W. Kaufman Digital Equipment Corporation 110 Spit Brook Road, ZKO3-3/U14 Nashua, NH 03062 Telephone: +1 603-881-1495 EMail: kaufman@zk3.dec.com Expiration and File Name This draft expires 22 September 1994 Its file name is draft-ietf-dnssec-secext-01.txt. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 39]   Received: from sol.tis.com by magellan.TIS.COM id aa12569; 23 Mar 94 11:54 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25829; Wed, 23 Mar 94 11:53:45 EST Received: by relay.tis.com; id AA19132; Wed, 23 Mar 94 11:53:17 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma019126; Wed Mar 23 11:52:19 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA05235; Wed, 23 Mar 94 08:49:55 -0800 Received: by skidrow.lkg.dec.com (5.65/DEC-Ultrix/4.3) id AA07406; Wed, 23 Mar 1994 11:51:04 -0500 Message-Id: <9403231651.AA07406@skidrow.lkg.dec.com> To: internet-drafts%cnri.reston.va.us@inet-gw-1.pa.dec.com Cc: dns-security%tis.com@inet-gw-1.pa.dec.com Subject: Revised dns-secext draft Date: Wed, 23 Mar 94 11:51:04 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp The following mail is stuck on the mail queue at skidrow.lkg.dec.com due to a configuration error. You will also get another copy if/when that problem is fixed. Hopefully I've addressed this copy to get around the problem. Donald ------- Forwarded Message Forwarded: Wed, 23 Mar 94 11:37:00 -0500 Forwarded: internet-drafts%cnri.reston.va.us@relay.dec.com Forwarded: dns-security%tis.com@relay.dec.com Return-Path: dee To: Internet Drafts Cc: dee, Charlie Kaufman , dns-security@tis.com Subject: Revised dns-secext draft Date: Wed, 23 Mar 94 03:43:38 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Hi, Here is an improved of our DNS Security Extensions drafts. Sorry to get this in so close to IETF... Donald - --------------------------------------------------------------------------- Donald E. Eastlake, III DTN: 226-6577(w) dee@lkg.dec.com 550 King St, LKG2-1/BB3 1-508-486-6577(w) dee@ranger.enet.dec.com Littleton, MA 01460 USA 1-508-486-7417(fax) 1-508-287-4877(h) INTERNET-DRAFT DNS Protocol Security Extensions 23 March 1994 Expires 22 September 1994 Domain Name System Protocol Security Extensions ------ ---- ------ -------- -------- ---------- Donald E. Eastlake 3rd & Charles W. Kaufman Status of This Document This draft, file name draft-ietf-dnssec-secext-01.txt, is intended to be become a standards track RFC. Distribution of this document is unlimited. Comments should be sent to the DNS Security Working Group mailing list or to the authors. This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions Abstract The Domain Name System has become a critical operational part of the Internet infrastructure yet it has no security mechanisms to assure data integrity or authentication. Extensions to the DNS protocol are proposed to provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are added to secured zones as resource records. They can be most efficiently handled by security aware servers but security can still be provided to security aware resolvers or applications even by non-security aware secondary or caching servers. In addition, the extensions provide for the storage of authenticated keys in the DNS, so that a security aware resolver can learn the authenticating key of zones in addition to those for which it is initially configured, and for other purposes. Finally, the extensions optionally provide for authentication of DNS protocol transactions for additional security. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................5 2. Overview of the Protocol...............................5 2.1 Data Origin Authentication.............................5 2.1.1 Security Provided...................................5 2.1.2 The SIG Resource Record..............................6 2.1.3 The RSA Resource Record..............................7 2.1.4 Signers Other Than The Zone..........................7 2.1.5 Special Problems With Time-to-Live...................7 2.1.6 Improved Performance At The Expense Of Compatibility.8 2.2 DNS Transaction Authentication.........................9 3. Services, Requirement, and Non-Requirements............10 3.1 Requirements..........................................10 3.2 Non-Requirements......................................12 4. The Security Desired & Security Available Bits.........13 5. The SIG Resource Record................................14 5.1 SIG RDATA Format......................................14 5.1.1 SIG Flag Bits.......................................15 5.1.2 Signature Format....................................15 5.1.3 Signet Format.......................................16 5.1.3.1 Direct Resource Record Signets....................17 5.1.3.2 Direct Glue Record Signet.........................18 5.1.3.3 Hashed Resource Record(s) Signet..................18 5.1.3.4 Partial RR Set Flag Signet........................19 5.1.3.5 Partial SIG Set Flag Signet.......................20 5.1.3.6 AXFR Signets......................................20 5.1.3.7 Message Hashed Signets............................21 5.1.3.8 Reserved Signet Prefixes..........................21 5.2 SIG RRs in the Construction of Responses..............22 5.3 Processing Responses with SIG RRs.....................23 5.4 File Representation of SIG RRs........................24 5.4.1 Size of Data........................................24 5.4.2 RR Numbering........................................24 5.4.3 SIG RR Scope........................................25 5.4.4 RRs Supressed by a SIG RR...........................25 5.4.5 Indicating Revocation...............................25 6. The RSA Resource Record................................27 6.1 RSA RDATA format......................................27 6.2 Types of DNS Names and Keys...........................27 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions 6.3 RSA RR Flag Bits......................................28 6.4 RSA RRs in the Construction of Responses..............29 6.5 File Representation of RSA RRs........................29 7. How to Resolve Securely................................31 7.1 Boot File Format......................................31 7.2 Chaining Through Zones................................31 7.3 Secure Time...........................................32 8. Operational Considerations.............................34 8.1 Modulus Size Considerations...........................34 8.2 Key Storage...........................................34 8.3 Key Generation........................................35 8.4 Key Lifetimes.........................................35 8.5 Key Revocation........................................35 8.6 Root..................................................36 9. Conformance............................................37 9.1 Server Conformance....................................37 9.2 Resolver Conformance..................................37 10. Security Considerations...............................38 References................................................38 Authors Addresses.........................................39 Expiration and File Name..................................39 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 4] INTERNET-DRAFT DNS Protocol Security Extensions 1. Introduction [To be written] 2. Overview of the Protocol These DNS protocol extensions provide two distinct services: data origin authentication, described in section 2.1 below, and message authentication, described in section 2.2 below. In addition, the resource records added to support these authentication services permit the association of keys with DNS names. These keys could be used in support of other security services such as IP level security in addition to supporting DNS zone security. 2.1 Data Origin Authentication There are two distinct aspects to the data origin authentication service. The purpose of the first is to add security; the purpose of the second is to improve performance when the first is used. Adding security requires no changes to the "on-the-wire" DNS protocol beyond the addition of two new resource types: signatures and keys. This service could be supported by existing resolver and server implementations so long as they could support the additional resource types. If signatures are always retrieved and verified when retrieving the information they authenticate, there will be more trips to the server and performance will suffer. The revisions to the DNS wire protocol for security aware servers are an attempt to mitigate that degradation by automatically sending exactly the signatures needed and by skipping the sending of the data if it can be derived from the signature. 2.1.1 Security Provided Security is provided by associating with each item of information in DNS a cryptographically generated digital signature. Commonly, there will be a single RSA key that signs for an entire zone. If the resolver reliably learns the public RSA key of the zone, it can verify that all the data read was properly authorized and is reasonably current. The expected implementation is for the zone private key to be kept off-line and used to re-sign all of the records in the zone periodically. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 5] INTERNET-DRAFT DNS Protocol Security Extensions The data origin authentication key belongs to the zone and not to the servers that store copies of the data. That means compromise of a server will not affect the degree of assurance that a resolver has that the data is genuine. However, such a server can (except in the case of a zone transfer) claim that a name does not exist and a resolver may not be able to determine otherwise. A resolver can learn the public key of a zone either by having it manually configured or by reading it from DNS. To reliably learn the public key by reading it from DNS, the key itself must be signed. Thus to provide a reasonable degree of security, the resolver must be configured with at least the public key of one zone. From that, it can securely read the public keys of other zones. It is in principle more secure to have the resolver manually configured with the public keys of multiple zones, since then the compromise of a single zone would not permit the faking of information from other zones. It is also more administratively cumbersome, however, particularly when public keys change. 2.1.2 The SIG Resource Record The syntax of a SIG resource record (signature) is described in Section 5. It includes the name of the signer, the time at which the signature was created, the time it expires (when it is no longer to be believed), its original time to live (which may be longer than its current time to live but cannot be shorter), some flags, and an RSA (Rivest, Shamir, and Adelman [RSA]) signature. There are a number of unusual aspects to the construction of the RSA signature that are intended to maximize performance in this application. Unlike some other digital signature schemes like El Gamal or DSS, RSA signatures have the property that when a signature is verified, it produces a message that is almost the size of the signature itself. In most uses, for example Privacy Enhanced Mail, the message to be signed is much larger than the signature (which is generally 64-256 bytes long), so a message digest of the message is computed (a 16-20 byte "fingerprint") and that quantity is signed. For DNS, however, it will be common that the messages being signed, will be very short - sometimes shorter than 16-20 bytes - particularly with the abbreviation techniques used herein. Further, there are commonly multiple resource records associated with a DNS name, and it should be efficient to verify a signature on a single one of those records or any subset of them. If a 64-256 byte signature record were created for every resource record, there would be an unacceptable explosion of data. The SIG resource record syntax proposed therefore has two unusual Donald E. Eastlake 3rd & Charles W. Kaufman [Page 6] INTERNET-DRAFT DNS Protocol Security Extensions properties: (1) when it signs a resource record, it may contain either the resource record itself or a message digest of the resource record; and (2) a single signature may sign multiple multiple resource records associated with a single name. Every name in a zone supporting signed data will have associated with it one or more SIG resource records - as many as required to sign all of the non-SIG resource records. A security aware server supporting the performance enhanced version of the DNS protocol security extensions will return with all records retrieved the corresponding SIG records. If a server does not support the protocol, the resolver must retrieve all the SIG records for a name, verify them all, and find the one or ones that sign the resource records that resolver is interested in. As a further optimization, a server supporting the performance enhanced version of the protocol will return only the signature - and skip the requested data - in the case where the signature contains enough information to reconstruct the data in full. Because of this, in some cases the authenticated data being sent via SIG records can be shorter than the plain data would have been. 2.1.3 The RSA Resource Record The syntax of an RSA resource record (key) is described in Section 6. It is present for two reasons: to support the DNS infrastructure itself so that a resolver that is manually configured with the public keys of one or more zones can securely learn the public keys of other zone; and to allow the storing of RSA public keys of DNS-named entities other than zones for applications like IP-Security. 2.1.4 Signers Other Than The Zone There are two cases where a signature is generated by other than the zone private key. One is for future support of dynamic update where an entity is permitted authenticate/update its own record. The public key of the entity must be present in the DNS and signed with the zone key, but the other RRs may be signed with the entity's key. The other is for support of message authentication as described in 2.2 below. 2.1.5 Special Problems With Time-to-Live A digital signature will fail to verify if any change has occurred to the data between the time it was originally signed and the time the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 7] INTERNET-DRAFT DNS Protocol Security Extensions signature is verified. This conflicts with our desire to have the time-to-live field tick down when resource records are cached. This could be avoided by leaving the time-to-live out of the digital signature, but that would allow unscrupulous secondaries to set arbitrarily long time to live values undetected. Instead, we include the "original" time-to-live in the signature and communicate that data in addition to the current time-to-live. Unscrupulous servers under this scheme can fail to decrement time to live, but they cannot increase it beyond its original value. Separately, signatures include a time signed and an expiration time. A resolver that knows an absolute time can determine securely whether a signature has expired. In order to keep the data as compressed as possible, we don't want to have to include the original TTL for every resource record included in a SIG when usually they are all the same. We therefore assume that the original TTL is equal to the original TTL of the SIG resource record (which is sent for every SIG resource record), and in the rare case where the TTL on the other resource record differs we permit it to be explicitly included. 2.1.6 Improved Performance At The Expense Of Compatibility To run the high performance version of the protocol, the server should remember for each resource record: (1) which SIG record includes the signature for that record and (2) whether the SIG record contains the resource record in full or in digested form. When the server is responding to a request, it should for each record requested return the corresponding SIG (removing duplicates) and also it should suppress the sending of the record itself if it is present in the signature in undigested form. Since a resolver running the secure protocol will not believe any record that is not signed, there would be no point in returning the record without the SIG. And if the resolver is going to see the RR in full in the course of verifying the signature there is no point in wasting bandwidth by sending the RR being authenticated. The high performance version of the protocol can only be used if both resolver and server understand it. Negotiation is done via some DNS message header bits we believe that existing servers will ignore and existing resolvers will not set. If signature verification is not done by the DNS resolver code but rather by some application that is retrieving resource records through that resolver, the standard protocol must be used. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 8] INTERNET-DRAFT DNS Protocol Security Extensions 2.2 DNS Transaction Authentication The data origin authentication service described above protects resource records but provides no protection for message headers and limited protection against resource record addition to or deletion from a message. If header bits or, in some cases, the resource record set in a response, are falsely set by a server, there is little that can be done. However, it is at least possible to add transaction authentication. Such authentication means that a resolver can be sure it is getting messages from the server it thinks it queried and that the response if from the query it sent and that these messages have not been diddled in transit. This is accomplished by adding a SIG resource record to end of the reply which digitally signs the message by the server and includes a hash code of the query. The private key used belongs to the host composing the reply, not to the zone being queried. The corresponding public key is stored in and retrieved from the DNS. Because replies are highly variable, message authentication SIGs can not be precalculated. Thus it will be necessary to keep the key on- line, for example in software or in a directly connected piece of hardware. The best way to get the security provided by the transaction authentication service would be to use a good IP level security protocol. The authors of this draft decry the every growing number of IP application level security protocols such as Telnet, NTP, FTP, etc., etc. when a single IP-security protocol could secure most of these applications. Unfortunately, an IP-security standard has not yet been adopted. And even if it had, there will be many systems for many years where it will be hard to add IP security but relatively easy to replace the DNS components. Furthermore, the data original authentication service requires the implementation of essentially all the mechanisms needed for a rudamentary message authentication service. Thus a simple transaction authentication service using mechanisms already required by DNS security is included as a strictly optional part of these extensions. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 9] INTERNET-DRAFT DNS Protocol Security Extensions 3. Services, Requirement, and Non-Requirements This section is based on the 19 November 1993 email message from James M. Galvin summarizing the Houston IETF meeting of the DNS Security BoF. At this meeting a list of requirements, shown in 3.1 below, and non-requirement shown in 3.2 below, were arrived at. The security services desired were set at the following: data integrity, and data origin authentication. It was noted at that meeting that these services can be provided by digital signatures. 3.1 Requirements The numbered items below were determined to be "requirements", not in the sense of being mandatory but in the sense of all being highly desirable. A comment appears after each requirement as to if/how it is met by this proposal. <1> Sites must be able to support at least their internal users in the presence of external network failures. Security aware resolvers can be configured with the public key of their local apex zone. The needed SIG RRs can be added to that zone and any desired lower level zones either off-line or on-line. Thus this requirement is met. <2> it should be possible for a site to pre-configure other authoritative servers without having to query the "system" to find the server. Security aware resolvers can be configured with the public key of any other zones and the IP address of their servers. <3> It should be possible to request services only from security enhanced servers, only from non-security enhanced servers, or a indicate that either is acceptable. These proposed protocol extensions do not provide any enhancement to the NS RR or otherwise to indicate whether or not a server is security aware without actually querying it. It is believed that this additional complexity is not warranted. Non-security aware servers can still support security aware resolvers, although less efficiently. It is possible to tell if a server is security aware by the SA (Security Available) bit in the header of its responses. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 10] INTERNET-DRAFT DNS Protocol Security Extensions <4> It should be possible to recognize security enhanced responses. Security enhanced responses can be recognized by the presence of SIG RRs. <5> It should be possible to assign cryptographic keys (make use of the security services) to leaf nodes in the DNS tree, i.e., fully qualified domain names. The proposed extensions allow RSA key RRs to be associated with any node in the DNS tree. Indeed, more than one key can be associated with a node whose name serves multiple functions. <6> It should be possible to not trust secondary servers. The proposed extensions can be implemented so that the zone private key is never on line on the network. Thus, ignoring denial of service threats, it is possible to have untrusted secondaries and even untrusted primaries. <7> A mechanism must exist for revoking cryptographic keys that works within the DNS time-to-live framework. A bit is defined in the SIG RR to indicate if it is an assertion or revocation. This applies to keys (RSA RRs) and such key revocations are opportunisticly flooded as additional information on every query to their zone if the resolver and server are security aware. However, an additional mechanism may be necessary to notify secondaries, caching servers, etc. to assure that a revocation is noticed within the TTL. This is really just a special case of a change in zone information and a general mechanism such as the NOTIFY operation described in draft-ietf-dns-ixfr-01.txt could be used. However, guaranteed revocation is not possible (for example in a partitioned network) without introducing unacceptable denial of service risks (such as having to wait "forever" to get a current "key revocation list" for a zone if the network is partitioned). <8> Security services should be supported with no additional DNS queries beyond what would be required if security was not supported. No additional queries are required, barring possible UDP truncation problems, to obtain authentication from or to securely learn the public key for a zone when its names servers are being obtain if a security enhanced server is being used by a security aware resolver. <9> It must be possible to ensure that cached data expires according to its TTL. A security aware resolver has both the TTL for an RR and the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 11] INTERNET-DRAFT DNS Protocol Security Extensions expiration time of the SIG covering the RR. Cached data is always invalid after the SIG expiration time plus the original TTL. 3.2 Non-Requirements It was explicitly decided by the DNS Security BoF at the Houston IETF meeting that the following were not requirements: <1> Confidentiality: DNS data is "public" and no effort need be made to provide encryption of queries/responses. (This service may be available via an IP level security protocol which is currently being worked on by the IP Security Working Group of the IETF .) <2> Access control: DNS data is "public" and no effort need be made to provide access control lists, or similar mechanisms, as part of this DNS security effort. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 12] INTERNET-DRAFT DNS Protocol Security Extensions 4. The Security Desired & Security Available Bits The header section of DNS messages is modified to define bits 9 and 10 in the second word (fourth octet). These were formerly the top two bits of the Z field defined as "Reserved for future use." [RFC1035] These bits are defined as security desired, labeled SD, and security available, labeled SA. With the definition of these bits, the header looks like the following: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | QR| Opcode | AA| TC| RD| RA| SD| SA| Z | RCODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | QDCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ANCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | NSCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ARCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ All fields are as before except that the Z field is reduced to one bit and SD and SA are defined as follows: SD Security Desired - this bit may be set in a query. If the server to which the query is sent does not support the DNS security protocol, the bit should be ignored except that it may be copied into the response. If the server does support this protocol, the bit MUST copied into the response and, if the bit is set, the server MUST provide any SIG and RSA RRs as described in the sections below concerning these RRs. SA Security Available - this is to be set or cleared in a response. If set, it indicates that the server fully supports this security protocol. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 13] INTERNET-DRAFT DNS Protocol Security Extensions 5. The SIG Resource Record The SIG or "signature" resource record (RR) is the fundamental way that resource records (and optionally message) are authenticated. The SIG RR unforgably binds one or more other RRs (or a DNS message) to a time and the signer's fully qualified domain name using cryptographic techniques and the signer's private key. The signer is the owner of the zone the RR originated from (or the composer of the authenticated DNS message). 5.1 SIG RDATA Format The RDATA portion of a SIG RR is as shown below. The integrity of the RDATA information and that of the SIG RRs owner, type, and class are protected by the signature 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signer's name | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time signed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key footprint | flags | sig length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of the SIG type is xxx. The "signer's name" field is the fully qualified domain name of the signer generating the SIG RR. This is the zone which contained the RR(s) being authenticated (or the host which is the source of a DNS reply that is being authenticated). The "original TTL" field is included in the RDATA portion to avoid authentication problems that caching servers would otherwise cause by decrementing the real TTL field and security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field. This original TTL is protected by the signature while the real TTL field is not. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 14] INTERNET-DRAFT DNS Protocol Security Extensions The "time signed" field is an unsigned number of seconds since the start of 1 January 1970. The SIG is valid until the signature expiration time which is a field of the same format as the time signed. The "key footprint" is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the lest significant 24 bits of this quantity. In cases where multiple keys may be applicable, it can be used to efficiently pick the right one in most cases. The "flags" octet is described below. The "sig length" field is an unsigned 8 bit count of the number of octets in the signature field. The structured of the "signature" field is described below. [It would be possible to allow additional optional fields after the above in the SIG RR as described in draft-ietf-dns-ixfr-01.txt] 5.1.1 SIG Flag Bits Bits 0 to 6 are reserved and must be zero. Bit 7 (the least significant bit) a zero means the SIG RR asserts the validity of the RR it signs from the start to the end time, inclusive. If it is a one, the RSA RR is a revocation of the RR as above. 5.1.2 Signature Format The actual signature portion of the SIG RR binds the owner, signer, class, original TTL, time signed, and expiration time of the RR to one or more RRs (or DNS messages) being authenticated. To accomplish this, it contains at least one "signet", as defined in the following section, and a "self-hash" field covering the above items. The structure of signets is described in section 5.1.2 below. The signature is then calculated using the RSA public key system as follows s = ( 01 | FF* | 00 | signets | self-hash ) ** e (mod n) where "|" is concatenation. "signets" is the concatenation of the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 15] INTERNET-DRAFT DNS Protocol Security Extensions signets included in this signature. "self-hash" is the 20 octet hash using the Secure Hash Standard [SHS] of the SIG RR name, class, signer name, original TTL, time signed, expiration time, key footprint, and flags. "e" is the secret key exponent of the signer, and "n" is the public modulus that is the signer's public key. 01, FF, and 00 are fixed octets of the corresponding hexadecimal value. The FF octet is repeated the maximum number of times such that the value of the quantity being exponentiated is less than the value of n. No FF octets need occur if "signets" is long enough. The order of the signets is not significant. The size of n, including most and least significant bits (which will be 1) SHALL be at least 641 and not more than 2040. n and e MUST be chosen such that the public exponent is less than 2**24 - 1 and SHOULD be chosen such that the public exponent is small. The above specifications are similar to PKCS #1 [PKCS1] except that, under most circumstances, one additional byte of data is allowed. (A public exponent of 3 minimizes the effort needed to decode a signature. Use of 3 as the public exponent may be weak for confidentiality uses since, if the same data can be collected encrypted under three different keys with an exponent of 3 then, using the Chinese Remainder Theorem [ref], the original plain text can be easily recovered. This weakness is not significant for DNS because we seek only authentication, not confidentiality.) 5.1.3 Signet Format Each signet consists of a prefix octet, with which the length of the signet can be unambiguously determined, followed by the signet data. Signet's are of three basic types: hashed, direct, and flag. A hashed signet consists of the prefix octet, some additional data, and a 20 bit hash of the data covered using the Secure Hash Standard [SHS]. Since this hash algorithm is not invertible, the data, such as RRs, covered by a hashed signet must also be included in the reply to a query if it was requested. A direct signet includes all of the data it covers. Some of the data may be implicit or compressed but it is all unambiguously recoverable. If a direct signet is present covering an RR, then that RR SHOULD be supressed from the reply message if the SD bit is on in the query and the server is security aware. Flag signets occur with direct signets and multiple SIG RRs. They are used to determine if a complete set of RRs of a particular Donald E. Eastlake 3rd & Charles W. Kaufman [Page 16] INTERNET-DRAFT DNS Protocol Security Extensions variety are present. Signet prefix octets are as follows: 0000000* Illegal 0LLLLLLL Direct Resource Record - type & rdata 10LLLLLL Direct Glue Record - name, type, & rdata 110***** (reserved) 1110**** (reserved) 11110NHT Hashed RR(s) - N, type, T, & hash 11111000 Partial SIG Set Flag 11111001 Partial RR Set Flag 11111010 Hashed query message 11111011 Hashed response message 1111110* (reserved) 1111111* Illegal In the above table, "*" represents 0 or 1 and L, N, H, and T are bits whose meaning is defined in the signet descriptions below. The illegal prefixes should never occur. Any signature that appears to include one should be considered invalid. 5.1.3.1 Direct Resource Record Signets This signet is an actual RR but with some fields supressed. In order to avoid inconsistencies, all RRs of the same type and class have to have the same TTL, at least for currently defined RRs. SIG RRs need not survive beyond the RRs they authenticate but must live as long as the covered RRs do. Thus SIG RRs may be constrained to having the same TTL as the RRs they cover in most cases. The SIG RR will always have the same class and name as the RRs it covers (except for glue RRs as described in 5.1.3.2 and 5.1.3.3 below). Finally, the signet data length in the prefix octet can be used to calculate the RDSIZE. Thus RRs directly represented by this variety of signet are compressed by omitting their name, class, TTL, and RDLENGTH fields. Only the type, and RDATA are present. For example, the direct signet for a type A record in the IN (Internet) class would be seven octets as follows: 06 00 01 xx yy zz ww where 06 is the prefix indicating a direct RR signet with six data octets, 00 01 is hex for the type code for type A, and xx yy zz ww is the 32 bit IP address from the RR. These 7 octets in a SIG RR completely represent the 15+ (1+ name, 2 type, 2 class, 4 TTL, 2 rdlength, 4 ip address) octets of the original type A RR. The class, name, and TTL are all recoverable from the same fields of the SIG RR whose signature field includes this signet. Thus the original type A RR can be supressed from the answer if given to a security aware Donald E. Eastlake 3rd & Charles W. Kaufman [Page 17] INTERNET-DRAFT DNS Protocol Security Extensions resolver. Note that any names in the RDATA area of this type of signet can not be abbreviated by pointers outside of the reconstructed RR. That is because the SIG RR and its signets are frozen at the time the signature is encrypted under the signer's private key and this frozen SIG may then be used in a variety of DNS messages. The RDATA area may, however, if it has multiple names, abbreviate them by references to earlier names within the reconstructed RR. The direct representation of RRs makes maximum use of the relatively large size of RSA digital signatures for common cases. The direct representation also avoids the computational effort of calculating a hash code. Because the original RR's type field must always be present, the minimum length of the data after this type of signet prefix is 2, thus prefixes of 00 and 01 hex are illegal. The maximum size direct RR signet is 128 octets. All RRs need not be included within a signature using this direct signet. If the data portion of a direct RR signet exceeds 22 octets (i.e., a total signet size of 23 octets including the prefix count octet), space inside the signature can be saved by going to the hashed RR signet described below. If an RR compressed for a direct signet exceeds 127 bytes or the amount of space available for signets in the signature part of a SIG RR, then it must appear separately and be authenticated by a hashed RR signet. 5.1.3.2 Direct Glue Record Signet Glue records must be handled a little differently. These are currently always A records with a name which usually isn't even in the zone being handled but are associated with an RR in the zone. This type of signet allows such glue RRs to be included within a SIG. The direct glue record signet is just like the direct resource record signet described above except that the name is included right after the prefix and before the type and RDATA. If the Glue Record signet won't fit, a hashed RR signet, described below, must be used. Note that names in the DNS can be up to 256 bytes long which would not fit inside a SIG RR signature field. 5.1.3.3 Hashed Resource Record(s) Signet RRs can also be protected by a signet with a hash code. If a hashed signet is used, all RRs of the same name, type, class, and TTL MUST Donald E. Eastlake 3rd & Charles W. Kaufman [Page 18] INTERNET-DRAFT DNS Protocol Security Extensions be hashed into a single signet. To avoid inconsistencies, RRs of the same name, type, class, and TTL must either all be present or all be absent. Thus a single hash code covering such multiple RRs is all that is required. The signet is then formed by a single octet 11110NHT (binary) prefix followed by a possible name field depending on "N" and "H" as described below, the two octet type for the RRs covered, a possible TTL field depending on the values of "T" described below, and then the 20 octet hash code. The hash is calculated by concatenating the full RRs, with all names fully expanded and any required RDLENGTH adjustments made, in a canonical order, and applying the Secure Hash Standard [SHS]. The canonical order for RRs is to sort them in ascending order as left justified unsigned octet sequences where a missing octet sorts before a zero octet. Thus the hex sequences FE 01 02, 07, FF 03, FE FD, FF, and 01 01 01 01 would sort and be concatenated into the sequence 01 01 01 01 07 FE 01 02 FE FD FF FF 03. The "N" bit in the prefix stands for Name. It is normally zero because almost all RRs associated with a name in a zone have that name. The exception is glue records. These are currently A records with owner names outside the zone. To be able to cover these in a SIG for a different name where they cannot be included as a direct glue record signet as discussed in the section above, the N bit makes it possible to include the different name in the signet immediately after the prefix. If the N bit is a one but the H bit is zero, the name is included in full. Because names in DNS can be up to 256 bytes long, the 20 byte hash of the full name, using the Secure Hash Standard, can be used instead of the actual name and is indicated by turning on the H (or "hash") bit. To match this against RRs in the reply, their names must be hashed and compared. The "T" bit in the prefix stands for TTL. It is normally zero. For the presently defined RRs, all RRs of the same type, class, and name should have the same TTL. Future RRs may be defined for which it is useful for such RRs to have different TTL's. In that case the T bit must be one in the signet prefix octet, and the TTL of the hashed RR(s) included after the two octet type and before the hash code. If both the N and T bits are on, the name appears immediately after the prefix byte followed by the type, then the TTL, then the 20 byte hash code. This is the standard order for these fields in an RR. 5.1.3.4 Partial RR Set Flag Signet Verification of a hashed RR signet against the RRs included in the hash provides a guarantee that none have been omitted. The same Donald E. Eastlake 3rd & Charles W. Kaufman [Page 19] INTERNET-DRAFT DNS Protocol Security Extensions assurance is not provided by the direct RR signet unless all of the direct RR signets of the same type and class are included in one SIG RR. If direct RR signets are split over more than one RR, they MUST be covered by a partial RR set flag signet in each RR. The partial RR set flag signet is indicated by a hex F8 prefix followed a two octet type and then by a count octet. The most significant 4 bits (nibble) of this count octet indicates one less than the total number of SIG RRs that include all of the direct signets for the variety of RRs in question. The least significant nibble is used to distinguish the different SIG RRs required and varies from zero through the value of the first nibble. It is permissible, but unnecessary, to include a partial RR set flag signet prefix followed by the type and a zero byte (i.e., 1 of 1) in the SIG RR containing direct signets for all RRs of a particular varient. For example, an signet of F8000131 (hex) means the SIG RR is the 2nd of the 4 SIG RRs covering A type RRs. Should there be a case where more than 16 SIG RRs could be required to hold the direct signets for a particular variety of RR, direct signets may not be used. The RRs must appear directly in the DNS answer and a hashed signet must be used for authentication. 5.1.3.5 Partial SIG Set Flag Signet Since the SIG RRs for an owner name are not in themselves covered by yet another SIG (except for the case of zone transfers), a malicious server might choose to provide only some of them in response to a query for SIG RRs. The partial RR set flag signet defined above is not guaranteed to help here. The signet prefix of hex F9 is followed by an unsigned byte which is one less than the total number of SIG RRs associated with the name and a second unsigned byte which varies from zero through the value of the first byte. It is permissible, but unnecessary, to include a partial SIG set flag signet prefix followed by two zero bytes (i.e, 1 of 1) if only one SIG RR is associated with a name. More than 256 SIGs many not be associated with the same name and class. 5.1.3.6 AXFR Signets To secure zone transfers, a SIG under the zone name will have a hashed RR signet with the AXFR type. It will be calculated by Donald E. Eastlake 3rd & Charles W. Kaufman [Page 20] INTERNET-DRAFT DNS Protocol Security Extensions hashing together all other static zone RRs, including SIGs. The RRs are ordered and concatenated for hashing as described in Section 5.1.3.3. This SIG, other than having to be calculated last of all zone key signed SIGs in the zone, is the same as any other SIG. It can contain non-AXFR signets, be numbered with the partial SIG set flag signet along with other zone level SIGs, if any, etc. Dynamic zone RRs which might be added by some future dynamic zone update protocol and signed by an end entity key rather than a zone key (see Section 6.2) are not included. They originate in the network and will not, in general, be migrated to the recommended off line zone signing procedure (see Section 8.2). Thus such dynamic RRs are not directly signed by the zone and are not generally protected against omission during zone transfers. 5.1.3.7 Message Hashed Signets The response message signet consists of the FA (hex) prefix followed by the 20 byte SHS hash of the entire response message before the SIG, including the header. The query signet consists of the FB (hex) prefix followed by the 20 byte SHS has of the entire query that produced this response, including the query's header. Verification of the transaction authentication SIG, which is signed by the server host key, not the zone key, and the message signets within it by the requesting resolver show that the query and response were not tampered with in transit, that the response corresponds to the intended query. 5.1.3.8 Reserved Signet Prefixes A number of signet prefixes are reserved for future allocation by the Internet Assigned Numbers Authority (IANA). All such signets will have an unsigned length octet immediately following their prefix code. This will be the length of the signet data not including the prefix or length octets. Thus their length can be unambiguously determined. Such signets are not to be generated by any implementation except for a use for which they have been allocated by IANA. Such signets are to be ignored on receipt by any implementation which does not understand them. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 21] INTERNET-DRAFT DNS Protocol Security Extensions 5.2 SIG RRs in the Construction of Responses SIG RRs MUST NOT be sent in response to a query where the SD header bit is clear unless the query specifically requests the SIG type. When the SD header bit is set, the DNS server MUST, for every RR the query will return, attempt to send the available SIG RRs which authenticate the requested RR. If multiple such SIGs are available, there may be insufficient space in the response to include them all. In this case, SIGs whose signer is the zone containing the RR MUST be given highest priority and retained even if SIGs with other signers must be dropped. Furthermore, this automatic inclusion of SIGs in a response is NOT additional information RR processing. To minimize possible truncation problems, if a SIG covers any RR that would be in the answer section of the response, it MUST appear in the answer section. If it covers an RR that would appear in the authority section and does not cover any answer section RR, it MUST appear in the authority section. If it covers an RR that would appear in the additional information section and does not cover any answer or authority section RR, it MUST appear in the additional information section. In many cases, as described below, the full authenticated RR will be included inside the SIG RR. In such cases, the DNS server SHOULD send only the SIG and supress the directly requested RR. The server should assume that the inquirer has the necessary public key to authenticate RRs with the SIG and that, in general, an RR not covered by a SIG may be considered worthless by the inquirer. However, if a SIG including a full RR or an RR and its authenticating SIG will not fit in a response, but the RR alone will, a server MAY send the unauthenticated RR notwithstanding the set SD bit in the query header. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section. Such SIG RRs are signed by the DNS server originating the response. The transaction authentication SIG contains a response message hashed signet and a query message hashed signet. Although the signer field must be the name of the originating server host, the name, class, TTL, and original TTL, are meaningless. To save space, the name should be root (a single zero byte) and the class and TTL fields can be zero. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 22] INTERNET-DRAFT DNS Protocol Security Extensions 5.3 Processing Responses with SIG RRs If SIG RRs are received in response to a query specifying the SIG type, no special processing is required but a security aware client may wish to authenticate them by decoding the signature and applying consistency checks. If SIG RRs are received in any other response, a security aware client should decoded them using the public key of the signer and the data coded into the signature should be carefully examined. It should start with a 01 FF* 00 octet sequence (a 01 octet, zero or more FF octets, and a 00 octet) followed immediately by one or more concatenated signets and ending with the 20 byte self hash field matching the hash of the relevant SIG RR fields outside of the signature. If the decoded signature can not be parsed or the self hash check fails, the SIG RR is invalid and should be ignored. The time of receipt of the SIG RR must be in the inclusive range of the time signed and the signature expiration but the SIG can be retained and remains locally valid until the expiration time plus the range authenticated TTL. Next, the contents of the one or more direct, hashed, or flag signets present should be examined. For all direct RR signets, the original RR should be reconstructed if they are of a type that should have been retrieved by the query. If they are of another type, they can be optionally reconstructed or ignored. For all reconstructed RRs, there must be a complete set of partial set flag signets or all must be included in one SIG. For hashed RR signets, the hash should be computed from RRs present in the response and compared for authentication. Hashed RR signets for a type not requested in the query must be ignored. If the SIG RR is the last RR in a response in the additional information section, it may contain hashed response and query message signets covering the preceding data in the response and the query that produced the response. These should be checked and the message rejected if the checks fails. But even it the check succeeds, such a transaction authentication SIG it does NOT authenticate any RRs in the message. Only proper direct or hashed RR signets signed by the zone can authenticate RRs. If all reasonable checks indicate that the SIG RR is valid then RRs reconstructed or verified by hash should be considered authenticated and all other RRs in the response should be considered with suspicion. The probability that a SIG RR that has been tampered with (without knowledge of the secret key) will pass reasonable checks is vanishingly small (less than 1 in 2**150). Donald E. Eastlake 3rd & Charles W. Kaufman [Page 23] INTERNET-DRAFT DNS Protocol Security Extensions 5.4 File Representation of SIG RRs A SIG RR covering RRs can be represented as a single logical line in a zone data file [RFC1033] but there are some special problems as described below. (It does not make sense to include a transaction authenticating SIG RR in a file as it is a transient authentication that must be calculated in real time by the DNS server.) 5.4.1 Size of Data There is no particular problem with the signer and times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59). The original TTL and flags fields appears as unsigned integers. The key footprint appears as an eight digit unsigned hexadecimal number. However, the signature itself can be up to 255 octets. It is the last data field and is represented in hex and may be divided up into any number of white space separated substrings, down to single hex digits, which are concatenated to obtain the full signature. These hex substrings can be split between lines using the standard parenthesis. 5.4.2 RR Numbering A SIG RR stored in a zone file covers and in some cases supresses a number of resource records via one or more direct or hashed signets. In order to represent this, RRs can be numbered by an integer field enclosed in curly braces "{}". For compatibility with earlier DNS zone file implementations, this field can occur after all data fields but before any comments, and can be optionally preceded by a single pound sign ("#") immediately before the open curly brace ("{"). This "#" will cause the RR number to be treated as a comment by non- security aware servers but the "#{ number }" will be recognized by security aware servers. [give example] Actually, the RR number is the first subfield of three within the curly braces. As described below additional fields can occur separated by semi-colons (";"). Donald E. Eastlake 3rd & Charles W. Kaufman [Page 24] INTERNET-DRAFT DNS Protocol Security Extensions 5.4.3 SIG RR Scope The RRs that are covered by a SIG RR are represented by a second sub-field inside the curly brace field which must be present for SIG RRs. This subfield consists of a comma and/or white space separated list of RR numbers, or ranges of the form n-m to indicates all integers from n through m inclusive. As an abbreviation, an asterisk ("*") appearing in this subfield means all RRs appearing before the SIG RR in the zone file back to but not include the immediately previous SIG RR or the beginning of the file, whether or not such covered RRs are numbered. The SIG RR should also be considered to cover any RRs that it supresses as explained in the section below. The SIG RR itself need not be numbered unless it needs to be referred to. For example [give examples here] 5.4.4 RRs Supressed by a SIG RR Where a SIG RR includes direct RR signets, the RRs being authenticated should normally be supressed when the SIG RR appears in a response. This is indicated in the zone data file by a third sub- field inside the curly brace field that may be present with SIG RRs and must be present if they have direct RR signets. As with the scope subfield, this subfield consists of a comma and/or white space separated list of RR numbers or ranges of the form n-m to indicate all integers from n through m inclusive. As an abbreviation, an asterisk ("*") appearing in this subfield means all RRs appearing before the SIG RR in the zone file back to but not include the immediately previous SIG RR or the beginning of the file, whether or not such supressed RRs are numbered. An RR that is supressed is implicitly covered and may, but need not, also be listed in the scope sub-field described in 5.4.2. [give example] 5.4.5 Indicating Revocation In many cases, a zone file will be maintained and SIG RRs will be added to the zone file by a separate operation. To indicate that Donald E. Eastlake 3rd & Charles W. Kaufman [Page 25] INTERNET-DRAFT DNS Protocol Security Extensions such a generated SIG should be a revocation, include the word "revoke", or any word (contiguous string of letters) beginning with a lower or upper case R within the "{}" field for the RR as described above. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 26] INTERNET-DRAFT DNS Protocol Security Extensions 6. The RSA Resource Record The RSA RR is used to document a public key that is associated with a DNS name. This can be a zone owner, the name of a DNS host for transaction authentication, etc., or any DNS name. An RSA RR is, like any other RR, authenticated by a SIG RR. Security aware DNS implementations should be designed to handle at least two simultaneously valid keys associated with a name. The type number for the RSA RR is xxx. 6.1 RSA RDATA format The RDATA for a RSA RR consists of an octet of flags, the public exponent, and the public modulus. The format is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | public key exponent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulus length| | +---------------+ public key modulus -+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The public key exponent is an unsigned 24 bit integer. The modulus length is an unsigned octet. This limits keys to a maximum of 255 bytes. A zero modulus length is special and indicates the specific assertion that there is no key associated with the owner. The public key modulus field is a multiprecision unsigned integer. The bits in the flag octet are described in Section 6.3 belows. [It would be possible to allow additional optional fields after the above in the SIG RR as described in draft-ietf-dns-ixfr-01.txt] 6.2 Types of DNS Names and Keys The same DNS name may refer to up to three things at present. For example, dee.lkg.dec.com could be (1) a zone, (2) a host, and (3) the mapping into a DNS name of the user dee@lkg.dec.com . Thus, the flag byte in the RSA RR has bits to indicate with which of these roles a Donald E. Eastlake 3rd & Charles W. Kaufman [Page 27] INTERNET-DRAFT DNS Protocol Security Extensions public key is associated as described below. It is possible to use the same key for these different things with the same DNS name but this is discouraged. In addition, there are two control bits, the "mandatory" bit and the "authority" bit, as described in 6.3 below. It would be desirable for the growth of DNS to be managed so that additional possible simultaneous uses for names are NOT added. New uses should be distinguished by exclusive domains. For example, all telephone numbers in the world have been mapped into the tpc.int domain of the operational DNS system. This is preferable to having the same name possibly be a telephone number and a host as well as a zone and a user, depending on the RRs present. 6.3 RSA RR Flag Bits Bits 0 is the "mandatory" bit. Keys may be associated with zone or entities for experimental, trial, or optional use, in which case this bit will be zero. If this bit is a one, it means that the use or availability of security based on the key is "mandatory". Thus, if this bit is on for a zone, the zone should be assumed secured by SIG RRs and any responses indicating the zone is not secured should be considered bogus. Similarly, if this bit were on for a host key and attempts to negotiate IP-security with the host produced indications that IP-security was not supported, it should be assumed that the host has been compromised or communications with it are being spoofed. On the other hand, if this bit were a zero, the host might very well sometimes operate in a secure mode and at other times operate without the availability of IP-security. The mandatory bit is only effective if the key is appropriately signed. Bit 1 is the "authority" bit. It indicates that the key can validly sign RRs of the same name. This bit is meaningless for zone keys which always have authority to sign any RRs in the zone. The bit is only effective if the key is signed by a valid zone key. Bits 2-4 are reserved and must be zero. If they are found non- zero, they should be ignored and the RSA RR used as indicated by the other flags. Bit 5 on indicates that this is a zone key for the zone whose name is the RSA RR owner name. This is the fundamental type of data origin authentication public key. Bit 6 on indicates that this is a key associated with the end entity whose name is the RR owner name. This will commonly be a host but could, in some part of the DNS tree, be some other type of Donald E. Eastlake 3rd & Charles W. Kaufman [Page 28] INTERNET-DRAFT DNS Protocol Security Extensions entity. This is the public key used in connection with the optional transaction authentication service defined in this draft. It could also be used in an IP-security protocol where authentication of a host was desired. This would be useful in IP or other security for host level services such as DNS, NTP, routing, etc. Bit 7 on indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. The coding of the owner name is that used for the responsible individual in the SOA record: The owner name is the user name as the name of a node under the entity name. For example, "j.random_user" on host.subdomain.domain could have a public key associated then through an RSA RR with name j\.random_user.host.subdomain.domain. It could be used in an IP-security protocol where authentication of a user was desired. This key would be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc. 6.4 RSA RRs in the Construction of Responses A request for RSA RRs does not cause any additional information process because of these RSA RRs except, of course, for SIG RRs if security is requested and available. Security aware DNS servers will include RSA RRs as additional information in responses where security is requested under appropriate conditions as follows: On the retrieval of NS RRs, the zone key RSA RR(s) for the zone served by these name servers will be included. If not all additional info will fit, the RSA RR(s) have higher priority than type A RRs. On retrieval of type A RRs, the end entity RSA RR(s) for the host named will be included. On inclusion of A RRs as additional information, they will also be included but with lower priority than the relevant A RRs. On any retrieval with security requested and available from a zone, any revoked RSAs that fit with their revoking SIG will be included as additional information with low priority. 6.5 File Representation of RSA RRs RSA RRs may appear as lines in a zone data file. The flags field is represented as an unsigned integer. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 29] INTERNET-DRAFT DNS Protocol Security Extensions The public key exponent appears as an unsigned integer from 3 to 16777215. The public key modulus can be quite large, up to 255 octets. It is the last data field and is represented in hex and may be divided up into any number of white space separated substrings, down to single hex digits, which are concatenated to obtain the full signature. These hex substrings can span lines using the standard parenthesis. The special case of a null key is indicated by a single zero digit. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 30] INTERNET-DRAFT DNS Protocol Security Extensions 7. How to Resolve Securely Retrieving or resolving authentic data from the DNS involves starting with one or more trusted public keys and, in general, progressing securely from them through the DNS structure to the zone of interest. Such trusted public keys would normally be configured in a manner similar to that described in section 7.1. However, as a practical matter, a security aware resolver would still gain some confidence in the results it returns even if it was not configured with any keys but trusted what it got from a local well known server as a starting point. 7.1 Boot File Format The recommended format for a boot file line to configure starting keys is as follows: zonekey f.q.d.n exponent modulus for a zone public key or hostkey f.q.d.n exponent modulus for a host public key. f.q.d.n is the domain name of the zone or host, exponent is the public key exponent between 3 and 16777215, and modulus is the public key modulus in hex. While it might seem logical for everyone to start with the key for the root zone, this has problems. The logistics of updating every DNS resolver in the world when the root key changes would be excessive. It may be some time before there even is a root key. And furthermore, some organizations may explicitly wish their "interior" DNS implementations to trust only their own zone. These interior resolvers can then go through the organization's zone server to access data outsize the organization's domain. If desired, the IP address for the f.q.d.n's with configured keys can generally also be configured via an /etc/hosts or similar local file. 7.2 Chaining Through Zones Starting with one trusted zone key, it is possible to retrieve signed keys for subzones which have them. Every secure zone (except root) should also include the RSA record for its super-zone signed by the secure zone. This makes it possible to climb the tree of zones if one starts below root. A secure sub-zone is generally indicated by Donald E. Eastlake 3rd & Charles W. Kaufman [Page 31] INTERNET-DRAFT DNS Protocol Security Extensions an RSA RR appearing with the NS RRs for the sub-zone. These make it possible to descend within the tree of zones. A resolver should keep track of the number of successive secure zones traversed from a starting point to any secure zone it can reach. In general, the lower such a distance number is, the greater the confidence in the data. Data configured via a boot file should be given a distance number of zero. Should a query encounter different data with different distance values, that with a larger value should be ignored. A security conscious resolver should completely refuse to step from a secure zone into a non-secure zone unless the non-secure zone is certified to be non-secure or only optionally secure by the present of an authenticated RSA RR for the non-secure zone with a zero length modulus or the presence of a non-zero length modulus RSA RR without the mandatory bit set. Otherwise the resolver is probably getting completely bogus or spoofed data. If legitimate non-secure zones are encountered in traversing the DNS tree, then no zone can be trusted as secure that can be reached only via information from such non-secure zones. Since the non-secure zone data could have been spoofed, the "secure" zone reach via it could be counterfeit. The "distance" to data in such zones or zones reached via such zones could be set to 512 or more as this exceeds the largest possible distance through secure zones in the DNS. Never the less, continuing to apply secure checks within "secure" zones reached via non-secure zones will, as a practical matter, provide some increase in security. 7.3 Secure Time Coordinated interpretation of the time fields in SIG RRs requires that secure consistent time be available to the hosts implementing the DNS security extensions. The Network Time Protocol (NTP) [RFC1305] provides an excellent means for coordinating consistent time. It also includes strong security but has no key management provisions. It just assumes that symmetric keying material will be on each pair of communicating nodes. In the absence of security, NTP or other time synchronization protocols could be spoofed. A solution to this would be to do NTP over IP-security. This may seem circular, where the security system is used to protect the synchronization of time needed for the security system. In practice, manual set up of approximate time would be adequate to bootstrap the system which could then securely synchronize itself more accurately. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 32] INTERNET-DRAFT DNS Protocol Security Extensions To accommodate the secure time requirement, all DNS servers should also be NTP servers. NTP assumes that time servers are organized into numbered strata where the servers at each strata are clients to a lower numbered strata and servers to higher numbered strata. This can be accomplished in the DNS context by have each primary or secondary DNS server be an NTP client to the servers up the DNS tree from those zones they provide (ignoring zones that are subzones of other zones the server carries). Stub resolvers or the like could look to their default server for NTP service. Special arrangements would have to been made for the root primary and its secondaries to either have reliable hardware time sources or be secure clients to machines with such sources. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 33] INTERNET-DRAFT DNS Protocol Security Extensions 8. Operational Considerations This section discusses a variety of operational considerations in secure operation of DNS using these proposed protocol extensions. 8.1 Modulus Size Considerations There are a number of factors that effect modulus (key) size choice for use in the DNS security extension. Unfortunately, these factors do not all point in the same direction. Choice of a modulus size should be made by the zone administrator depending on their local conditions. Larger moduluses are more secure but slower. The recommended minimum modulus size, 641 bit, is believed by the authors to be secure at this time and for some years but high level nodes in the DNS tree may wish to set a higher minimum, perhaps 1000 bits, for security reasons. (Since the United States National Security Agency generally permits export of encryption systems using an RSA modulus of up to 512 bits, use of that small a modulus, i.e. n, must be considered weak.) Because this protocol packs information inside an RSA signature, larger moduluses also increase the efficiency of use of space with SIG RRs. There is a 22 byte overhead (prefix and self hash) within the signature plus all the SIG RR fields outside of the signature. However, larger moduluses also lead to larger SIG RRs which may lead to lower packing density of SIG RRs in a maximum length DNS UDP packet. With the minimum modulus size required by this protocol, the signature before RSA encoding is 80 octets (usually resulting in 81 octets after encoding). After deducting 2 octets for the minimum 01 00 signature prefix and 20 octets for a hashed self signet, 56 octets would be available for other signets. With the maximum modulus size permitted by this protocol, the signature is usually 255 octets which leaves 233 bytes for other signets. Zones may wish to adopt policies on the size of host, user, or even subzone keys within them such that the RSA RRs for these keys will fit within a zone signed SIG for efficiency. 8.2 Key Storage It is strongly recommended that zone private keys and the zone file master copy be kept and used in off-line non-network connected Donald E. Eastlake 3rd & Charles W. Kaufman [Page 34] INTERNET-DRAFT DNS Protocol Security Extensions physically secure machines only. Periodically an application can be run to re-sign the RRs in a zone by adding SIG RRs and then the SIG augmented file transferred, perhaps by sneaker-net, to the networked server machine. The idea is to have a one way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. The master copy of the zone file should also be off net and should not be updated based on a solely network mediated communication. 8.3 Key Generation Careful key generation is a sometimes over looked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Suggestions will be found in draft-ietf-security-randomness-01.txt. 8.4 Key Lifetimes No key should be used forever. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. No DNS security extensions key should have a lifetime significantly over five years. The recommended lifetime for zone keys that are kept off-line and carefully guarded is 13 months with the intent that they be replaced every year. The recommended maximum lifetime for host keys that are used for IP-security or the like and are kept on line is 35 days with the intent that they be replaced monthly or more often. 8.5 Key Revocation In cases where an erroneous signed key exists in the DNS system, it is useful to be able to propagate a revocation. In most cases, the natural refresh processes of DNS will eventually obtain valid, up to date key information for secondaries. However, there could be stale information out in caching servers or the like for a long time, particularly since accident or malicious action could have cause RRs, Donald E. Eastlake 3rd & Charles W. Kaufman [Page 35] INTERNET-DRAFT DNS Protocol Security Extensions including SIGs, RSAs, etc., with very long TTLs and/or distant end- times to be distributed. There are limits to how much can be done about this problem. The DNS security extensions provide for revocation of keys. The revocation information is provided when current key information is retrieved. In addition, security aware servers opportunisticly flood revocation information by including it with low priority in the additional information section of any retrieval from the zone containing the revoked key. It is a matter of server policy how to choose which extra revocations to include as additional information. Some revocations may be "more important" than others or it may be best to simply pick as much as will fit at random. On receipt of an authenticated revocation, a resolver should expunge all RRs authenticated by the revoked key. It is a matter of resolver policy what revocations, if any, to cache and for how long. Resolvers can not keep an indefinite number of revocations for an indefinite time. The possibility of denial of service attacks based on fabricating many revocations must be considered. It should be noted that like assertions, revocations have start and end times. Thus, for example, a valid key validly generated but accidentally given an excessive lifetime in a SIG can be revoked for just the later part of that lifetime by setting appropriate times in the revocation SIG RR. 8.6 Root The root zone RSA key is self-signed. It should also be noted that in DNS the root is a zone unto itself. Thus the root key should only be see signing itself or signing RRs with names one level below root, such as .aq, .edu, or .arpa. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 36] INTERNET-DRAFT DNS Protocol Security Extensions 9. Conformance [this section needs work ...] 9.1 Server Conformance Security aware servers MUST respond normally to requests that do not have the Security Desired bit set. Three levels of server conformance are defined as follows: Zilch server compliance is (1) the ability to ignore the Security Requested bit in queries, (2) ability to store and retrieve (incluidng zone transfer) SIG and RSA RRs, and (3) always clearing the Security Available bit in responses. It is believed that almost all current servers meet this level of compliance. Minimal server compliance adds the following to zilch compliance: (1) ability to read SIG and RSA RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG RRs, possibly via a separate application. Primary servers for secure zones must be at least minimally compliant. Full server compliance is ability to handle the Security Desired bit in inquiries, automatically including SIG and RSA RRs in responses as appropriate, as well as meeting the minimal compliance except that only item 2 of zilch criteria should be met. In addition, fully compliant servers MUST turn on the Security Available bit in responses. 9.2 Resolver Conformance - Resolver compliance... Donald E. Eastlake 3rd & Charles W. Kaufman [Page 37] INTERNET-DRAFT DNS Protocol Security Extensions 10. Security Considerations The entirety of this document concerns extensions to the Domain Name System (DNS) protocol to provide data origin authentication, DNS transaction authentication, and key storage. References [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 June 1991, Version 1.4. [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 [RFC1033] - Domain Administrators Operations Guide, M. Lottor, November 1987 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987 [RFC1035] - Domain Names - Implementation and Specifications [RFC1305] - Network Time Protocol (v3), D. Mills, April 9 1992 [SHS] - NIST FIPS PUB 180, Secure Hash Standard, National Institute of Science and Technology, U.S. Department of Commerce, April 1993. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 38] INTERNET-DRAFT DNS Protocol Security Extensions Authors Addresses Donald E. Eastlake 3rd Digital Equipment Corporation 550 King Street, LKG2-1/BB3 Littleton, MA 01460 Telephone: +1 508 486 6577(w) +1 508 287 4877(h) EMail: dee@lkg.dec.com Charles W. Kaufman Digital Equipment Corporation 110 Spit Brook Road, ZKO3-3/U14 Nashua, NH 03062 Telephone: +1 603-881-1495 EMail: kaufman@zk3.dec.com Expiration and File Name This draft expires 22 September 1994 Its file name is draft-ietf-dnssec-secext-01.txt. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 39] ------- End of Forwarded Message   Received: from sol.tis.com by magellan.TIS.COM id aa23493; 24 Mar 94 19:15 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23033; Thu, 24 Mar 94 19:15:27 EST Received: by relay.tis.com; id AA11048; Thu, 24 Mar 94 19:14:58 EST Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay via smap (V1.3mjr) id sma011034; Thu Mar 24 19:14:34 1994 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07825; 24 Mar 94 11:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@magellan.TIS.COM MMDF-Warning: Parse error in original version of preceding line at magellan.TIS.COM Cc: dns-security@tis.com From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-secext-01.txt Date: Thu, 24 Mar 94 11:19:37 -0500 Sender: cclark@cnri.reston.va.us Message-Id: <9403241119.aa07825@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Security Working Group of the IETF. Title : Domain Name System Protocol Security Extensions Author(s) : D. Eastlake, C. Kaufman Filename : draft-ietf-dnssec-secext-01.txt Pages : 39 Date : 03/23/1994 The Domain Name System has become a critical operational part of the Internet infrastructure yet it has no security mechanisms to assure data integrity or authentication. Extensions to the DNS protocol are proposed to provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are added to secured zones as resource records. They can be most efficiently handled by security aware servers but security can still be provided to security aware resolvers or applications even by non-security aware secondary or caching servers. In addition, the extensions provide for the storage of authenticated keys in the DNS, so that a security aware resolver can learn the authenticating key of zones in addition to those for which it is initially configured, and for other purposes. Finally, the extensions optionally provide for authentication of DNS protocol transactions for additional security. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-dnssec-secext-01.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext-01.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940323172226.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-dnssec-secext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940323172226.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from sol.tis.com by magellan.TIS.COM id aa07334; 30 Mar 94 20:02 EST Received: from magellan.TIS.COM by tis.com (4.1/SUN-5.64) id AA06909; Wed, 30 Mar 94 20:02:43 EST Received: from localhost.tis.com by magellan.TIS.COM id aa07327; 30 Mar 94 20:02 EST Reply-To: James M Galvin To: Dave Crocker Cc: dns-security@tis.com Subject: DNS Security Area Report Summary (March 94 Seattle) Mime-Version: 1.0 Content-Type: multipart/security; boundary="----- =_aaaaaaaaaa0" Date: Wed, 30 Mar 1994 20:02:47 -0500 From: James M Galvin Message-Id: <9403302002.aa07327@magellan.TIS.COM> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7309.765075761.2@tis.com> The DNS Security WG met to review the proposed security enhancements drafted by Charile Kaufman and Don Eastlake. The desired requirements specifed at the Houston meeting were reviewed, followed by a presentation and discussion of the proposal. A number of issues were identified, with a disposition proposed for each. In particular, resolution on a few was deferred until after implementation experience was available. Jim Galvin indicated that TIS would be implementing the proposal. This group expects to meet in Toronto. Jim ------- =_aaaaaaaaaa0 Content-Type: application/signature; protocol="pem" Content-ID: <7309.765075761.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE= ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0= 2 MIC-Info: RSA-MD5,RSA,hYipsflYdAmIuTebemHiLMtxqwl92qd3XEFqVBq0+D+7NgX7SuKJ= KWFfF1YqCLBzwsMR3OQWdZY2ruNYy8pqhg6Gb2uekCW7twhiDtHui1x9MoGg401JNFa6TK1brq= r1 ------- =_aaaaaaaaaa0--