idnits 2.17.1 draft-ietf-dnssec-secext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnssec-secext-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-secext-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-secext-00.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnssec-secext-00.txt,', but the file name used is 'draft-ietf-dnssec-secext-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 484: '...es support this protocol, the bit MUST...' RFC 2119 keyword, line 485: '...nd, if the bit is set, the server MUST...' RFC 2119 keyword, line 584: '... be 1) SHALL be at least 641 and not...' RFC 2119 keyword, line 586: '... SHOULD be chosen such that the publ...' RFC 2119 keyword, line 616: '... RR SHOULD be surpressed from the re...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (22 August 1994) is 10832 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1032' is defined on line 1460, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1465, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' ** Downref: Normative reference to an Unknown state RFC: RFC 1032 ** Downref: Normative reference to an Unknown state RFC: RFC 1033 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 14 errors (**), 1 flaw (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT DNS Protocol Security Extensions 2 23 February 1994 3 Expires 22 August 1994 5 Domain Name System Protocol Security Extensions 6 ------ ---- ------ -------- -------- ---------- 7 Donald E. Eastlake 3rd & Charles W. Kaufman 9 Status of This Document 11 This draft, file name draft-ietf-dnssec-secext-00.txt, is intended to be 12 become a standards track RFC. Distribution of this document is 13 unlimited. Comments should be sent to the DNS Security Working Group 14 mailing list or to the authors. 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 its Working Groupsd and other organizations or individuals. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a 24 ``working draft'' or ``work in progress.'' Please check the 1id- 25 abstracts.txt listing contained in the internet-drafts Shadow 26 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 27 munnari.oz.au to learn the current status of any Internet Draft. 29 Abstract 31 The Domain Name System has become a critical operational part of the 32 Internet infrastructure yet it has no security mechanisms to assure 33 data integrity or authentication. Extensions to the DNS protocol are 34 proposed to provide these services to security aware resolvers or 35 applications through the use of cryptographic digital signatures. 36 These digital signatures are added to secured zones as resource 37 records. They can be most efficiently handled by security aware 38 servers but security can still be provided to security aware 39 resolvers or applications even by non-security aware primary, 40 secondary, and caching servers. 42 In addition, the extensions provide for the storage of authenticated 43 keys in the DNS, so that a security aware resolver can learn the 44 authenticating key of zones in addition to those for which it is 45 initially configured, and for other purposes. 47 Finally, the extensions optionally provide for authentication of DNS 48 protocol messages for additional security. 50 Table of Contents 52 Status of This Document....................................1 53 Abstract...................................................1 54 Acknowledgements...........................................2 55 Table of Contents..........................................2 56 1. Introduction............................................4 57 2. Overview of the Protocol...............................4 58 2.1 Data Origin Authentication.............................4 59 2.1.1 Security Provided...................................4 60 2.1.2 The SIG Resource Record..............................5 61 2.1.3 The RSA Resource Record..............................6 62 2.1.4 Signers Other Than The Zone..........................6 63 2.1.5 Special Problems With Time-to-Live...................6 64 2.1.6 Improved Performance At The Expense Of Compatibility.7 65 2.2 DNS Message Authentication.............................8 66 3. Services, Requirement, and Non-Requirements.............9 67 3.1 Requirements...........................................9 68 3.2 Non-Requirements......................................11 69 4. The Security Desired & Security Available Bits.........12 70 5. The SIG Resource Record................................13 71 5.1 SIG RDATA Format......................................13 72 5.1.1 Signature Format....................................14 73 5.1.2 Signet Format.......................................15 74 5.1.2.1 Direct Resource Record Signets....................16 75 5.1.2.2 Direct Glue Record Signet.........................17 76 5.1.2.3 Hashed Resource Record(s) Signet..................17 77 5.1.2.4 Partial RR Set Flag Signet........................18 78 5.1.2.5 Partial SIG Set Flag Signet.......................19 79 5.1.2.6 AXFR Signets......................................19 80 5.1.2.7 Reserved Signet Prefixes..........................20 81 5.2 SIG RRs in the Construction of Responses..............20 82 5.3 Processing Responses with SIG RRs.....................21 83 5.4 File Representation of SIG RRs........................22 84 5.4.1 Size of Data........................................22 85 5.4.2 RR Numbering........................................22 86 5.4.3 SIG RR Scope........................................23 87 5.4.4 RRs Surpressed by a SIG RR..........................23 88 6. The RSA Resource Record................................25 89 6.1 RSA RDATA format......................................25 90 6.2 Types of DNS Names and Keys...........................26 91 6.3 RSA RR Flag Bits......................................26 92 6.4 RSA RRs in the Construction of Responses..............27 93 6.5 File Representation of RSA RRs........................28 94 7. How to Resolve Securely................................29 95 7.1 Boot File Format......................................29 96 7.2 Chaining Through Zones................................29 97 7.3 Secure Time...........................................30 98 8. Operational Considerations.............................32 99 8.1 Modulus Size Considerations...........................32 100 8.2 Key Storage...........................................32 101 8.3 Key Generation........................................33 102 8.4 Key Lifetimes.........................................33 103 8.5 Key Revocation........................................33 104 8.6 Root..................................................34 105 9. Conformance............................................35 106 10. Security Considerations...............................36 107 References................................................36 108 Authors Addresses.........................................37 109 Expiration and File Name..................................37 111 1. Introduction 113 [To be written] 115 2. Overview of the Protocol 117 These DNS protocol extensions provide two distinct services: data 118 origin authentication, described in section 2.1 below, and message 119 authentication, described in section 2.2 below. In addition, the 120 resource records added to support these authentication services 121 permit the association of keys with DNS names. These keys could be 122 used in support of other security services such as IP level security. 124 2.1 Data Origin Authentication 126 There are two distinct aspects to the data origin authentication 127 service. The purpose of the first is to add security; the purpose of 128 the second is to improve performance when the first is used. Adding 129 security requires no changes to the "on-the-wire" DNS protocol beyond 130 the addition of two new resource types: signatures and keys. This 131 service could be supported by existing resolver and server 132 implementations so long as they could support the additional resource 133 types. 135 If signatures are always retrieved and verified when retrieving the 136 information they authenticate, there will be more trips to the server 137 and performance will suffer. The revisions to the DNS wire protocol 138 for security aware servers are an attempt to mitigate that 139 degradation by automatically sending exactly the signatures needed 140 and by skipping the sending of the data if it can be derived from the 141 signature. 143 2.1.1 Security Provided 145 Security is provided by associating with each item of information in 146 DNS a cryptographically generated digital signature. Commonly, there 147 will be a single RSA key that signs for an entire zone. If the 148 resolver reliably learns the public RSA key of the zone, it can 149 verify that all the data read was properly authorized and is 150 reasonably current. The expected implementation is for the zone 151 private key to be kept off-line and used to re-sign all of the 152 records in the zone periodically. 154 The data origin authentication key belongs to the zone and not to the 155 servers that store copies of the data. That means compromise of a 156 secondary or caching server will not affect the degree of assurance 157 that a resolver has that the data is genuine. However, such a server 158 can (except in the case of a zone transfer) claim that a name does 159 not exist and a resolver may not be able to determine otherwise. 161 A resolver can learn the public key of a zone either by having it 162 manually configured or by reading it from DNS. To reliably learn the 163 public key by reading it from DNS, the key itself must be signed. 164 Thus to provide any reasonable degree of security, the resolver must 165 be configured with at least the public key of one zone. From that, 166 it can securely read the public keys of other zones. It is in 167 principle more secure to have the resolver manually configured with 168 the public keys of multiple zones, since then the compromise of a 169 single zone would not permit the faking of information from other 170 zones. It is also more administratively cumbersome, however, 171 particularly when public keys change. 173 2.1.2 The SIG Resource Record 175 The syntax of a SIG resource record (signature) is described in 176 Section 5. It includes the name of the signer, the time at which the 177 signature was created, the time it expires (when it is no longer to 178 be believed), its original time to live (which may be longer than its 179 current time to live but cannot be shorter), and an RSA signature. 181 There are a number of unusual aspects to the construction of the RSA 182 signature that are intended to maximize performance in this 183 application. Unlike some other digital signature schemes like El 184 Gamal or DSS, RSA signatures have the property that when a signature 185 is verified, it produces a message that is almost the size of the 186 signature itself. In most uses, for example Privacy Enhanced Mail, 187 the message to be signed is much larger than the signature (which is 188 generally 64-256 bytes long), so a message digest of the message is 189 computed (a 16-20 byte "fingerprint") and that quantity is signed. 190 For DNS, however, it will be common that the messages being signed, 191 will be very short - sometimes shorter than 16-20 bytes - 192 particularly with the abbreviation techniques used herein. 194 Further, there are commonly multiple resource records associated with 195 a DNS name, and it should be efficient to verify a signature on a 196 single one of those records or any subset of them. If a 64-256 byte 197 signature record were created for every resource record, there would 198 be an unacceptable explosion of data. 200 The SIG Resource record syntax proposed therefore has two unusual 201 properties: (1) when it signs a resource record, it may contain 202 either the resource record itself or a message digest of the resource 203 record; and (2) a single signature may sign multiple multiple 204 resource records associated with a single name. 206 Every name in a zone supporting signed data will have associated with 207 it one or more SIG resource records - as many as required to sign all 208 of the non-SIG resource records. A security aware server supporting 209 the performance enhanced version of the DNS protocol security 210 extensions will return with all records retrieved the corresponding 211 SIG records. If a server does not support the protocol, the resolver 212 must retrieve all the SIG records for a name, verify them all, and 213 find the one or ones that sign the resource records that resolver is 214 interested in. As a further optimization, a server supporting the 215 performance enhanced version of the protocol will return only the 216 signature - and skip the requested data - in the case where the 217 signature contains enough information to reconstruct the data in 218 full. Because of this, in some cases the authenticated data being 219 sent via SIG records can be shorter than the plain data would have 220 been. 222 2.1.3 The RSA Resource Record 224 The syntax of an RSA resource record (key) is described in Section 6. 225 It is present for two reasons: to support the DNS infrastructure 226 itself so that a resolver that is manually configured with the public 227 keys of one or more zones can securely learn the public keys of other 228 zone; and to allow the storing of RSA public keys of DNS-named 229 entities other than zones for applications like IP-Security. 231 2.1.4 Signers Other Than The Zone 233 There are two cases where a signature is generated by other than the 234 zone private key. One is for future support of dynamic update where 235 an entity is permitted authenticate/update its own record. The 236 public key of the entity must be present in the DNS and signed with 237 the zone key, but the other RRs may be signed with the entity's key. 238 The other is for support of message authentication as described in 239 2.2 below. 241 2.1.5 Special Problems With Time-to-Live 243 A digital signature will fail to verify if any change has occurred to 244 the data between the time it was originally signed and the time the 245 signature is verified. This conflicts with our desire to have the 246 time-to-live field tick down when resource records are cached. 248 This could be avoided by leaving the time-to-live out of the digital 249 signature, but that would allow unscrupulous secondaries to set 250 arbitrarily long time to live values undetected. Instead, we include 251 the "original" time-to-live in the signature and communicate that 252 data in addition to the current time-to-live. Unscrupulous servers 253 under this scheme can fail to decrement time to live like they are 254 supposed to, but they cannot increase it beyond its original value. 255 Separately, signatures include a time signed and an expiration time. 256 A resolver that knows an absolute time can determine securely whether 257 a signature has expired. 259 In order to keep the data as compressed as possible, we don't want to 260 have to include the original TTL for every resource record included 261 in a SIG when usually they are all the same. We therefore assume 262 that the original TTL is equal to the original TTL of the SIG 263 resource record (which is sent for every SIG resource record), and in 264 the rare case where the TTL on the other resource record differs we 265 permit it to be explicitly included. 267 2.1.6 Improved Performance At The Expense Of Compatibility 269 To run the high performance version of the protocol, the server 270 should remember for each resource record: (1) which SIG record 271 includes the signature for that record and (2) whether the SIG record 272 contains the resource record in full or in digested form. 274 When the server is responding to a request, it should for each record 275 requested return the corresponding SIG (removing duplicates) and also 276 it should suppress the sending of the record itself if it is present 277 in the signature in undigested form. Since a resolver running the 278 secure protocol will not believe any record that is not signed, there 279 would be no point in returning the record without the SIG. And if 280 the resolver is going to see the RR in full in the course of 281 verifying the signature there is no point in wasting bandwidth by 282 sending the RR being authenticated. 284 The high performance version of the protocol can only be used if both 285 resolver and server understand it. Negotiation is done via some DNS 286 message header bits we believe that existing servers will ignore and 287 existing resolvers will not set. 289 If signature verification is not done by the DNS resolver code but 290 rather by some application that is retrieving resource records 291 through that resolver, the standard protocol must be used. 293 2.2 DNS Message Authentication 295 The data origin authentication service described above protects 296 resource records but provides no protection for message headers and 297 limited protection against resource record addition to or deletion 298 from a message. If header bits or, in some cases, the resource 299 record set in a response, are falsely set by a server, there is 300 little that can be done. However, it is at least possible to add 301 message authentication. Such authentication means that a resolver 302 can be sure it is getting messages from the server it thinks it is, a 303 server can be sure it is getting requests from the resolver it thinks 304 it is, and that in both cases these messages have not been diddled in 305 transit. 307 This is accomplished by adding a SIG resource record to end of the 308 message which digitally signs the message by the server or resolver. 309 The private key used belongs to the host composing the message, not 310 to the zone being queried. The corresponding public key is stored in 311 and retrieved from the DNS. Because messages are highly variable, 312 message authentication SIGs can not be precalculated. Thus it will 313 be necessary to keep the key on-line, for example in software or in a 314 directly connected piece of hardware. 316 The best way to get the security provided by the message 317 authentication service would be to use a good IP level security 318 protocol. The authors of this draft decry the every growing number 319 of IP application level security protocols such as Telnet, NTP, FTP, 320 etc., etc. when a single IP-security protocol could secure most of 321 these applications. 323 Unfortunately, an IP-security standard has not yet been adopted. And 324 even if it had, there will be many systems for many years where it 325 will be hard to add IP security but relatively easy to replace the 326 DNS components. Furthermore, the data original authentication 327 service requires the implementation of essentially all the mechanisms 328 needed for a rudamentary message authentication service. Thus a 329 simple message authentication service using mechanisms already 330 required by DNS security is included as a strictly optional part of 331 these extensions. 333 3. Services, Requirement, and Non-Requirements 335 This section is based on the 19 November 1993 email message from 336 James M. Galvin summarizing the Houston IETF meeting of the DNS 337 Security Working Group. At this meeting a list of requirements, 338 shown in 3.1 below, and non-requirement shown in 3.2 below, were 339 arrived at. 341 The security services desired were set at the following: 343 data integrity, and 344 data origin authentication. 346 It was noted at that meeting that these services can be provided by 347 digital signatures. 349 3.1 Requirements 351 The numbered items below were determined to be "requirements", not in 352 the sense of being mandatory but in the sense of all being highly 353 desirable. A comment appears after each requirement as to if/how it 354 is met by this proposal. 356 <1> Sites must be able to support at least their internal users in 357 the presence of external network failures. 359 Security aware resolvers can be configured with the public key of 360 their local apex zone. The needed SIG RRs can be added to that zone 361 and any desired lower level zones either off-line or on-line. Thus 362 this requirement is met. 364 <2> it should be possible for a site to pre-configure other 365 authoritative servers without having to query the "system" to find 366 the server. 368 Security aware resolvers can be configured with the public key of any 369 other zones and the IP address of their servers. 371 <3> It should be possible to request services only from security 372 enhanced servers, only from non-security enhanced servers, or a 373 indicate that either is acceptable. 375 These proposed protocol extensions do not provide any enhancement to 376 the NS RR or otherwise to indicate whether or not a server is 377 security aware without actually querying it. It is believed that 378 this additional complexity is not warranted. Non-security aware 379 servers can still support security aware resolvers, although less 380 efficiently. It is possible to tell if a server is security aware by 381 the SA (Security Available) bit in the header of its responses. 383 <4> It should be possible to recognize security enhanced responses. 385 Security enhanced responses can be recognized by the presence of SIG 386 RRs. 388 <5> It should be possible to assign cryptographic keys (make use of 389 the security services) to leaf nodes in the DNS tree, i.e., fully 390 qualified domain names. 392 The proposed extensions allow RSA key RRs to be associated with any 393 node in the DNS tree. Indeed, more than one key can be associated 394 with a node which serves multiple functions. 396 <6> It should be possible to not trust secondary servers. 398 The proposed extensions can be implemented so that the zone private 399 key is never on line on the network. Thus, ignoring denial of 400 service threats, it is possible to have untrusted secondaries and 401 even untrusted primaries. 403 <7> A mechanism must exist for revoking cryptographic keys that works 404 within the DNS time-to-live framework. 406 A bit is defined in the RSA RR to indicate if it is a key assertion 407 or key revocation and key revocations are opportunisticly flooded as 408 additional information on every query to their zone if the resolver 409 and server are security aware. 411 However, an additional mechanism may be necessary to notify 412 secondaries, caching servers, etc. to assure that a revocation is 413 noticed within the TTL. This is really just a special case of a 414 change in zone information and a general mechanism such as the NOTIFY 415 operation described in draft-ietf-dns-ixfr-01.txt could be used. 416 However, guaranteed revocation is not possible (for example in a 417 partitioned network) without introducing unacceptable denial of 418 service risks (such as having to wait "forever" to get a current "key 419 revocation list" for a zone if the network is partitioned). 421 <8> Security services should be supported with no additional DNS 422 queries beyond what would be required if security was not supported. 424 No additional queries are required, barring possible UDP truncation 425 problems, to obtain authentication from or to securely learn the 426 public key for a zone when its names servers are being obtain if a 427 security enhanced server is being used by a security aware resolver. 429 <9> It must be possible to ensure that cached data expires according 430 to its TTL. 432 A security aware resolver has both the TTL for an RR and the 433 expiration time of the SIG covering the RR. Cached data is always 434 invalid after the SIG expiration time plus the original TTL. 436 3.2 Non-Requirements 438 It was explicitly decided by the DNS Security Working Group at the 439 Houston IETF meeting that the following were not requirements: 441 <1> Confidentiality: DNS data is "public" and no effort need be made 442 to provide encryption of queries/responses. (This service may be 443 available via an IP level security protocol which is currently being 444 worked on by the IP Security Working Group of the IETF .) 447 <2> Access control: DNS data is "public" and no effort need be made 448 to provide access control lists, or similar mechanisms, as part of 449 this DNS security effort. 451 4. The Security Desired & Security Available Bits 453 The header section of DNS messages is modified to define bits 9 and 454 10 in the second word (fourth octet). These were formerly the top 455 two bits of the Z field defined as "Reserved for future use." 456 [RFC1035] 458 These bits are defined as security desired, labeled SD, and security 459 available, labeled SA. With the definition of these bits, the header 460 looks like the following: 462 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 463 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 464 | ID | 465 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 466 | QR| Opcode | AA| TC| RD| RA| SD| SA| Z | RCODE | 467 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 468 | QDCOUNT | 469 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 470 | ANCOUNT | 471 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 472 | NSCOUNT | 473 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 474 | ARCOUNT | 475 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 477 All fields are as before except that the Z field is reduced to one 478 bit and SD and SA are defined as follows: 480 SD 481 Security Desired - this bit may be set in a query. If the 482 server to which the query is sent does not support the DNS security 483 protocol, the bit should be ignored except that it may be copied into 484 the response. If the server does support this protocol, the bit MUST 485 copied into the response and, if the bit is set, the server MUST 486 provide any SIG and KEY RRs as described in the sections below 487 concerning these RRs. 489 SA 490 Security Available - this is to be set or cleared in a 491 response. If set, it indicates that the server supports this 492 security protocol. 494 5. The SIG Resource Record 496 The SIG or "signature" resource record (RR) is the fundamental way 497 that resource records (and optionally message) are authenticated. 499 The SIG RR unforgably binds one or more other RRs (or a DNS message) 500 to a time and the signer's fully qualified domain name using 501 cryptographic techniques and the signer's private key. The signer is 502 the owner of the zone the RR originated from (or the composer of the 503 authenticated DNS message). 505 5.1 SIG RDATA Format 507 The RDATA portion of a SIG RR is as shown below. The integrity of 508 the RDATA information and that of the SIG RRs owner, type, and class 509 are protected by the signature field. 511 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | signer's name | 515 / / 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | original TTL | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | time signed | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | signature expiration | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | sig length | / 524 +-+-+-+-+-+-+-+-+ signature -+ 525 / / 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 The value of the SIG type is xxx. 530 The "signer's name" field is the fully qualified domain name of the 531 signer of node generating the SIG RR. This is the zone which 532 contained the RR(s) being authenticated (or the host which is the 533 source of a DNS message that is being authenticated). 535 The "original TTL" field is included in the RDATA portion to avoid 536 authentication problems that caching servers would otherwise cause by 537 decrementing the real TTL field and security problems that 538 unscrupulous servers could otherwise cause by manipulating the real 539 TTL field. This original TTL is protected by the signature while the 540 real TTL field is not. 542 The "time signed" field is an unsigned number of seconds since the 543 start of 1 January 1970. 545 The SIG is valid until the signature expiration time which is a field 546 of the same format as the time signed. 548 The "sig length" field is an unsigned 8 bit count of the number of 549 octets in the signature field. 551 The structured of the "signature" field is described below. 553 [It would be possible to allow additional optional fields after the 554 above in the SIG RR as described in draft-ietf-dns-ixfr-01.txt] 556 5.1.1 Signature Format 558 The actual signature portion of the SIG RR binds the owner, signer, 559 class, original TTL, time signed, and expiration time of the RR to 560 one or more RRs being authenticated (or to the entire DNS message in 561 which it occurs). To accomplish this, it contains at least one 562 "signet", as defined in the following section, and a "self-hash" 563 field covering the above items. The structure of signets is 564 described in section 5.1.2 below. 566 The signature is then calculated using the RSA public key system as 567 follows 569 s = ( 01 | FF* | 00 | signets | self-hash ) ** e (mod n) 571 where "|" is concatenation. "signets" is the concatenation of the 572 signets included in this signature. "self-hash" is the 20 octet hash 573 using the Secure Hash Standard [SHS] of the SIG RR name, class, 574 signer name, original TTL, time signed, and expiration time. "e" is 575 the secret key exponent of the signer, and "n" is the public modulus 576 that is the signer's public key. 01, FF, and 00 are fixed octets of 577 the corresponding hexadecimal value. The FF octet is repeated the 578 maximum number of times such that the value of the quantity being 579 exponentiated is less than the value of n. No FF octets need occur 580 if "signets" is long enough. The order of the signets is not 581 significant. 583 The size of n, including most and least significant bits (which will 584 be 1) SHALL be at least 641 and not more than 2040. n and e MUST be 585 chosen such that the public exponent is less than 2**24 - 1 and 586 SHOULD be chosen such that the public exponent is small. 588 The above specifications are a profiling of PKCS #1 [PKCS1] except 589 that, under most circumstances, one additional byte of data is 590 allowed. 592 (A public exponent of 3 minimizes the effort needed to decode a 593 signature. Use of 3 as the public exponent may be weak for 594 confidentiality uses since, if the same data can be collected 595 encrypted under three different keys with an exponent of 3 then, 596 using the Chinese Remainder Theorem [ref], the original plain text 597 can be easily recovered. This weakness is not significant for DNS 598 because we seek only authentication, not confidentiality.) 600 5.1.2 Signet Format 602 Each signet consists of a prefix octet, with which the length of the 603 signet can be unambiguously determined, followed by the signet data. 605 Signet's are of three basic types: hashed, direct, and flag. 607 A hashed signet consists of the prefix octet, some additional data, 608 and a 20 bit hash of the data covered using the Secure Hash Standard 609 [SHS]. Since this hash algorithm is not invertible, the data, such 610 as RRs, covered by a hashed signet must also be included in the reply 611 to a query if it was requested. 613 A direct signet includes all of the data it covers. Some of the data 614 may be implicit or compressed but it is all unambiguously 615 recoverable. If a direct signet is present covering an RR, then that 616 RR SHOULD be surpressed from the reply message if the SD bit is on in 617 the query and the server is security aware. 619 Flag signets occur with direct signets and multiple SIG RRs. They 620 are used to determine if a complete set of RRs of a particular 621 variety are present. 623 Signet prefix octets are as follows: 625 0000000* Illegal 626 0LLLLLLL Direct Resource Record - type & rdata 627 10LLLLLL Direct Glue Record - name, type, & rdata 628 110***** (reserved) 629 1110**** (reserved) 630 11110NHT Hashed RR(s) - N, type, T, & hash 631 111110** (reserved 632 11111100 Partial SIG Set Flag 633 11111101 Partial RR Set Flag 634 1111111* Illegal 636 In the above table, "*" represents 0 or 1 and L, N, H, and T are bits 637 whose meaning is defined in the signet descriptions below. The 638 illegal prefixes should never occur. Any signature that appears to 639 include one should be considered invalid. 641 5.1.2.1 Direct Resource Record Signets 643 This signet is an actual RR but with some fields surpressed. 645 In order to avoid inconsistencies, all RRs of the same type and class 646 have to have the same TTL, at least for currently defined RRs. SIG 647 RRs need not survive beyond the RRs they authenticate but must live 648 as long as the covered RRs do. Thus SIG RRs may be constrained to 649 having the same TTL as the RRs they cover in most cases. The SIG RR 650 will always have the same class and name as the RRs it covers(except 651 for glue RRs as described in 5.1.2.2 and 5.1.2.3 below). Finally, 652 the signet data length in the prefix octet can be used to calculate 653 the RDSIZE. Thus RRs directly represented by this variety of signet 654 are compressed by omitting their name, class, TTL, and RDLENGTH 655 fields. Only the type, and RDATA are present. For example, the 656 direct signet for a type A record in the IN (Internet) class would be 657 seven octets as follows: 658 06 00 01 xx yy zz ww 659 where 06 is the prefix indicating a direct RR signet with six data 660 octets, 00 01 is hex for the type code for type A, and xx yy zz ww is 661 the 32 bit IP address from the RR. These 7 octets in a SIG RR 662 completely represent the 15+ (1+ name, 2 type, 2 class, 4 TTL, 2 663 rdlength, 4 ip address) octets of the original type A RR. The class, 664 name, and TTL are all recoverable from the same fields of the SIG RR 665 whose signature field includes this signet. Thus the original type A 666 RR can be surpressed from the answer if given to a security aware 667 resolver. 669 Note that any names in the RDATA area of this type of signet can not 670 be abbreviated by pointers outside of the reconstructed RR. That is 671 because the SIG RR and its signets are frozen at the time the 672 signature is encrypted under the signer's private key and this frozen 673 SIG may then be used in a variety of DNS messages. The RDATA area 674 may, however, if it has multiple names, abbreviate them by references 675 to earlier names in the reconstructed RR. 677 The direct representation of RRs makes maximum use of the relatively 678 large size of RSA digital signatures for common cases. The direct 679 representation also avoids the computational effort of calculating a 680 hash code. Because the original RRs type field must always be 681 present, the minimum length of the data after this type of signet 682 prefix is 2, thus prefixes of 00 and 01 hex are illegal. The maximum 683 size direct RR signet is 128 octets. 685 All RRs need not be included within a signature using this direct 686 signet. If the data portion of a direct RR signet exceeds 22 octets 687 (i.e., a total signet size of 23 octets including the prefix count 688 octet), space inside the signature can be saved by going to the 689 hashed RR signet described below. If an RR compressed for a direct 690 signet exceeds 127 bytes or the amount of space available for signets 691 in the signature part of a SIG RR, then it must appear separately and 692 be authenticated by a hashed RR signet. 694 5.1.2.2 Direct Glue Record Signet 696 Glue records must be handled a little differently. These are 697 currently always A records with a name which usually isn't even in 698 the zone being handled but are associated with an RR in the zone. 699 This type of signet allows such glue RRs to be included within a SIG. 701 The direct glue record signet is just like the direct resource record 702 signet described above except that the name is included right after 703 the prefix and before the type and RDATA. 705 If the Glue Record signet won't fit, a hashed RR signet, described 706 below, must be used. Note that names in the DNS can be up to 256 707 bytes long which would not fit inside a SIG RR signature field. 709 5.1.2.3 Hashed Resource Record(s) Signet 711 RRs can also be protected by a signet with a hash code. If a hashed 712 signet is used, all RRs of the same name, type, class, and TTL MUST 713 be hashed into a single signet. 715 To avoid inconsistencies, RRs of the same name, type, class, and TTL 716 must either all be present or all be absent. Thus a single hash code 717 covering such multiple RRs is all that is required. The signet is 718 then formed by a single octet 11110NHT (binary) prefix followed by a 719 possible name field depending on "N" and "H" as described below, the 720 two octet type for the RRs covered, a possible TTL field depending on 721 the values of "T" described below, and then the 20 octet hash code. 723 The hash is calculated by concatenating the full RRs, with all names 724 fully expanded and any required RDLENGTH adjustments made, in a 725 canonical order, and applying the Secure Hash Standard [SHS]. The 726 canonical order for RRs is to sort them in ascending order as left 727 justified unsigned octet sequences where a missing octet sorts before 728 a zero octet. Thus the hex sequences FE 01 02, 07, FF 03, FE FD, FF, 729 and 01 01 01 01 would sort and be concatenated into the sequence 01 730 01 01 01 07 FE 01 02 FE FD FF FF 03. 732 The "N" bit in the prefix stands for Name. It is normally zero 733 because almost all RRs associated with a name in a zone have that 734 name. The exception is glue records. These are currently A records 735 with owner names outside the zone. To be able to cover these in a 736 SIG for a different name where they cannot be included as a direct 737 glue record signet as discussed in the section above, the N bit makes 738 it possible to include the different name in the signet immediately 739 after the prefix. If the N bit is a one but the H bit is zero, the 740 name is included in full. Because names in DNS can be up to 256 741 bytes long, the 20 byte hash of the full name, using the Secure Hash 742 Standard, can be used instead of the actual name and is indicated by 743 turning on the H (or "hash") bit. To match this against RRs in the 744 reply, their names must be hashed and compared. 746 The "T" bit in the prefix stands for TTL. It is normally zero. For 747 the presently defined RRs, all RRs of the same type, class, and name 748 should have the same TTL. Future RRs may be defined for which it is 749 useful for such RRs to have different TTL's. In that case the T bit 750 must be one in the signet prefix octet, and the TTL of the hashed 751 RR(s) included after the two octet type and before the hash code. 753 If both the N and T bits are on, the name appears immediately after 754 the prefix byte followed by the type, then the TTL, then the 20 byte 755 hash code. This is the standard order for these fields in an RR. 757 5.1.2.4 Partial RR Set Flag Signet 759 Verification of a hashed RR signet against the RR(s) included in the 760 hash provides a guarantee that none have been omitted. The same 761 assurance is not provided by the direct RR signet unless all of the 762 direct RR signets of the same type and class are included in one SIG 763 RR. If direct RR signets are split over more than one RR, they MUST 764 be covered by a partial RR set flag signet in each RR. 766 The partial RR set flag signet is indicated by a hex FC prefix 767 followed a two octet type and then by a count octet. The most 768 significant 4 bits (nibble) of this count octet indicates one less 769 than the total number of SIG RRs that include all of the direct 770 signets for the variety of RRs in question. The least significant 771 nibble is used to distinguish the different SIG RRs required and 772 varies from zero through the value of the first nibble. It is 773 permissible, but unnecessary, to include a partial RR set flag signet 774 prefix followed by the type and a zero byte (i.e., 1 of 1) in the SIG 775 RR containing direct signets for all RRs of a particular varient. 777 For example, an signet of FC000131 (hex) means the SIG RR is the 2nd 778 of the 4 SIG RRs covering A type RRs. 780 Should there be a case where more than 16 SIG RRs could be required 781 to hold the direct signets for a particular variety of RR, direct 782 signets may not be used. The RRs must appear directly in the DNS 783 answer and a hashed signet must be used for authentication. 785 5.1.2.5 Partial SIG Set Flag Signet 787 Since the SIG RRs for an owner name are not in themselves covered by 788 yet another SIG (except for the case of zone transfers), a malicious 789 server might choose to provide only some of them in response to a 790 query for SIG RRs. The partial RR set flag signet defined above is 791 not guaranteed to help here. 793 The signet prefix of hex FD is followed by an unsigned byte which is 794 one less than the total number of SIG RRs associated with the name 795 and a second unsigned byte which varies from zero through the value 796 of the first byte. It is permissible, but unnecessary, to include a 797 partial SIG set flag signet prefix followed by two zero bytes (i.e, 1 798 of 1) if only one SIG RR is associated with a name. 800 More than 256 SIGs many not be associated with the same name and 801 class. 803 5.1.2.6 AXFR Signets 805 To secure zone transfers, a SIG under the zone name will have a 806 hashed RR signet with the AXFR type. It will be calculated by 807 hashing together all other static zone RRs, including SIGs. The RRs 808 are ordered and concatenated for hashing as described in Section 809 5.1.2.3. This SIG, other than having to be calculated last of all 810 zone key signed SIGs in the zone, is the same as any other SIG. It 811 can contain non-AXFR signets, be numbered with the partial SIG set 812 flag signet along with other zone level SIGs, if any, etc. 814 Dynamic zone RRs which might be added by some future dynamic zone 815 update protocol and signed by an end entity key rather than a zone 816 key (see Section 6.2) are not included. They originate in the 817 network and will not, in general, be migrated to the recommended off 818 line zone signing procedure (see Section 8.2). Thus such dynamic RRs 819 are not directly signed by the zone and are not generally protected 820 against omission during zone transfers. 822 5.1.2.7 Reserved Signet Prefixes 824 A number of signet prefixes are reserved for future allocation by the 825 Internet Assigned Numbers Authority (IANA). All such signets will 826 have an unsigned length octet immediately following their prefix 827 code. This will be the length of the signet data not including the 828 prefix or length octets. Thus their length can be unambiguously 829 determined. 831 Such signets are not to be generated by any implementation except for 832 a use for which they have been allocated by IANA. Such signets are 833 to be ignored on receipt by any implementation which does not 834 understand them. 836 5.2 SIG RRs in the Construction of Responses 838 SIG RRs MUST NOT be sent in response to a query where the SD header 839 bit is clear unless the query specifically requests the SIG type. 841 When the SD header bit is set, the DNS server MUST, for every RR the 842 query will return, attempt to send the available SIG RRs which 843 authenticates the requested RR. If multiple such SIGs are available, 844 there may be insufficient space in the response to include them all. 845 In this case, SIGs whose signer is the zone containing the RR MUST be 846 given highest priority and retained even if SIGs with other signers 847 must be dropped. 849 Furthermore, this automatic inclusion of SIGs in a response is NOT 850 additional information RR processing. To minimize possible 851 truncation problems, if a SIG covers any RR that would be in the 852 answer section of the response, it MUST appear in the answer section. 853 If it covers an RR that would appear in the authority section and 854 does not cover any answer section RR, it MUST appear in the authority 855 section. If it covers an RR that would appear in the additional 856 information section and does not cover any answer or authority 857 section RR, it MUST appear in the additional information section. 859 In many cases, as described below, the full authenticated RR will be 860 included inside the SIG RR. In such cases, the DNS server SHOULD 861 send only the SIG and surpress the directly requested RR. 863 The server should assume that the inquirer has the necessary public 864 key to authenticate RRs with the SIG and that, in general, an RR not 865 covered by a SIG may be considered worthless by the inquirer. 866 However, if a SIG including a full RR or an RR and its authenticating 867 SIG will not fit in a response, but the RR alone will, a server MAY 868 send the unauthenticated RR notwithstanding the set SD bit in the 869 query header. 871 Optionally, DNS messages may be authenticated by a SIG RR at the end 872 of the message in the additional information section. Such SIG RRs 873 are signed by the DNS server originating the message. 875 5.3 Processing Responses with SIG RRs 877 If SIG RRs are received in response to a query specifying the SIG 878 type, no special processing is required but a security aware client 879 may wish to authenticate them by decoding the signature and applying 880 consistency checks. 882 If SIG RRs are received in any other response, a security aware 883 client should decoded them using the public key of the signer and the 884 data coded into the signature should be carefully examined. 886 It should start with a 01 FF* 00 octet sequence (a 01 octet, zero or 887 more FF octets, and a 00 octet) followed immediately by one or more 888 concatenated signets and ending with the 20 byte self hash field 889 matching the hash of the relevant SIG RR fields outside of the 890 signature. If the decoded signature can not be parsed or the self 891 hash check fails, the SIG RR is invalid and should be ignored. The 892 time of receipt of the SIG RR must be in the inclusive range of the 893 time signed and the signature expiration but the SIG can be retained 894 and remains locally valid until the expiration time plus the range 895 authenticated TTL. Next, the contents of the one or more direct RR, 896 hashed RR, or flag signets present should be examined. 898 For all direct RR signets, the original RR should be reconstructed if 899 they are of a type that should have been retrieved by the query. If 900 they are of another type, they can be optionally reconstructed or 901 ignored. For all reconstructed RRs, there must be a complete set of 902 partial set flag signets or all must be included in one SIG. For 903 hashed RR signets, the hash should be computed from RRs present in 904 the response and compared for authentication. Hashed RR signets for 905 a type not requested in the query must be ignored. 907 If the SIG RR is the last RR in a response in the additional 908 information section, it may contain a hashed message signet covering 909 the preceding data in the response. This should be checked and the 910 message rejected if the check fails but it does NOT authenticate any 911 RRs in the message. Only proper direct or hashed RR signets signed 912 by the originating zone can authenticate RRs. The hashed message 913 signet merely protects from tampering between the DNS server and the 914 resolver making the query. 916 If all reasonable checks indicate that the SIG RR is valid then RRs 917 reconstructed or verified by hash should be considered authenticated 918 and all other RRs in the response should be considered with 919 suspicion. The probability that a SIG RR that has been tampered with 920 (without knowledge of the secret key) will pass reasonable checks is 921 vanishingly small (less than 1 in 2**150). 923 If a SIG RR is received in the additional information section of a 924 query, rather than a response, it can be optionally used to 925 authenticate the query. Warning: many current implementations of the 926 DNS ignore queries with a non-zero additional information count. A 927 message authenticating SIG RR should NOT be included in a query 928 unless you have outside knowledge that the queried system will permit 929 it or have received a DNS message from the system with the SA bit on 930 in the header. 932 5.4 File Representation of SIG RRs 934 A SIG RR covering RRs can be represented as a single logical line in 935 a zone data file [RFC1033] but there are some special problems as 936 described below. (It does not make sense to include a message 937 authenticating SIG RR in a file as it is a transient authentication 938 that must be calculated in real time by the message composing DNS 939 host.) 941 5.4.1 Size of Data 943 There is no particular problem with the signer and times. The time 944 fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the 945 first MM is the month number (01-12), DD is the day of the month 946 (01-31), HH is the hour in 24 hours notation (00-23), the second MM 947 is the minute (00-59), and SS is the second (00-59). 949 The original TTL appears as an unsigned integer. 951 However, the signature itself can be up to 255 octets. It is the 952 last data field and is represented in hex and may be divided up into 953 any number of white space separated substrings, down to single hex 954 digits, which are concatenated to obtain the full signature. These 955 hex substrings can be split between lines using the standard 956 parenthesis. 958 5.4.2 RR Numbering 960 A SIG RR stored in a zone file covers and in some cases surpresses a 961 number of resource records via one or more direct or hashed signets. 962 In order to represent this, RRs can be numbered by an integer field 963 enclosed in curly braces "{}". For compatibility with earlier DNS 964 zone file implementations, this field can occur after all data fields 965 but before any comments, and can be optionally preceded by a single 966 pound sign ("#") immediately before the open curly brace ("{"). This 967 "#" will cause the RR number to be treated as a comment by non- 968 security aware servers but the "#{ number }" will be recognized by 969 security aware servers. 971 [give example] 973 Actually, the RR number is the first subfield of three within the 974 curly braces. As described below additional fields can occur 975 separated by semi-colons (";"). 977 5.4.3 SIG RR Scope 979 The RRs that are covered by a SIG RR are represented by a second 980 sub-field inside the curly brace field which must be present for SIG 981 RRs. This subfield consists of a comma and/or white space separated 982 list of RR numbers, or ranges of the form n-m to indicates all 983 integers from n through m inclusive. As an abbreviation, an asterisk 984 ("*") appearing in this subfield means all RRs appearing before the 985 SIG RR in the zone file back to but not include the immediately 986 previous SIG RR or the beginning of the file, whether or not such 987 covered RRs are numbered. 989 The SIG RR should also be considered to cover any RRs that it 990 surpresses as explained in the section below. 992 The SIG RR itself need not be numbered unless it needs to be referred 993 to. 995 For example 997 [give examples here] 999 5.4.4 RRs Surpressed by a SIG RR 1001 Where a SIG RR includes direct RR signets, the RRs being 1002 authenticated should normally be surpressed when the SIG RR appears 1003 in a response. This is indicated in the zone data file by a third 1004 sub-field inside the curly brace field that may be present with SIG 1005 RRs and must be present if they have direct RR signets. 1007 As with the scope subfield, this subfield consists of a comma and/or 1008 white space separated list of RR numbers or ranges of the form n-m to 1009 indicate all integers from n through m inclusive. As an 1010 abbreviation, an asterisk ("*") appearing in this subfield means all 1011 RRs appearing before the SIG RR in the zone file back to but not 1012 include the immediately previous SIG RR or the beginning of the file, 1013 whether or not such surpressed RRs are numbered. An RR that is 1014 surpressed is implicitly covered and may, but need not, also be 1015 listed in the scope sub-field described in 5.4.2. 1017 [give example] 1019 6. The RSA Resource Record 1021 The RSA RR is used to document a public key that is associated with a 1022 DNS name. This can be a zone owner, the name of a DNS host for 1023 message authentication, or any DNS name. An RSA RR is, like any 1024 other RR, authenticated by a SIG RR. Security aware DNS 1025 implementations should be designed to handle at least two 1026 simultaneously valid keys associated with a name and try both for 1027 decoding relevant SIG RRs to handle key roll over. 1029 The type number for the RSA RR is xxx. 1031 6.1 RSA RDATA format 1033 The RDATA for a RSA RR consists of a start and end time, an octet of 1034 flags, the public exponent, and the public modulus. The format is as 1035 follows: 1037 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1038 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 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | start time | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | end time | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | flags | public key exponent | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | modulus length| | 1047 +---------------+ public key modulus -+ 1048 / / 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 The time fields are unsigned in seconds since the start of 1 January 1052 1970. 1054 The public key exponent is an unsigned 24 bit integer. 1056 The modulus length is an unsigned octet. This limits keys to a 1057 maximum of 255 bytes. A zero modulus length is special and indicates 1058 the specific assertion that there is no key associated with the 1059 owner. 1061 The public key modulus field is a multiprecision unsigned integer. 1063 The bits in the flag octet are described in Section 6.3 belows. 1065 [It would be possible to allow additional optional fields after the 1066 above in the SIG RR as described in draft-ietf-dns-ixfr-01.txt] 1068 6.2 Types of DNS Names and Keys 1070 The same DNS name may refer to up to three things at present. For 1071 example, dee.lkg.dec.com could be (1) a zone, (2) a host, and (3) the 1072 mapping into a DNS name of the user dee@lkg.dec.com (although at 1073 present it is only the last of these three). Thus, the flag byte in 1074 the RSA RR has bits to indicate with which of these roles a public 1075 key is associated as described below. It is possible to use the same 1076 key for these different things with the same DNS name but this is 1077 discouraged. 1079 The case of the host or other end entity is further subdivided. One 1080 bit indicates that a key is generally associated with that entity. A 1081 second indicates that the key belongs to the end entity and is 1082 authorized to authenticate RRs for the end entity. In this case, the 1083 thing represented by the key is the same and it would be reasonable 1084 to use the same key for both the general and DNS updating / 1085 authenticating roles but the freedom is provided to use different 1086 keys. 1088 It would be desirable for the growth of DNS to be managed so that 1089 additional possible simultaneous uses for names are NOT added. New 1090 uses should be distinguished by exclusive domains. For example, all 1091 telephone numbers in the world have been mapped into the tpc.int 1092 domain of the operational DNS system. This is preferable to having 1093 the same name possibly be a telephone number and a host as well as a 1094 zone and a user, depending on the RRs present. 1096 6.3 RSA RR Flag Bits 1098 Bit 0 (the most significant bit) a zero means the RSA RR asserts 1099 the validity of the public key from the start to the end time, 1100 inclusive. If it is a one, the RSA RR is a revocation of the key as 1101 above. The strength of these assertions depends on the SIG RR(s), if 1102 any, authenticating the RSA RR. 1104 Bits 1 is the "mandatory" bit. Keys may be associated with zone 1105 or entities for experimental, trial, or optional use, in which case 1106 this bit will be zero. If this bit is a one, it means that the use 1107 or availability of security based on the key is "mandatory". Thus, 1108 if this bit is on for a zone, the zone should be assumed secured by 1109 SIG RRs and any responses indicating the zone is not secured should 1110 be considered bogus. Similarly, if this bit were on for a host key 1111 and attempts to negotiate IP-security with the host produced 1112 indications that IP-security was not supported, it should be assumed 1113 that the host has been compromised or communications with it are 1114 being spoofed. On the other hand, if this bit were a zero, the host 1115 might very well sometimes operate in a secure mode and at other times 1116 operate without the availability of IP-security. (This bit is 1117 meaningless in a revocation RSA RR.) 1119 Bits 2-3 are reserved and must be zero. If they are found non- 1120 zero, they should be ignored and the RSA RR used as indicated by the 1121 other flags. 1123 Bit 4 on indicates that this is a zone key for the zone whose 1124 name is the RSA RR owner name. This is the fundamental type of data 1125 origin authentication public key. 1127 Bit 5 on indicates that this is a key associated with the end 1128 entity whose name is the RR owner name by which that entity is 1129 authorized to authenticate DNS entries for itself. This assertion 1130 is, of course, only valid if the asserting RSA RR is signed by a 1131 valid zone key. This is intended to support certain types of dynamic 1132 update. 1134 Bit 6 on indicates that this is a key associated with the end 1135 entity whose name is the RR owner name. This will commonly be a host 1136 but could, in some part of the DNS tree, be some other type of 1137 entity. This is the public key used in connection with the optional 1138 message authentication service defined in this draft. It could also 1139 be used in an IP-security protocol where authentication of a host was 1140 desired. This would be useful in IP or other security for host level 1141 services such as DNS, NTP, routing, etc. 1143 Bit 7 on indicates that this is a key associated with a "user" 1144 or "account" at an end entity, usually a host. The coding of the 1145 owner name is that used for the responsible individual in the SOA 1146 record: The owner name is the user name as the name of a node under 1147 the entity name. For example, "j.random_user" on 1148 host.subdomain.domain could have a public key associated then through 1149 an RSA RR with name j\.random_user.host.subdomain.domain. It could 1150 be used in an IP-security protocol where authentication of a user was 1151 desired. This key would be useful in IP or other security for a user 1152 level service such a telnet, ftp, rlogin, etc. 1154 6.4 RSA RRs in the Construction of Responses 1156 A request for RSA RRs does not cause any additional information 1157 process because of these RSA RRs except, of course, for SIG RRs if 1158 security is requested and available. 1160 Security aware DNS servers will include RSA RRs as additional 1161 information in responses where security is requested under 1162 appropriate conditions as follows: 1164 On the retrieval of NS RRs, the zone key RSA RR for the zone 1165 served by these name servers will be included. If not all additional 1166 info will fit, the RSA RR has higher priority than type A RRs. 1168 On retrieval of type A RRs, the end entity RSA RR for the host 1169 named will be included. On inclusion of A RRs as additional 1170 information, they will also be included but with lower priority than 1171 the relevant A RRs. 1173 On any retrieval with security requested and available from a 1174 zone, any revocation RSAs that fit will be included as additional 1175 information with low priority and the relevant SIGs for such 1176 revocation RSAs will also be included with lower priority than the 1177 RSA RRs they sign. 1179 6.5 File Representation of RSA RRs 1181 RSA RRs may appear as lines in a zone data file. 1183 The time fields appear in the form YYYYMMDDHHMMSS where YYYY is the 1184 year, the first MM is the month number (01-12), DD is the day of the 1185 month (01-31), HH is the hour in 24 hours notation (00-23), the 1186 second MM is the minute (00-59), and SS is the second (00-59). 1188 The flags field is represented as an unsigned integer. 1190 The public key exponent appears as an unsigned integer from 3 to 1191 16777215. 1193 The public key modulus can be quite large, up to 255 octets. It is 1194 the last data field and is represented in hex and may be divided up 1195 into any number of white space separated substrings, down to single 1196 hex digits, which are concatenated to obtain the full signature. 1197 These hex substrings can span lines using the standard parenthesis. 1198 The special case of a null key is indicated by a single zero digit. 1200 7. How to Resolve Securely 1202 Retrieving or resolving secure data from the DNS involves starting 1203 with one or more trusted public keys and, in general, progressing 1204 securely from them through the DNS structure to the zone of interest. 1205 Such trusted public keys would normally be configured in a manner 1206 similar to that described in section 7.1. However, as a practical 1207 matter, a security aware resolver would still gain some confidence in 1208 the results it returns even if it was not configured with any keys 1209 but trusted what it got from a local well known server as a starting 1210 point. 1212 7.1 Boot File Format 1214 The recommended format for a boot file line to configure starting 1215 keys is as follows: 1217 zonekey f.q.d.n exponent modulus 1219 for a zone public key or 1221 hostkey f.q.d.n exponent modulus 1223 for a host public key. f.q.d.n is the domain name of the zone or 1224 host, exponent is the public key exponent between 3 and 16777215, and 1225 modulus is the public key modulus in hex. Appropriate "start" and 1226 "end" times should be synthesized when the boot file is read. 1228 While it might seem logical for everyone to start with the key for 1229 the root zone, this has problems. The logistics of updating every 1230 DNS resolver in the world when the root key changes would be 1231 excessive. It may be some time before there even is a root key. And 1232 furthermore, some organizations may explicitly wish their "interior" 1233 DNS implementations to trust only their own zone. These interior 1234 resolvers can then go through the organization's zone server to 1235 access data outsize the organization's domain. 1237 If desired, the IP address for the f.q.d.n's with configured keys can 1238 generally also be configured via an /etc/hosts or similar local file. 1240 7.2 Chaining Through Zones 1242 Starting with one trusted zone key, it is possible to retrieve signed 1243 keys for subzones which have them. Every secure zone (except root) 1244 should also include the RSA record for its super-zone signed by the 1245 secure zone. This makes it possible to climb the tree of zones if 1246 one starts below root. 1248 A resolver should keep track of the number of successive secure zones 1249 traversed from a starting point to any secure zone it can reach. In 1250 general, the lower such a distance number is, the greater the 1251 confidence in the data and data configured via a boot file should be 1252 given a distance number of zero. Should a query encounter different 1253 data with different distance values, that with a larger value should 1254 be ignored. 1256 A security conscious resolver should completely refuse to step from a 1257 secure zone into a non-secure zone unless the non-secure zone is 1258 certified to be non-secure or only optionally secure by the present 1259 of an authenticated RSA RR for the non-secure zone with a zero length 1260 modulus or the presence of a non-zero length modulus RSA RR without 1261 the mandatory bit set. Otherwise the resolver could be getting 1262 completely bogus or spoofed replies. 1264 If legitimate non-secure zones are encountered in traversing the DNS 1265 tree, then no zone can be trusted as secure that can be reached only 1266 via information from such non-secure zones. Since the non-secure zone 1267 data could have been spoofed, the "secure" zone reach via it could be 1268 counterfeit. The "distance" to data in such zones or zones reached 1269 via such zones could be set to 512 or more as this exceeds the 1270 largest possible distance through secure zones in the DNS. Never the 1271 less, continuing to apply secure checks withing "secure" zones 1272 reached via non-secure zones will, as a practical matter, provide 1273 some increase in security. 1275 7.3 Secure Time 1277 Coordinated interpretation of the time fields in SIG and RSA RRs 1278 requires that secure consistent time be available to the hosts 1279 implementing the DNS security extensions. The Network Time Protocol 1280 (NTP) [ref] provides an excellent means for coordinating consistent 1281 time. It also includes strong security but has no key management 1282 provisions. It just assumes that symmetric keying material will be 1283 on each pair of communicating nodes. 1285 In the absence of security, NTP or other time synchronization 1286 protocols could be spoofed. A solution to this would be to do NTP 1287 over IP-security. This may seem circular, where the security system 1288 is used to protect the synchronization of time needed for the 1289 security system. In practice, manual set up of approximate time 1290 would be adequate to bootstrap the system which could then securely 1291 synchronize itself more accurately. 1293 To accommodate the secure time requirement, all DNS servers should 1294 also be NTP servers. 1296 NTP assumes that time servers are organized into numbered strata 1297 where the servers at each strata are clients to a lower numbered 1298 strata and servers to higher numbered strata. This can be 1299 accomplished in the DNS context by have each primary or secondary DNS 1300 server be an NTP client to the servers up the DNS tree from those 1301 zones they provide (ignoring zones that are subzones of other zones 1302 the server carries). Stub resolvers or the like could look to their 1303 default server for NTP service. Special arrangements would have to 1304 been made for the root primary and its secondaries to either have 1305 reliable hardware time sources or be secure clients to machines with 1306 such sources. 1308 8. Operational Considerations 1310 8.1 Modulus Size Considerations 1312 There are a number of factors that effect modulus size choice for use 1313 in the DNS security extension. Unfortunately, these factors do not 1314 all point in the same direction. Choice of a modulus size should be 1315 made by the zone administrator depending on their local conditions. 1317 Larger moduluses are more secure but slower. The recommended minimum 1318 modulus size, 641 bit, is believed by the authors to be secure at 1319 this time and for some years but high level nodes in the DNS tree may 1320 wish to set a higher minimum, perhaps 1000 bits, for security 1321 reasons. (Since the United States National Security Agency generally 1322 permits export of encryption systems using an RSA modulus of up to 1323 512 bits, use of that small a modulus, i.e. n, must be considered 1324 weak.) 1326 Because this protocol packs information inside an RSA signature, 1327 larger moduluses also increase the efficiency of use of space with 1328 SIG RRs. There is a 22 byte overhead (prefix and self hash) within 1329 the signature plus all the SIG RR fields outside of the signature. 1330 However, larger moduluses also lead to larger SIG RRs which may lead 1331 to lower packing density of SIG RRs in a maximum length DNS UDP 1332 packet. 1334 With the minimum modulus size required by this protocol, the 1335 signature before RSA encoding is 80 octets (usually resulting in 81 1336 octets after encoding). After deducting 2 octets for the minimum 01 1337 00 signature prefix and 20 octets for a hashed self signet, 56 octets 1338 would be available for other signets. With the maximum modulus size 1339 permitted by this protocol, the signature is usually 255 octets which 1340 leaves 233 bytes for other signets. 1342 Zones may wish to adopt policies on the size of host, user, or even 1343 subzone keys within them such that the RSA RRs for these keys will 1344 fit within a zone signed SIG for efficiency. 1346 8.2 Key Storage 1348 It is strongly recommended that zone private keys and the zone file 1349 master copy be kept and used in off-line non-network connected 1350 machines. Periodically an application can be run to re-sign the RRs 1351 in a zone by adding SIG RRs and then the signed file transferred, 1352 perhaps by sneaker-net, to the networked server machine. 1354 The idea is to have a one way information flow to the network to 1355 avoid the possibility of tampering from the network. Keeping the 1356 zone master file on-line on the network and simply cycling it through 1357 an off-line signer does not do this. The on-line version could still 1358 be tampered with if the host it resides on is compromised. The 1359 master copy of the zone file should also be off net and should not be 1360 updated based on a solely network mediated communication. 1362 8.3 Key Generation 1364 Careful key generation is a sometimes over looked but absolutely 1365 essential element in any cryptographically secure system. The 1366 strongest algorithms used with the longest keys are still of no use 1367 if an adversary can guess enough to lower the size of the likely key 1368 space so that it can be exhaustively searched. Suggestions will be 1369 found in draft-ietf-security-randomness-01.txt. 1371 8.4 Key Lifetimes 1373 No key should be used forever. The longer a key is in use, the 1374 greater the probability that it will have been compromised through 1375 carelessness, accident, espionage, or cryptanalysis. 1377 No DNS security extensions key should have a lifetime significantly 1378 over five years. The recommended lifetime for zone keys that are 1379 kept off-line and carefully guarded is 13 months with the intent that 1380 they be replaced every year. The recommended lifetime for host keys 1381 that are used for IP-security or the like and are kept on line is 35 1382 days with the intent that they be replaced monthly. 1384 8.5 Key Revocation 1386 In cases where an erroneous signed key exists in the DNS system, it 1387 is useful to be able to propagate a revocation. In most cases, the 1388 natural refresh processes of DNS will eventually obtain valid up to 1389 date key information for secondaries. However, there could be stale 1390 information out in caching servers or the like for a long time, 1391 particularly since accident or malicious action could have cause RRs, 1392 including SIGs, RSAs, etc., with very long TTLs and/or distant end- 1393 times to be distributed. 1395 There are limits to how much can be done about this problem. The DNS 1396 security extensions provide for revocation of keys. The revocation 1397 information is provided when current key information is retrieved. 1399 In addition, security aware servers opportunisticly flood revocation 1400 information by including it with low priority in the additional 1401 information section of any retrieval from the zone containing the 1402 revoked key. It is a matter of server policy how to choose which 1403 extra revocations to include as additional information. Some 1404 revocations may be "more important" than others or it may be best to 1405 simply pick as much as will fit at random. 1407 On receipt of an authenticated revocation, a resolver should expunge 1408 all RRs authenticated by the revoked key. It is a matter of resolver 1409 policy what revocations, if any, to cache and for how long. If a 1410 relavent revocation is received by a resolver but is not accompanied 1411 by an authenticating SIG, the resolver should normally attempt to 1412 retrieve such a SIG. 1414 Resolvers can not keep an indefinite number of revocations for an 1415 indefinite time. The possibility of denial of service attacks based 1416 on fabricating many revocations must be considered. 1418 It should be noted that like assertions, revocations have start and 1419 end times. Thus, for example, a valid key validly generated but 1420 accidentally given an excessive lifetime can be revoked for just the 1421 later part of that lifetime by setting appropriate times in the 1422 revocation RSA RR. 1424 8.6 Root 1426 The root zone RSA key is self-signed. 1428 It should also be noted that in DNS the root is a zone unto itself. 1429 Thus the root key should only be see signing itself or signing RRs 1430 with names one level below root, such as .aq, edu, or .arpa. 1432 9. Conformance 1434 [this section needs work ...] 1436 - Security aware server needs to respond normally to requests that do 1437 not have the Security Desired bit set. [should response still have 1438 the Security Available bit set if SD wasn't?] 1440 - Minimal server compliance is ability to handle SIG and RSA RRs in 1441 zone files, etc. 1443 - Full server compliance is ability to handle SD and SA bits, 1444 automatically include SIG and RSA RRs in responses as appropriate, 1445 etc. 1447 - Resolver compliance... 1449 10. Security Considerations 1451 The entirety of this document concerns extensions to the Domain Name 1452 System (DNS) protocol to provide data origin authentication, DNS 1453 message authentication, and key storage. 1455 References 1457 [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 1458 3 June 1991, Version 1.4. 1460 [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 1462 [RFC1033] - Domain Administrators Operations Guide, M. Lottor, 1463 November 1987 1465 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 1466 November 1987 1468 [RFC1035] - Domain Names - Implementation and Specifications 1470 [SHS] - NIST FIPS PUB 180, Secure Hash Standard, National Institute 1471 of Science and Technology, U.S. Department of Commerce, April 1993. 1473 Authors Addresses 1475 Donald E. Eastlake 3rd 1476 Digital Equipment Corporation 1477 550 King Street, LKG2-1/BB3 1478 Littleton, MA 01460 1480 Telephone: +1 508 486 6577(w) +1 508 287 4877(h) 1481 EMail: dee@lkg.dec.com 1483 Charles W. Kaufman 1484 Digital Equipment Corporation 1485 110 Spit Brook Road, ZKO3-3/U14 1486 Nashua, NH 03062 1488 Telephone: +1 603-881-1495 1489 EMail: kaufman@zk3.dec.com 1491 Expiration and File Name 1493 This draft expires 22 August 1994 1495 Its file name is draft-ietf-dnssec-secext-00.txt.