idnits 2.17.1 draft-ietf-dnssec-secext-08.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-19) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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-08.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-secext-08.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-secext-08.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-08.txt,', but the file name used is 'draft-ietf-dnssec-secext-08' == 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 are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 11 instances of lines with non-RFC2606-compliant FQDNs in the document. ** 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 432: '... implementations MUST be designed to h...' RFC 2119 keyword, line 714: '...ese name servers MUST be included as a...' RFC 2119 keyword, line 945: '... be 1) SHALL be not less than 512 bi...' RFC 2119 keyword, line 946: '... and e SHOULD be chosen such that th...' RFC 2119 keyword, line 973: '...FR SIG, the zone MAY be considered val...' (21 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 (9 January 1996) is 10328 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) == Missing Reference: 'RFC 1825' is mentioned on line 562, but not defined ** Obsolete undefined reference: RFC 1825 (Obsoleted by RFC 2401) == Missing Reference: 'RFC 1530' is mentioned on line 550, but not defined == Unused Reference: 'RFC1032' is defined on line 1712, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1717, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1720, but no explicit reference was found in the text == Unused Reference: 'RFC1305' is defined on line 1722, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1724, but no explicit reference was found in the text == Unused Reference: 'RFC1530' is defined on line 1727, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 1730, but no explicit reference was found in the text == Unused Reference: 'RFC1825' is defined on line 1733, but no explicit reference was found in the text == Unused Reference: 'RSA FAQ' is defined on line 1736, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'NETSEC' -- 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 ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 1530 ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA FAQ' Summary: 20 errors (**), 1 flaw (~~), 16 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Security Working Group Donald E. Eastlake 3rd 2 INTERNET-DRAFT CyberCash 3 UPDATES RFC 1034, 1035 Charles W. Kaufman 4 Iris 5 Expires: 8 July 1996 9 January 1996 7 Domain Name System Security Extensions 8 ------ ---- ------ -------- ---------- 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-secext-08.txt, is intended to 13 be become a Proposed Standard RFC. Distribution of this document is 14 unlimited. Comments should be sent to the DNS Security Working Group 15 mailing list or to the authors. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 31 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 32 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 34 Abstract 36 The Domain Name System (DNS) has become a critical operational part 37 of the Internet infrastructure yet it has no strong security 38 mechanisms to assure data integrity or authentication. Extensions to 39 the DNS are described that provide these services to security aware 40 resolvers or applications through the use of cryptographic digital 41 signatures. These digital signatures are included in secured zones 42 as resource records. Security can still be provided even through 43 non-security aware DNS servers in many cases. 45 The extensions also provide for the storage of authenticated public 46 keys in the DNS. This storage of keys can support general public key 47 distribution service as well as DNS security. The stored keys enable 48 security aware resolvers to learn the authenticating key of zones in 49 addition to those for which they are initially configured. Keys 50 associated with DNS names can be retrieved to support other 51 protocols. Provision is made for a variety of key types and 52 algorithms. 54 In addition, the security extensions provide for the optional 55 authentication of DNS protocol transactions. 57 Acknowledgments 59 The significant contributions of the following persons (in alphabetic 60 order) to this draft are gratefully acknowledged: 62 Madelyn Badger 63 Matt Crawford 64 James M. Galvin 65 Olafur Gudmundsson 66 Edie Gunter 67 Sandy Murphy 68 Masataka Ohta 69 Michael A. Patton 70 Jeffrey I. Schiller 72 Table of Contents 74 Status of This Document....................................1 76 Abstract...................................................2 77 Acknowledgments............................................2 79 Table of Contents..........................................3 81 1. Overview of Contents....................................5 83 2. Overview of the Extensions.............................6 84 2.1 Services Not Provided..................................6 85 2.2 Key Distribution.......................................6 86 2.3 Data Origin Authentication and Integrity...............7 87 2.3.1 The SIG Resource Record..............................8 88 2.3.2 Authenticating Name and Type Non-existence...........8 89 2.3.3 Special Considerations With Time-to-Live.............8 90 2.3.4 Special Considerations at Delegation Points..........9 91 2.3.5 Special Considerations with CNAME RRs................9 92 2.3.6 Signers Other Than The Zone.........................10 93 2.4 DNS Transaction and Request Authentication............10 95 3. The KEY Resource Record................................12 96 3.1 KEY RDATA format......................................12 97 3.2 Object Types, DNS Names, and Keys.....................12 98 3.3 The KEY RR Flag Field.................................13 99 3.4 The Protocol Octet....................................15 100 3.5 The KEY Algorithm Number and the MD5/RSA Algorithm....16 101 3.6 Interaction of Flags, Algorithm, and Protocol Bytes...17 102 3.7 KEY RRs in the Construction of Responses..............17 103 3.8 File Representation of KEY RRs........................18 105 4. The SIG Resource Record................................19 106 4.1 SIG RDATA Format......................................19 107 4.1.1 Signature Data......................................21 108 4.1.2 MD5/RSA Algorithm Signature Calculation.............22 109 4.1.3 Zone Transfer (AXFR) SIG............................23 110 4.1.4 Transaction and Request SIGs........................24 111 4.2 SIG RRs in the Construction of Responses..............24 112 4.3 Processing Responses and SIG RRs......................25 113 4.4 Signature Expiration, TTLs, and Validity..............26 114 4.5 File Representation of SIG RRs........................26 116 5. Non-existent Names and Types...........................28 117 5.1 The NXT Resource Record...............................28 118 5.2 NXT RDATA Format......................................29 119 5.3 Example...............................................30 120 5.4 Interaction of NXT RRs and Wildcard RRs...............30 121 5.5 Blocking NXT Pseudo-Zone Transfers....................31 122 5.6 Special Considerations at Delegation Points...........32 124 6. The AD and CD Bits and How to Resolve Securely.........33 125 6.1 The AD and CD Header Bits.............................33 126 6.2 Boot File Format......................................34 127 6.3 Chaining Through Zones................................35 128 6.4 Secure Time...........................................36 130 7. Operational Considerations.............................37 131 7.1 Key Size Considerations...............................37 132 7.2 Key Storage...........................................37 133 7.3 Key Generation........................................38 134 7.4 Key Lifetimes.........................................38 135 7.5 Signature Lifetime....................................39 136 7.6 Root..................................................39 138 8. Conformance............................................40 139 8.1 Server Conformance....................................40 140 8.2 Resolver Conformance..................................40 142 9. Security Considerations................................41 144 References................................................42 146 Authors Addresses.........................................43 147 Expiration and File Name..................................43 149 Appendix: Base 64 Encoding................................44 151 1. Overview of Contents 153 This draft describes extensions of the Domain Name System (DNS) 154 protocol to support DNS security and public key distribution. It 155 assumes that the reader is familiar with the Domain Name System, 156 particularly as described in RFCs 1033, 1034, and 1035. 158 Section 2 provides a detailed overview of the extensions and the key 159 distribution, data origin authentication, and transaction and request 160 security they provide. 162 Section 3 discusses the KEY resource record, its structure, use in 163 DNS responses, and file representation. These resource records 164 represent the public keys of entities named in the DNS and are used 165 for key distribution. 167 Section 4 discusses the SIG digital signature resource record, its 168 structure, use in DNS responses, and file representation. These 169 resource records are used to authenticate other resource records in 170 the DNS and optionally to authenticate DNS transactions and requests. 172 Section 5 discusses the NXT resource record and its use in DNS 173 responses. The NXT RR permits authenticated denial in the DNS of the 174 existence of a name or of a particular type for an existing name. 176 Section 6 discusses how a resolver can be configured with a starting 177 key or keys and proceed to securely resolve DNS requests. 178 Interactions between resolvers and servers are discussed for all 179 combinations of security aware and security non-aware. Two 180 additional query header bits are defined for signaling between 181 resolvers and servers. 183 Section 7 reviews a variety of operational considerations including 184 key generation, lifetime, and storage. 186 Section 8 defines levels of conformance for resolvers and servers. 188 Section 9 provides a few paragraphs on overall security 189 considerations. 191 An Appendix is provided that gives some details of base 64 encoding 192 which is used in the file representation of some RR's defined in this 193 draft. 195 2. Overview of the Extensions 197 The Domain Name System (DNS) protocol security extensions provide 198 three distinct services: key distribution as described in Section 2.2 199 below, data origin authentication as described in Section 2.3 below, 200 and transaction and request authentication, described in Section 2.4 201 below. 203 Special considerations related to "time to live", CNAMEs, and 204 delegation points are also discussed in Section 2.3. 206 2.1 Services Not Provided 208 It is part of the design philosophy of the DNS that the data in it is 209 public and that the DNS gives the same answers to all inquirers. 211 Following this philosophy, no attempt has been made to include any 212 sort of access control lists or other means to differentiate 213 inquirers. 215 In addition, no effort has been made to provide for any 216 confidentiality for queries or responses. (This service may be 217 available via IPSEC [RFC 1825].) 219 2.2 Key Distribution 221 Resource records (RRs) are defined to associate keys with DNS names. 222 This permits the DNS to be used as a general public key distribution 223 mechanism in support of the data origin authentication and 224 transaction authentication DNS services as well as other security 225 services. 227 The syntax of a KEY resource record (RR) is described in Section 3. 228 It includes an algorithm identifier, the actual public key 229 parameters, and a variety of flags including those indicating the 230 type of entity the key is associated with and/or asserting that there 231 is no key associated with that entity. 233 Under conditions described in Section 3, security aware DNS servers 234 will automatically attempt to return KEY resources as additional 235 information, along with those resource records actually requested, to 236 minimize the number of queries needed. 238 2.3 Data Origin Authentication and Integrity 240 Authentication is provided by associating with resource records in 241 the DNS cryptographically generated digital signatures. Commonly, 242 there will be a single private key that signs for an entire zone. If 243 a security aware resolver reliably learns the public key of the zone, 244 it can verify, for signed data read from that zone, that it was 245 properly authorized and is reasonably current. The expected 246 implementation is for the zone private key to be kept off-line and 247 used to re-sign all of the records in the zone periodically. 249 This data origin authentication key belongs to the zone and not to 250 the servers that store copies of the data. That means compromise of 251 a server or even all servers for a zone will not necessarily affect 252 the degree of assurance that a resolver has that it can determine 253 whether data is genuine. 255 A resolver can learn the public key of a zone either by reading it 256 from DNS or by having it staticly configured. To reliably learn the 257 public key by reading it from DNS, the key itself must be signed. 258 Thus, to provide a reasonable degree of security, the resolver must 259 be configured with at least the public key of one zone that it can 260 use to authenticate signatures. From there, it can securely read the 261 public keys of other zones, if the intervening zones in the DNS tree 262 are secure. (It is in principle more secure to have the resolver 263 manually configured with the public keys of multiple zones, since 264 then the compromise of a single zone would not permit the faking of 265 information from other zones. It is also more administratively 266 cumbersome, however, particularly when public keys change.) 268 Adding data origin authentication and integrity requires no change to 269 the "on-the-wire" DNS protocol beyond the addition of the signature 270 resource type and, as a practical matter, the key resource type 271 needed for key distribution. This service can be supported by 272 existing resolver and server implementations so long as they can 273 support the additional resource types (see Section 8). The one 274 exception is that CNAME referrals from a secure zone can not be 275 authenticated if they are from non-security aware servers (see 276 Section 2.3.5). 278 If signatures are always separately retrieved and verified when 279 retrieving the information they authenticate, there will be more 280 trips to the server and performance will suffer. To avoid this, 281 security aware servers mitigate that degradation by always attempting 282 to send the signature(s) needed. 284 2.3.1 The SIG Resource Record 286 The syntax of a SIG resource record (signature) is described in 287 Section 4. It includes the type of the RR(s) being signed, the name 288 of the signer, the time at which the signature was created, the time 289 it expires (when it is no longer to be believed), its original time 290 to live (which may be longer than its current time to live but cannot 291 be shorter), the cryptographic algorithm in use, and the actual 292 signature. 294 Every name in a secured zone will have associated with it at least 295 one SIG resource record for each resource type under that name. A 296 security aware server supporting the performance enhanced version of 297 the DNS protocol security extensions will attempt to return, with all 298 records retrieved, the corresponding SIGs. If a server does not 299 support the protocol, the resolver must retrieve all the SIG records 300 for a name and select the one or ones that sign the resource 301 record(s) that resolver is interested in. 303 2.3.2 Authenticating Name and Type Non-existence 305 The above security mechanism provides only a way to sign existing RRs 306 in a zone. "Data origin" authentication is not obviously provided 307 for the non-existence of a domain name in a zone or the non-existence 308 of a type for an existing name. This gap is filled by the NXT RR 309 which authenticatably asserts a range of non-existent names in a zone 310 and the non-existence of types for the name just before that range. 312 Section 5 below covers the NXT RR. 314 2.3.3 Special Considerations With Time-to-Live 316 A digital signature will fail to verify if any change has occurred to 317 the data between the time it was originally signed and the time the 318 signature is verified. This conflicts with our desire to have the 319 time-to-live field tick down when resource records are cached. 321 This could be avoided by leaving the time-to-live out of the digital 322 signature, but that would allow unscrupulous servers to set 323 arbitrarily long time to live values undetected. Instead, we include 324 the "original" time-to-live in the signature and communicate that 325 data in addition to the current time-to-live. Unscrupulous servers 326 under this scheme can manipulate the time to live but a security 327 aware resolver will bound the TTL value it uses at the original 328 signed value. Separately, signatures include a time signed and an 329 expiration time. A resolver that knows the absolute time can 330 determine securely whether a signature has expired. It is not 331 possible to rely solely on the signature expiration as a substitute 332 for the TTL, however, since the TTL is primarily a database 333 consistency mechanism and, in any case, non-security aware servers 334 that depend on TTL must still be supported. 336 2.3.4 Special Considerations at Delegation Points 338 DNS security would like to view each zone as a unit of data 339 completely under the control of the zone owner and signed by the 340 zone's key. But the operational DNS views the leaf nodes in a zone 341 which are also the apex nodes of a subzone (i.e., delegation points) 342 as "really" belonging to the subzone. These nodes occur in two 343 master files and may have RRs signed by both the upper and lower 344 zone's keys. A retrieval could get a mixture of these RRs and SIGs, 345 especially since one server could be serving both the zone above and 346 below a delegation point. 348 In general, there must be a zone KEY RR for the subzone in the 349 superzone and the copy signed in the superzone is controlling. For 350 all other RRs that should appearing in both the superzone and 351 subzone, the data from the subzone is more authoritative. To avoid 352 conflicts, only the KEY RR in the superzone should be signed and the 353 NS and any A (glue) RRs should only be signed in the subzone. The SOA 354 and any other RRs that have the zone name as owner should appear only 355 in the subzone and thus are signed there. The NXT RR type is an 356 exceptional case that will always appear differently and 357 authoritatively in both the superzone and subzone, if both are 358 secure, as described in Section 5. 360 2.3.5 Special Considerations with CNAME RRs 362 There is a significant problem when security related RRs with the 363 same owner name as a CNAME RR are retrieved from a non-security-aware 364 server. In particular, an initial retrieval for the CNAME or any 365 other type will not retrieve any associated signature, key, or NXT 366 RR. For types other than CNAME, it will retrieve that type at the 367 target name of the CNAME (or chain of CNAMEs) and will return the 368 CNAME as additional information. In particular, a specific retrieval 369 for type SIG will not get the SIG, if any, at the original CNAME 370 domain name but rather a SIG at the target name. 372 In general, security aware servers must be used to securely CNAME in 373 DNS. Security aware servers must (1) allow KEY, SIG, and NXT RRs 374 along with CNAME RRs, (2) suppress CNAME processing on retrieval of 375 these types as well as on retrieval of the type CNAME, and (3) 376 automatically return SIG RRs authenticating the CNAME or CNAMEs 377 encountered in resolving a query. This is a change from the previous 378 DNS standard which prohibited any other RR type at a node where a 379 CNAME RR was present. 381 2.3.6 Signers Other Than The Zone 383 There are two cases where a SIG resource record is signed by other 384 than the zone private key. One is for support of dynamic update 385 where an entity is permitted to authenticate/update its own records. 386 The public key of the entity must be present in the DNS and be 387 appropriately signed but the other RR(s) may be signed with the 388 entity's key. The other is for support of transaction and request 389 authentication as described in Section 2.4 immediately below. 391 2.4 DNS Transaction and Request Authentication 393 The data origin authentication service described above protects 394 retrieved resource records but provides no protection for DNS 395 requests or for message headers. 397 If header bits are falsely set by a server, there is little that can 398 be done. However, it is possible to add transaction authentication. 399 Such authentication means that a resolver can be sure it is at least 400 getting messages from the server it thinks it queried, that the 401 response is from the query it sent, and that these messages have not 402 been diddled in transit. This is accomplished by optionally adding a 403 special SIG resource record at the end of the reply which digitally 404 signs the concatenation of the server's response and the resolver's 405 query. 407 Requests can also be authenticated by including a special SIG RR at 408 the end of the request. Authenticating requests serves no function 409 in the current DNS and requests with a non-empty additional 410 information section are ignored by almost all current DNS servers. 411 However, this syntax for signing requests is defined in connection 412 with authenticating future secure dynamic update requests or the 413 like. 415 The private key used in transaction security belongs to the host 416 composing the reply message, not to the zone involved. The 417 corresponding public key is normally stored in and retrieved from the 418 DNS. 420 Because requests and replies are highly variable, message 421 authentication SIGs can not be pre-calculated. Thus it will be 422 necessary to keep the private key on-line, for example in software or 423 in a directly connected piece of hardware. 425 3. The KEY Resource Record 427 The KEY resource record (RR) is used to document a key that is 428 associated with a Domain Name System (DNS) name. It will be a public 429 key as only public keys are stored in the DNS. This can be the 430 public key of a zone, a host or other end entity, or a user. A KEY 431 RR is, like any other RR, authenticated by a SIG RR. Security aware 432 DNS implementations MUST be designed to handle at least two 433 simultaneously valid keys of the same type associated with a name. 435 The type number for the KEY RR is 25. 437 3.1 KEY RDATA format 439 The RDATA for a KEY RR consists of flags, a protocol octet, the 440 algorithm number, and the public key itself. The format is as 441 follows: 443 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | flags | protocol | algorithm | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | / 449 / public key / 450 / / 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 453 The meaning of the KEY RR owner name, flags, and protocol octet are 454 described in Sections 3.2, 3.3 and 3.4 below respectively. The flags 455 and algorithm must be examined before any data following the 456 algorithm octet as they control the format and even whether there is 457 any following data. The algorithm and public key fields are 458 described in Section 3.5. The format of the public key is algorithm 459 dependent. 461 3.2 Object Types, DNS Names, and Keys 463 The public key in a KEY RR belongs to the object named in the owner 464 name. 466 This DNS name may refer to up to three different categories of 467 things. For example, dee.cybercash.com could be (1) a zone, (2) a 468 host or other end entity , and (3) the mapping into a DNS name of the 469 user or account dee@cybercash.com. Thus, there are flags, as 470 described below, in the KEY RR to indicate with which of these roles 471 the owner name and public key are associated. Note that an 472 appropriate zone KEY RR must occur at the apex node of a secure zone 473 and at every leaf node which is a delegation point (and thus the same 474 owner name as the apex of a subzone) within a secure zone. 476 Although the same name can be used for up to all three of these 477 categories, such overloading of a name is discouraged. It is also 478 possible to use the same key for different things with the same name 479 or even different names, but this is strongly discouraged. In 480 particular, the use of a zone key as a non-zone key will usually 481 require that the corresponding private key be kept on line and 482 thereby become more vulnerable. 484 It would be desirable for the growth of DNS to be managed so that 485 additional possible simultaneous uses for names are NOT added. New 486 uses should be distinguished by exclusive domains. For example, all 487 IP autonomous system numbers have been mapped into the in-as.arpa 488 domain [draft-ietf-dnssec-as-map-*.txt (may have an RFC number if 489 issued simultaneously with this draft)], all telephone numbers in the 490 world have been mapped into the tpc.int domain [RFC 1530], and all 491 IPv4 addresses (i.e., all IPv4 globally addressable interfaces) have 492 been mapped into the in-addr.arpa domain. This is much preferable to 493 having the same fully qualified name simultaneously be a possible 494 autonomous system number, telephone number, IPv4 interface, and/or 495 host as well as a zone and a user. 497 In addition to the name type bits, there are additional flag bits 498 including the "type" field, "experimental" bit, "signatory" field, 499 etc., as described below. 501 3.3 The KEY RR Flag Field 503 In the "flags" field: 505 Bit 0 and 1 are the "type" field. Bit 0 a one indicates that 506 use of the key is prohibited for authentication. Bit 1 a one 507 indicates that use of the key is prohibited for confidentiality. If 508 this field is zero, then use of the key for authentication and/or 509 confidentiality is permitted. Note that DNS security makes use of 510 keys for authentication only. Confidentiality use flagging is 511 provided for use of keys in other protocols. If both bits of this 512 field are one, "no key" value, there is no key information and the RR 513 stops after the algorithm octet. By the use of this "no key" value, 514 a signed KEY RR can authenticatably assert that, for example, a zone 515 is not secured. 517 Bit 2 is the "experimental" bit. It is ignored if the type 518 field indicates "no key" and the following description assumes that 519 type field to be non-zero. Keys may be associated with zones, 520 entities, or users for experimental, trial, or optional use, in which 521 case this bit will be one. If this bit is a zero, it means that the 522 use or availability of security based on the key is "mandatory". 523 Thus, if this bit is off for a zone key, the zone should be assumed 524 secured by SIG RRs and any responses indicating the zone is not 525 secured should be considered bogus. If this bit is a one for a host 526 or end entity, it might sometimes operate in a secure mode and at 527 other times operate without security. The experimental bit, like all 528 other aspects of the KEY RR, is only effective if the KEY RR is 529 appropriately signed by a SIG RR. The experimental bit must be zero 530 for safe secure operation and should only be a one for a minimal 531 transition period. 533 Bits 3-4 are reserved and must be zero. 535 Bit 5 on indicates that this is a key associated with a "user" 536 or "account" at an end entity, usually a host. The coding of the 537 owner name is that used for the responsible individual mailbox in the 538 SOA and RP RRs: The owner name is the user name as the name of a node 539 under the entity name. For example, "j.random_user" on 540 host.subdomain.domain could have a public key associated through a 541 KEY RR with name j\.random_user.host.subdomain.domain and the user 542 bit a one. It could be used in an security protocol where 543 authentication of a user was desired. This key might be useful in IP 544 or other security for a user level service such a telnet, ftp, 545 rlogin, etc. 547 Bit 6 on indicates that this is a key associated with the non- 548 zone "entity" whose name is the RR owner name. This will commonly be 549 a host but could, in some parts of the DNS tree, be some other type 550 of entity such as a telephone number [RFC 1530] or autonomous system 551 number [draft-ietf-dnssec-as-map-*.txt (may have an RFC number if 552 issued simultaneously with this draft)]. This is the public key used 553 in connection with the optional DNS transaction authentication 554 service if the owner name is a DNS server host. It could also be 555 used in an IP-security protocol where authentication of at the host, 556 rather than user, level was desired, such as routing, NTP, etc. 558 Bit 7 is the "zone" bit and indicates that this is a zone key 559 for the zone whose name is the KEY RR owner name. This is the 560 primary type of DNS data origin authentication public key. 562 Bit 8 is reserved to be the IPSEC [RFC 1825] bit and indicate 563 that this key is valid for use in conjunction with that security 564 standard. This key could be used in connection with secured 565 communication on behalf of an end entity or user whose name is the 566 owner name of the KEY RR if the entity or user bits are on. The 567 presence of a KEY resource with the IPSEC and entity bits on and 568 experimental and no-key bits off is a guarantee that the host speaks 569 IPSEC. 571 Bit 9 is reserved to be the "email" bit and indicate that this 572 key is valid for use in conjunction with MIME security multiparts. 573 This key could be used in connection with secured communication on 574 behalf of an end entity or user whose name is the owner name of the 575 KEY RR if the entity or user bits are on. 577 Bits 10-11 are reserved and must be zero. 579 Bits 12-15 are the "signatory" field. If non-zero, they 580 indicate that the key can validly sign RRs or updates of the same 581 name. If the owner name is a wildcard, then RRs or updates with any 582 name which is in the wildcard's scope can be signed. Fifteen 583 different non-zero values are possible for this field and any 584 differences in their meaning are reserved for definition in 585 connection with DNS dynamic update or other new DNS commands. Zone 586 keys always have authority to sign any RRs in the zone regardless of 587 the value of this field. The signatory field, like all other aspects 588 of the KEY RR, is only effective if the KEY RR is appropriately 589 signed by a SIG RR. 591 3.4 The Protocol Octet 593 It is anticipated that some keys stored in DNS will be used in 594 conjunction with Internet protocols other than DNS (keys with zone 595 bit or signatory field non-zero) and IPSEC/email (keys with IPSEC 596 and/or email bit set). The protocol octet is provided to indicate 597 that a key is valid for such use and, for end entity keys or the host 598 part of user keys, that the secure version of that protocol is 599 implemented on that entity or host. 601 Values between 1 and 191 decimal inclusive are available for 602 assignment by IANA for such protocols. The 63 values between 192 and 603 254 inclusive will not be assigned to a specific protocol and are 604 available for experimental use under bilateral agreement. Value 0 605 indicates, for a particular key, that it is not valid for any 606 particular additional protocol beyond those indicated in the flag 607 field. And value 255 indicates that the key is valid for all assigned 608 protocols (those in the 1 to 191 range). 610 It is intended that new uses of DNS stored keys would initially be 611 implemented, and operational experience gained, using the 612 experimental range of the protocol octet. If demand for widespread 613 deployment for the indefinite future warrants, a value in the 614 assigned range would then be designated for the protocol. Finally, 615 (1) should the protocol become so widespread in conjunction with 616 other protocols and with which it shares key values that duplicate 617 RRs are a serious burden and (2) should the protocol provide 618 substantial facilities not available in any protocol for which a 619 flags field bit has been allocated, then one of the four remaining 620 flag field bits may be allocated to the protocol. When such a bit has 621 been allocated, a key can be simultaneously indicated as valid for 622 that protocol and the entity or host can be simultaneously flagged as 623 implementing the secure version of that protocol, along with other 624 protocols for which flag field bits have been assigned. 626 Note that the IPSEC protocol being developed may provide facilities 627 adequate for all point to point communication over IP meaning that 628 additional flag field bits would only be assigned, when appropriate 629 as indicated above, to protocols with a store-and-forward nature or 630 otherwise not subsumed into a point-to-point paradigm. 632 3.5 The KEY Algorithm Number and the MD5/RSA Algorithm 634 This octet is the key algorithm parallel to the same field for the 635 SIG resource. The MD5/RSA algorithm described in this draft is 636 number 1. Numbers 2 through 252 are available for assignment should 637 sufficient reason arise. However, the designation of a new algorithm 638 could have a major impact on interoperability and requires an IETF 639 standards action. Number 254 is reserved for private use and will 640 never be assigned a specific algorithm. For number 254, the public 641 key area shown in the packet diagram above will actually begin with 642 an Object Identifier (OID) indicating the private algorithm in use 643 and the remainder of the area is whatever is required by that 644 algorithm. Number 253 is reserved as the "expiration date algorithm" 645 for use where the expiration date or other labeling fields of SIGs 646 are desired without any actual security. It is anticipated that this 647 algorithm will only be used in connection with some modes of DNS 648 dynamic update. For number 253, the public key area is null. Values 649 0 and 255 are reserved. 651 If the type field does not have the "no key" value and the algorithm 652 field is 1, indicating the MD5/RSA algorithm, the public key field is 653 structured as follows: 655 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | pub exp length| public key exponent / 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | / 661 +- modulus / 662 | / 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 664 To promote interoperability, the exponent and modulus are each 665 limited to 2552 bits in length. The public key exponent is a 666 variable length unsigned integer. Its length in octets is 667 represented as one octet if it is in the range of 1 to 255 and by a 668 zero octet followed by a two octet unsigned length if it is longer 669 than 255 bytes. The public key modulus field is a multiprecision 670 unsigned integer. The length of the modulus can be determined from 671 the RDLENGTH and the preceding RDATA fields including the exponent. 672 Leading zero bytes are prohibited in the exponent and modulus. 674 3.6 Interaction of Flags, Algorithm, and Protocol Bytes 676 Various combinations of the no-key type value, algorithm byte, 677 protocol byte, and any protocol indicating flags (such as the 678 reserved IPSEC flag) are possible. (Note that the zone flag bit 679 being on or the signatory field being non-zero is effectively a DNS 680 protocol flag on.) The meaning of these combinations is indicated 681 below: 683 NK = no key type value 684 AL = algorithm byte 685 PR = protocols indicated by protocol byte or protocol flags 687 x represents any valid non-zero value(s). 689 AL PR NK Meaning 690 0 0 0 Illegal, claims key but has bad algorithm field. 691 0 0 1 Specifies total lack of security for owner. 692 0 x 0 Illegal, claims key but has bad algorithm field. 693 0 x 1 Specified protocols insecure, others may be secure. 694 x 0 0 Useless. Gives key but no protocols to use it. 695 x 0 1 Useless. Denies key but for no protocols. 696 x x 0 Specifies key for protocols and certifies that 697 those protocols are implemented with security. 698 x x 1 Algorithm not understood for protocol. 700 (remember, in reference to the above table, that a protocol 701 byte of 255 means all protocols with protocol byte values 702 assigned) 704 3.7 KEY RRs in the Construction of Responses 706 An explicit request for KEY RRs does not cause any special additional 707 information processing except, of course, for the corresponding SIG 708 RR from a security aware server. 710 Security aware DNS servers will include KEY RRs as additional 711 information in responses where appropriate including the following: 713 (1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone 714 served by these name servers MUST be included as additional 715 information. There will always be at least one such KEY RR in a 716 secure zone, even if it has the no-key type value to indicate that 717 the subzone is insecure. If not all additional information will fit, 718 the KEY RR(s) have higher priority than type A or AAAA glue RRs. If 719 such a KEY RR does not fit on a retrieval, the retrieval must be 720 considered truncated. 722 (2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) will 723 be included. On inclusion of A or AAAA RRs as additional 724 information, their KEY RRs will also be included but with lower 725 priority than the relevant A or AAAA RRs. 727 3.8 File Representation of KEY RRs 729 KEY RRs may appear as lines in a zone data master file. 731 The flag field, protocol, and algorithm number octets are then 732 represented as unsigned integers. Note that if the type field has 733 the "no key" value or the algorithm specified is 253, nothing appears 734 after the algorithm octet. 736 The remaining public key portion is represented in base 64 (see 737 Appendix) and may be divided up into any number of white space 738 separated substrings, down to single base 64 digits, which are 739 concatenated to obtain the full signature. These substrings can span 740 lines using the standard parenthesis. 742 Note that the public key may have internal sub-fields but these do 743 not appear in the master file representation. For example, with 744 algorithm 1 there is a public size, then a public exponent, and then 745 a modulus. With algorithm 254, there will be an OID followed by 746 algorithm dependent information. But in both cases only a single 747 logical base 64 string will appear in the master file. 749 4. The SIG Resource Record 751 The SIG or "signature" resource record (RR) is the fundamental way 752 that data is authenticated in the secure Domain Name System (DNS). As 753 such it is the heart of the security provided. 755 The SIG RR unforgably authenticates other RRs of a particular type, 756 class, and name and binds them to a time interval and the signer's 757 domain name. This is done using cryptographic techniques and the 758 signer's private key. The signer is frequently the owner of the zone 759 from which the RR originated. 761 4.1 SIG RDATA Format 763 The RDATA portion of a SIG RR is as shown below. The integrity of 764 the RDATA information is protected by the signature field. 766 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 767 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 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | type covered | algorithm | labels | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | original TTL | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | signature expiration | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | time signed | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | key footprint | / 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name / 779 / / 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | / 782 +- signature / 783 / / 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 The value of the SIG RR type is 24. 788 The "type covered" is the type of the other RRs covered by this SIG. 790 The algorithm number is an octet specifying the digital signature 791 algorithm used parallel to the algorithm octet for the KEY RR. The 792 MD5/RSA algorithm described in this draft is number 1. Numbers 2 793 through 252 are available for assignment should sufficient reason 794 arise to allocate them. However, the designation of a new algorithm 795 could have a major impact on the interoperability of the global DNS 796 system and requires an IETF standards action. Number 254 is reserved 797 for private use and will not be assigned a specific algorithm. For 798 number 254, the "signature" area shown above will actually begin with 799 an Object Identifier (OID) indicating the private algorithm in use 800 and the remainder of the signature area is whatever is required by 801 that algorithm. Number 253, known as the "expiration date 802 algorithm", is used when the expiration date or other non-signature 803 fields of the SIG are desired without any actual security. It is 804 anticipated that this algorithm will only be used in connection with 805 some modes of DNS dynamic update. For number 253, the signature 806 field will be null. Values 0 and 255 are reserved. 808 The "labels" octet is an unsigned count of how many labels there are 809 in the original SIG RR owner name not counting the null label for 810 root and not counting any initial "*" for a wildcard. If a secured 811 retrieval is the result of wild card substitution, it is necessary 812 for the resolver to use the original form of the name in verifying 813 the digital signature. This field helps optimize the determination 814 of the original form thus reducing the effort in authenticating 815 signed data. 817 If, on retrieval, the RR appears to have a longer name than indicated 818 by "labels", the resolver can tell it is the result of wildcard 819 substitution. If the RR owner name appears to be shorter than the 820 labels count, the SIG RR should be considered corrupt and ignored. 821 The maximum number of labels possible in the current DNS is 127 but 822 the entire octet is reserved and would be required should DNS names 823 ever be expanded to 255 labels. The following table gives some 824 examples. The value of "labels" is at the top, the retrieved owner 825 name on the left, and the table entry is the name to use in signature 826 verification except that "bad" means the RR is corrupt. 828 labels= | 0 | 1 | 2 | 3 | 4 | 829 --------+-----+------+--------+----------+----------+ 830 .| . | bad | bad | bad | bad | 831 d.| *. | d. | bad | bad | bad | 832 c.d.| *. | *.d. | c.d. | bad | bad | 833 b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad | 834 a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. | 836 The "original TTL" field is included in the RDATA portion to avoid 837 (1) authentication problems that caching servers would otherwise 838 cause by decrementing the real TTL field and (2) security problems 839 that unscrupulous servers could otherwise cause by manipulating the 840 real TTL field. This original TTL is protected by the signature 841 while the current TTL field is not. 843 NOTE: The "original TTL" must be restored into the covered RRs when 844 the signature is verified. This implies that all RRs for a 845 particular type, name, and class need to have the same TTL to start 846 with. 848 The SIG is valid until the "signature expiration" time which is an 849 unsigned number of seconds since the start of 1 January 1970, GMT, 850 ignoring leap seconds. (See also Section 4.4.) SIG RRs should not 851 have a date signed significantly in the future. To prevent 852 misordering of network request to update a zone dynamically, 853 monotonically increasing "time signed" dates may be necessary. 855 The "time signed" field is an unsigned number of seconds since the 856 start of 1 January 1970, GMT, ignoring leap seconds. 858 A SIG RR with an expiration date before the time signed should be 859 considered corrupt and ignored. 861 The "key footprint" is a 16 bit quantity that is used to help 862 efficiently select between multiple keys which may be applicable and 863 as a quick check that a public key about to be used for the 864 computationally expensive effort to check the signature is possibly 865 valid. Its exact meaning is algorithm dependent. For the MD5/RSA 866 algorithm, it is the next to the bottom two octets of the public key 867 modulus needed to decode the signature field. That is to say, the 868 most significant 16 of the lest significant 24 bits of the modulus in 869 network order. 871 The "signer's name" field is the domain name of the signer generating 872 the SIG RR. This is the owner of the public KEY RR that can be used 873 to verify the signature. It is frequently the zone which contained 874 the RR(s) being authenticated. The signer's name may be compressed 875 with standard DNS name compression when being transmitted over the 876 network. 878 The structure of the "signature" field is described below. 880 4.1.1 Signature Data 882 Except for algorithm number 253 where it is null, the actual 883 signature portion of the SIG RR binds the other RDATA fields to all 884 of the "type covered" RRs with that owner name and class. These 885 covered RRs are thereby authenticated. To accomplish this, a data 886 sequence is constructed as follows: 888 data = RDATA | RR(s)... 890 where "|" is concatenation, RDATA is all the RDATA fields in the SIG 891 RR itself before the signature, and RR(s) are all the RR(s) of the 892 type covered with the same owner name and class as the SIG RR in 893 canonical form and order. How this data sequence is processed into 894 the signature is algorithm dependent. 896 For purposes of DNS security, the canonical form for an RR is the RR 897 with domain names (1) fully expanded (no name compression via 898 pointers), (2) all domain name letters set to lower case, and (3) the 899 original TTL substituted for the current TTL. 901 For purposes of DNS security, the canonical order for RRs is to sort 902 them in ascending order by name, as left justified unsigned octet 903 sequences in network (transmission) order where a missing octet sorts 904 before a zero octet. (See also ordering discussion in Section 5.1.) 905 Within any particular name they are similarly sorted by type and then 906 RDATA as a left justified unsigned octet sequence. EXCEPT that the 907 type SIG RR(s) covering any particular type appear immediately after 908 the other RRs of that type. (This special consideration for SIG 909 RR(s) in ordering really only applies to calculating the AXFR SIG RR 910 as explained in section 4.1.3 below.) Thus if at name a.b there are 911 two A RRs and one KEY RR, their order with SIGs for concatenating the 912 "data" to be signed would be as follows: 914 a.b. A .... 915 a.b. A .... 916 a.b. SIG A ... 917 a.b. KEY ... 918 a.b. SIG KEY ... 920 SIGs covering type ANY should not be included in a zone. 922 4.1.2 MD5/RSA Algorithm Signature Calculation 924 For the MD5/RSA algorithm, the signature is as follows 926 hash = MD5 ( data ) 928 signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) 930 where MD5 is the message digest algorithm documented in RFC 1321, "|" 931 is concatenation, "e" is the private key exponent of the signer, and 932 "n" is the public modulus of the signer's public key. 01, FF, and 00 933 are fixed octets of the corresponding hexadecimal value. "prefix" is 934 the ASN.1 BER MD5 algorithm designator prefix specified in PKCS1, 935 that is, 936 hex 3020300c06082a864886f70d020505000410 [NETSEC]. 937 This prefix is included to make it easier to use RSAREF or similar 938 packages. The FF octet is repeated the maximum number of times such 939 that the value of the quantity being exponentiated is one octet 940 shorter than the value of n. 942 (The above specifications are Public Key Cryptographic Standard #1 943 [PKCS1].) 944 The size of n, including most and least significant bits (which will 945 be 1) SHALL be not less than 512 bits and not more than 2552 bits. n 946 and e SHOULD be chosen such that the public exponent is small. 948 Leading zeros bytes are not permitted in the MD5/RSA algorithm 949 signature. 951 A public exponent of 3 minimizes the effort needed to decode a 952 signature. Use of 3 as the public exponent may be weak for 953 confidentiality uses since, if the same data can be collected 954 encrypted under three different keys with an exponent of 3 then, 955 using the Chinese Remainder Theorem, the original plain text can be 956 easily recovered. This weakness is not significant for DNS because 957 we seek only authentication, not confidentiality. 959 4.1.3 Zone Transfer (AXFR) SIG 961 The above SIG mechanisms assure the authentication of all zone signed 962 RRs of a particular name, class and type. However, to efficiently 963 secure complete zone transfers, a SIG RR owned by the zone name must 964 be created with a type covered of AXFR that covers all zone signed 965 RRs other than the SIG AXFR itself. It will be calculated by hashing 966 together all other zone signed RRs, including SIGs. The RRs are 967 ordered and concatenated for hashing as described in Section 4.1.1. 968 (See also ordering discussion in Section 5.1.) 970 The AXFR SIG must be calculated last of all zone key signed SIGs in 971 the zone. It really belongs to the zone as a whole, not to the zone 972 name. The AXFR SIG is only retrieved as part of a zone transfer. 973 After validation of the AXFR SIG, the zone MAY be considered valid 974 without verification of all the internal zone SIGs in the zone; 975 however, any SIGs signed by entity keys or the like must still be 976 validated. The AXFR SIG SHOULD be transmitted first in a zone 977 transfer so the receiver can tell immediately that they may be able 978 to avoid verifying other zone signed SIGs. 980 RRs which might be added by a dynamic zone update protocol or are 981 otherwise signed by an end entity or user key and not by the zone key 982 (see Section 3.2) are not included in the AXFR SIG. They may 983 originate in the network and might not, in general, be migrated to 984 the recommended off line zone signing procedure (see Section 7.2). 985 Thus, such RRs are not directly signed by the zone, are not included 986 in the AXFR SIG, and are protected against omission from zone 987 transfers only to the extent that the server and communication can be 988 trusted. 990 4.1.4 Transaction and Request SIGs 992 A response message from a security aware server may optionally 993 contain a special SIG as the last item in the additional information 994 section to authenticate the transaction. 996 This SIG has a "type covered" field of zero, which is not a valid RR 997 type. It is calculated by using a "data" (see Section 4.1.2) of the 998 entire preceding DNS reply message, including DNS header, 999 concatenated with the entire DNS query message that produced this 1000 response, including the query's DNS header. That is 1002 data = full response (less final transaction SIG) | full query 1004 Verification of the transaction SIG (which is signed by the server 1005 host key, not the zone key) by the requesting resolver shows that the 1006 query and response were not tampered with in transit, that the 1007 response corresponds to the intended query, and that the response 1008 comes from the queried server. 1010 A DNS request may be optionally signed by including one or more SIGs 1011 at the end of the query. Such SIGs are identified by having a "type 1012 covered" field of zero. They sign the preceding DNS request message 1013 including DNS header but not including any preceding request SIGs. 1014 Such request SIGs are included in the "data" used to form any 1015 optional response transaction SIG. 1017 WARNING: Request SIGs are unnecessary for currently defined queries 1018 and will cause almost all existing DNS servers to completely ignore a 1019 query. However, such SIGs may be need to authenticate future DNS 1020 secure dynamic update or other requests. 1022 4.2 SIG RRs in the Construction of Responses 1024 Security aware DNS servers MUST, for every authoritative RR the query 1025 will return, attempt to send the available SIG RRs which authenticate 1026 the requested RR. The following rules apply to the inclusion of SIG 1027 RRs in responses: 1029 1. when an RR is placed in a response, its SIG RR has a higher 1030 priority for inclusion than other RRs that may need to be 1031 included. If space does not permit its inclusion, the response 1032 MUST be considered truncated except as provided in 2 below. 1034 2. when a SIG RR is present in the zone for an additional information 1035 section RR, the response MUST NOT be considered truncated merely 1036 because space does not permit the inclusion of its SIG RR. 1038 3. SIGs to authenticate non-authoritative data (glue records and NS 1039 RRs for subzones) are unnecessary and MUST NOT be sent. (Note 1040 that KEYs for subzones are controlling in a superzone so the 1041 superzone's signature on the KEY MUST be included (unless the KEY 1042 was additional information).) 1044 4. If a SIG covers any RR that would be in the answer section of the 1045 response, its automatic inclusion MUST be the answer section. If 1046 it covers an RR that would appear in the authority section, its 1047 automatic inclusion MUST be in the authority section. If it 1048 covers an RR that would appear in the additional information 1049 section it MUST appear in the additional information section. 1050 This is a change in the existing standard which contemplates only 1051 NS and SOA RRs in the authority section. 1053 5. Optionally, DNS transactions may be authenticated by a SIG RR at 1054 the end of the response in the additional information section 1055 (Section 4.1.4). Such SIG RRs are signed by the DNS server 1056 originating the response. Although the signer field MUST be the 1057 name of the originating server host, the owner name, class, TTL, 1058 and original TTL, are meaningless. The class and TTL fields 1059 SHOULD be zero. To conserve space, the owner name SHOULD be root 1060 (a single zero octet). If transaction authentication is desired, 1061 that SIG RR must be considered higher priority for inclusion than 1062 any other RR in the response. 1064 4.3 Processing Responses and SIG RRs 1066 The following rules apply to the processing of SIG RRs included in a 1067 response: 1069 1. a security aware resolver that receives a response from what it 1070 believes to be a security aware server via a secure communication 1071 with the AD bit (see Section 6.1) set, MAY choose to accept the 1072 RRs as received without verifying the SIG RRs. 1074 2. in other cases, a security aware resolver SHOULD verify the SIG 1075 RRs for the RRs of interest. This may involve initiating 1076 additional queries for SIG or KEY RRs, especially in the case of 1077 getting a response from an insecure server. (As explained in 4.2 1078 above, it will not be possible to secure CNAMEs being served up by 1079 non-secure resolvers.) 1081 NOTE: Implementers might expect the above SHOULD to be a MUST. 1082 However, local policy or the calling application may not require 1083 the security services. 1085 3. If SIG RRs are received in response to a user query explicitly 1086 specifying the SIG type, no special processing is required. 1088 If the message does not pass reasonable checks or the SIG does not 1089 check against the signed RRs, the SIG RR is invalid and should be 1090 ignored. If all of the SIG RR(s) purporting to authenticate a set of 1091 RRs are invalid, then the set of RR(s) is not authenticated. 1093 If the SIG RR is the last RR in a response in the additional 1094 information section and has a type covered of zero, it is a 1095 transaction signature of the response and the query that produced the 1096 response. It MAY be optionally checked and the message rejected if 1097 the checks fail. But even if the checks succeed, such a transaction 1098 authentication SIG does NOT authenticate any RRs in the message. 1099 Only a proper SIG RR signed by the zone or a key tracing its 1100 authority to the zone can authenticate RRs. If a resolver does not 1101 implement transaction and/or request SIGs, it MUST ignore them 1102 without error. 1104 If all reasonable checks indicate that the SIG RR is valid then RRs 1105 verified by it should be considered authenticated. 1107 4.4 Signature Expiration, TTLs, and Validity 1109 Security aware servers must not consider SIG RRs to authenticate 1110 anything after their expiration time and not consider any RR to be 1111 authenticated after its signatures have expired. Within that 1112 constraint, servers should continue to follow DNS TTL aging. Thus 1113 authoritative servers should continue to follow the zone refresh and 1114 expire parameters and a non-authoritative server should count down 1115 the TTL and discard RRs when the TTL is zero. In addition, when RRs 1116 are transmitted in a query response, the TTL should be trimmed so 1117 that current time plus the TTL does not extend beyond the signature 1118 expiration time. Thus, in general, the TTL on an transmitted RR 1119 would be 1121 min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) 1123 4.5 File Representation of SIG RRs 1125 A SIG RR can be represented as a single logical line in a zone data 1126 file [RFC1033] but there are some special considerations as described 1127 below. (It does not make sense to include a transaction or request 1128 authenticating SIG RR in a file as they are a transient 1129 authentication that covers data including an ephemeral transaction 1130 number and so must be calculated in real time.) 1131 There is no particular problem with the signer, covered type, and 1132 times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY 1133 is the year, the first MM is the month number (01-12), DD is the day 1134 of the month (01-31), HH is the hour in 24 hours notation (00-23), 1135 the second MM is the minute (00-59), and SS is the second (00-59). 1137 The original TTL and algorithm fields appear as unsigned integers. 1139 If the original TTL, which applies to the type signed, is the same as 1140 the TTL of the SIG RR itself, it may be omitted. The date field 1141 which follows it is larger than the maximum possible TTL so there is 1142 no ambiguity. 1144 The "labels" field does not appear in the file representation as it 1145 can be calculated from the owner name. 1147 The key footprint appears as an unsigned decimal number. 1149 However, the signature itself can be very long. It is the last data 1150 field and is represented in base 64 (see Appendix) and may be divided 1151 up into any number of white space separated substrings, down to 1152 single base 64 digits, which are concatenated to obtain the full 1153 signature. These substrings can be split between lines using the 1154 standard parenthesis. 1156 5. Non-existent Names and Types 1158 The SIG RR mechanism described in Section 4 above provides strong 1159 authentication of RRs that exist in a zone. But is it not 1160 immediately clear how to authenticatably deny the existence of a name 1161 in a zone or a type for an existent name. 1163 The nonexistence of a name in a zone is indicated by the NXT ("next") 1164 RR for a name interval containing the nonexistent name. A NXT RR and 1165 its SIG are returned in the authority section, along with the error, 1166 if the server is security aware. The same is true for a non-existent 1167 type under an existing name. This is a change in the existing 1168 standard which contemplates only NS and SOA RRs in the authority 1169 section. NXT RRs will also be returned if an explicit query is made 1170 for the NXT type. 1172 The existence of a complete set of NXT records in a zone means that 1173 any query for any name and any type to a security aware server 1174 serving the zone will always result in an reply containing at least 1175 one signed RR. 1177 NXT RRs do not appear in zone master files since they can be derived 1178 from the rest of the zone. 1180 5.1 The NXT Resource Record 1182 The NXT resource record is used to securely indicate that RRs with an 1183 owner name in a certain name interval do not exist in a zone and to 1184 indicate what zone signed RR types are present for an existing name. 1186 The owner name of the NXT RR is an existing name in the zone. It's 1187 RDATA is a "next" name and a type bit map. The presence of the NXT RR 1188 means that generally no name between its owner name and the name in 1189 its RDATA area exists and that no other zone signed types exist under 1190 its owner name. This implies a canonical ordering of all domain 1191 names in a zone. 1193 The ordering is to sort labels as unsigned left justified octet 1194 strings where the absence of a octet sorts before a zero octet and 1195 upper case letters are treated as lower case letters. Names are then 1196 sorted by sorting on the highest level label and then, within those 1197 names with the same highest level label by the next lower label, etc. 1198 down to leaf node labels. Since we are talking about a zone, the 1199 zone name itself always exists and all other names are the zone name 1200 with some prefix of lower level labels. Thus the zone name itself 1201 always sorts first. 1203 There is a problem with the last NXT in a zone as it wants to have an 1204 owner name which is the last existing name in sort order, which is 1205 easy, but it is not obvious what name to put in its RDATA to indicate 1206 the entire remainder of the name space. This is handled by treating 1207 the name space as circular and putting the zone name in the RDATA of 1208 the last NXT in a zone. 1210 There are special considerations due to interaction with wildcards as 1211 explained below. 1213 The NXT RRs for a zone should be automatically calculated and added 1214 to the zone by the same recommended off-line process that signs the 1215 zone (see Section 7.2). The NXT RR's TTL should not exceed the zone 1216 minimum TTL. 1218 5.2 NXT RDATA Format 1220 The RDATA for an NXT RR consists simply of a domain name followed by 1221 a bit map. 1223 The type number for the NXT RR is 30. 1225 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1226 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 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | next domain name / 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | type bit map / 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 The NXT RR type bit map is one bit per RR type present for the owner 1234 name similar to the WKS socket bit map. The first bit represents RR 1235 type zero (an illegal type which should not be present.) A one bit 1236 indicates that at least one RR of that type is present for the owner 1237 name. A zero indicates that no such RR is present. All bits not 1238 specified because they are beyond the end of the bit map are assumed 1239 to be zero. Note that bit 30, for NXT, will always be on so the 1240 minimum bit map length is actually four octets. The NXT bit map 1241 should be printed as a list of RR type mnemonics or decimal numbers 1242 similar to the WKS RR. 1244 The domain name may be compressed with standard DNS name compression 1245 when being transmitted over the network. The size of the bit map can 1246 be inferred from the RDLENGTH and the length of the next domain name. 1248 5.3 Example 1250 Assume zone foo.tld has entries for 1252 big.foo.tld, 1253 medium.foo.tld. 1254 small.foo.tld. 1255 tiny.foo.tld. 1257 Then a query to a security aware server for huge.foo.tld would 1258 produce an error reply with the authority section data including 1259 something like the following: 1261 big.foo.tld. NXT medium.foo.tld. A MX SIG NXT 1262 big.foo.tld. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 1263 19960102030405 ;signature expiration 1264 19951211100908 ;time signed 1265 2143658709 ;key footprint 1266 foo.tld. ;signer 1267 MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU 1268 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) 1269 ) 1271 Note that this response implies that big.foo.tld is an existing name 1272 in the zone and thus has other RR types associated with it than NXT. 1273 However, only the NXT (and its SIG) RR appear in the response to this 1274 query for huge.foo.tld, which is a non-existent name. 1276 5.4 Interaction of NXT RRs and Wildcard RRs 1278 Since, in some sense, a wildcard RR causes all possible names in an 1279 interval to exist, there should not be an NXT RR that would cover any 1280 part of this interval. Thus if *.X.ZONE exists you would expect an 1281 NXT RR that ends at X.ZONE and one that starts with the last name 1282 covered by *.X.ZONE. However, this "last name covered" is something 1283 very ugly and long like \255\255\255....X.zone. So the NXT for the 1284 interval following is simply given the owner name *.X.ZONE. This "*" 1285 type name is not expanded when the NXT is returned as authority 1286 information in connection with a query for a non-existent name. 1288 If there could be any wildcard RRs in a zone and thus wildcard NXTs, 1289 care must be taken in interpreting the results of explicit NXT 1290 retrievals as the owner name may be a wildcard expansion. 1292 The existence of one or more wildcard RRs covering a name interval 1293 makes it possible for a malicious server to hide any more 1294 specifically named RRs in the internal. The server can just falsely 1295 return the wildcard match NXT instead of the more specifically named 1296 RRs. If there is a zone wide wildcard, there will be an NXT RR whose 1297 owner name is the wild card and whose RDATA is the zone name. In 1298 this case a server could conceal the existence of any more specific 1299 RRs in the zone. (It would be possible to design a more strict NXT 1300 feature which would eliminate this possibility. But it would be more 1301 complex and might be so constraining as to make any dynamic update 1302 feature very difficult.) 1304 What name should be put into the RDATA of an NXT RR with an owner 1305 name that is within a wild card scope? Since the "next" existing 1306 name will be one that matches the wild card, the wild card name 1307 should be used. Inclusion of such NXTs for names interior to a wild 1308 card scope is optional. 1310 5.5 Blocking NXT Pseudo-Zone Transfers 1312 In a secure zone, a resolver can query for the initial NXT associated 1313 with the zone name. Using the next domain name RDATA field from that 1314 RR, it can query for the next NXT RR. By repeating this, it can walk 1315 through all the NXTs in the zone. If there are no wildcards, it can 1316 use this technique to find all names in a zone. If it does type ANY 1317 queries, it can incrementally get all information in the zone and 1318 perhaps defeat attempts to administratively block zone transfers. 1320 If there are any wildcards, this NXT walking technique will not find 1321 any more specific RR names in the part of the name space the wildcard 1322 covers. By doing explicit retrievals for wildcard names, a resolver 1323 could determine what intervals are covered by wildcards but still 1324 could not, with these techniques, find any names inside such 1325 intervals except by trying every name. 1327 If it is desired to block NXT walking, the recommended method is to 1328 add a zone wide wildcard of the KEY type with the no-key type value 1329 and with no type (zone, entity, or user) bit on. This will cause 1330 there to be one zone covering NXT RR and leak no information about 1331 what real names exist in the zone. This protection from pseudo-zone 1332 transfers is bought at the expense of eliminating the data origin 1333 authentication of the non-existence of names that NXT RRs can 1334 provide. If an entire zone is covered by a wildcard, a malicious 1335 server can return an RR produced by matching the resulting wildcard 1336 NXT and can thus hide all the real data and delegations with more 1337 specific names in the zone. 1339 5.6 Special Considerations at Delegation Points 1341 A name (other than root) which is the head of a zone also appears as 1342 the leaf in a superzone. If both are secure, there will always be 1343 two different NXT RRs with the same name. They can be distinguished 1344 by their signers and next domain name fields. Security aware servers 1345 should return the correct NXT automatically when required to 1346 authenticate the non-existence of a name and both NXTs, if available, 1347 on explicit query for type NXT. 1349 Insecure servers will never automatically return an NXT and some 1350 implementations may only return the NXT from the subzone on explicit 1351 queries. 1353 6. The AD and CD Bits and How to Resolve Securely 1355 Retrieving or resolving authentic data from the Domain Name System 1356 (DNS) involves starting with one or more trusted public keys for one 1357 or more zones. With trusted keys, a resolver willing to perform 1358 cryptography can progress securely through the secure DNS zone 1359 structure to the zone of interest as described in Section 6.3. Such 1360 trusted public keys would normally be configured in a manner similar 1361 to that described in Section 6.2. However, as a practical matter, a 1362 security aware resolver would still gain some confidence in the 1363 results it returns even if it was not configured with any keys but 1364 trusted what it got from a local well known server as a starting 1365 point. 1367 Data stored at a security aware server needs to be internally 1368 categorized as Authenticated, Pending, or Insecure. There is also a 1369 fourth transient state of Bad which indicates that all SIG checks 1370 have explicitly failed on the data. Such Bad data is not retained at 1371 a security aware server. Authenticated means that the data has a 1372 valid SIG under a KEY traceable via a chain of zero or more SIG and 1373 KEY RRs to a KEY configured at the resolver via its boot file. 1374 Pending data has no authenticated SIGs and at least one additional 1375 SIG the resolver is still trying to authenticate. Insecure data is 1376 data which it is known can never be either Authenticated or found Bad 1377 because it is in or has been reached via a non-secured zone. Behavior 1378 in terms of control of and flagging based on such data labels is 1379 described in Section 6.1. 1381 The proper validation of signatures requires a reasonably secure 1382 shared opinion of the absolute time between resolvers and servers as 1383 described in Section 6.4. 1385 6.1 The AD and CD Header Bits 1387 Two unused bits are allocated out of the DNS query/response format 1388 header. The AD (authentic data) bit indicates in a response that the 1389 data included has been verified by the server providing it. The CD 1390 (checking disabled) bit indicates in a query that non-verified data 1391 is acceptable to the resolver sending the query. 1393 These bits are allocated from the must-be-zero Z field as follows: 1395 1 1 1 1 1 1 1396 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1397 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1398 | ID | 1399 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1400 |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | 1401 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1402 | QDCOUNT | 1403 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1404 | ANCOUNT | 1405 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1406 | NSCOUNT | 1407 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1408 | ARCOUNT | 1409 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1411 These bits are zero in old servers and resolvers. Thus the responses 1412 of old servers are not flagged as authenticated to security aware 1413 resolvers and queries from non-security aware resolvers do not assert 1414 the checking disabled bit and thus will be answered by security aware 1415 servers only with authenticated data. Of course security aware 1416 resolvers can not trust the AD bit unless they trust the server they 1417 are talking to and either have a secure path to it or use DNS 1418 transaction security. 1420 Any security aware resolver willing to do cryptography SHOULD assert 1421 the CD bit on all queries to reduce DNS latency time by allowing 1422 security aware servers to answer before they have resolved the 1423 validity of data. 1425 Security aware servers NEVER return Bad data. For non-security aware 1426 resolvers or security aware resolvers requesting service by having 1427 the CD bit clear, security aware servers return only Authenticated or 1428 Insecure data with the AD bit set in the response. Security aware 1429 resolvers will know that if data is Insecure versus Authentic by the 1430 absence of SIG RRs. Security aware servers may return Pending data 1431 to security aware resolvers requesting the service by clearing the AD 1432 bit in the response. The AD bit may only be set on a response if the 1433 RRs in the response are either Authenticated or Insecure. 1435 6.2 Boot File Format 1437 The format for a boot file directive to configure a starting zone key 1438 is as follows: 1440 pubkey name flags protocol algorithm key-data 1442 for a public key. "name" is the owner name (if the line is 1443 translated into a KEY RR). Flags indicates the type of key and is 1444 the same as the flag octet in the KEY RR. Protocol and algorithm 1445 also have the same meaning as they do in the KEY RR. The material 1446 after the algorithm is algorithm dependent and, for private 1447 algorithms (algorithm 254), starts with the algorithm's identifying 1448 OID. If the "no key" type value is set in flags or the algorithm is 1449 specified as 253, then the key-data after algorithm is null. It is 1450 treated as an octet stream and encoded in base 64 (see Appendix). 1452 A file of keys for cross certification or other purposes can be 1453 configured though the keyfile directive as follows: 1455 keyfile filename 1457 The file looks like a master file except that it can only contain KEY 1458 and SIG RRs with the SIGs signed under a key configured with the 1459 pubkey directive. 1461 While it might seem logical for everyone to start with the key for 1462 the root zone, this has problems. The logistics of updating every 1463 DNS resolver in the world when the root key changes would be 1464 excessive. It may be some time before there even is a root key. 1465 Furthermore, many organizations will explicitly wish their "interior" 1466 DNS implementations to completely trust only their own zone. These 1467 interior resolvers can then go through the organization's zone 1468 servers to access data outsize the organization's domain. 1470 6.3 Chaining Through Zones 1472 Starting with one or more trusted keys for a zone, it should be 1473 possible to retrieve signed keys for its subzones which have a key 1474 and, if the zone is not root, for its superzone. Every authoritative 1475 secure zone server MUST also include the KEY RR for a super-zone 1476 signed by the secure zone via a keyfile directive. This makes it 1477 possible to climb the tree of zones if one starts below root. A 1478 secure sub-zone is indicated by a KEY RR with non-null key 1479 information appearing with the NS RRs for the sub-zone. These make 1480 it possible to descend within the tree of zones. 1482 A resolver should keep track of the number of successive secure zones 1483 traversed from a starting point to any secure zone it can reach. In 1484 general, the lower such a distance number is, the greater the 1485 confidence in the data. Data configured via a boot file directive 1486 should be given a distance number of zero. Should a query encounter 1487 different data for the same query with different distance values, 1488 that with a larger value should be ignored. 1490 A security conscious resolver should completely refuse to step from a 1491 secure zone into a non-secure zone unless the non-secure zone is 1492 certified to be non-secure, or only experimentally secure, by the 1493 presence of an authenticated KEY RR for the non-secure zone with the 1494 no-key type value or the presence of a KEY RR with the experimental 1495 bit set. Otherwise the resolver is getting bogus or spoofed data. 1497 If legitimate non-secure zones are encountered in traversing the DNS 1498 tree, then no zone can be trusted as secure that can be reached only 1499 via information from such non-secure zones. Since the non-secure zone 1500 data could have been spoofed, the "secure" zone reach via it could be 1501 counterfeit. The "distance" to data in such zones or zones reached 1502 via such zones could be set to 512 or more as this exceeds the 1503 largest possible distance through secure zones in the DNS. 1504 Nevertheless, continuing to apply secure checks within "secure" zones 1505 reached via non-secure zones is a good practice and will, as a 1506 practical matter, provide some small increase in security. 1508 6.4 Secure Time 1510 Coordinated interpretation of the time fields in SIG RRs requires 1511 that reasonably consistent time be available to the hosts 1512 implementing the DNS security extensions. 1514 A variety of time synchronization protocols exist including the 1515 Network Time Protocol (NTP, RFC1305). If such protocols are used, 1516 they MUST be used securely so that time can not be spoofed. 1517 Otherwise, for example, a host could get its clock turned back and 1518 might then believe old SIG and KEY RRs which were valid but no longer 1519 are. 1521 7. Operational Considerations 1523 This section discusses a variety of considerations in secure 1524 operation of the Domain Name System (DNS) using these protocol 1525 extensions. 1527 7.1 Key Size Considerations 1529 There are a number of factors that effect public key size choice for 1530 use in the DNS security extension. Unfortunately, these factors 1531 usually do not all point in the same direction. Choice of zone key 1532 size should generally be made by the zone administrator depending on 1533 their local conditions. 1535 For most schemes, larger keys are more secure but slower. Given a 1536 small public exponent, verification (the most common operation) for 1537 the MD5/RSA algorithm will vary roughly with the square of the 1538 modulus length, signing will vary with the cube of the modulus 1539 length, and key generation (the least common operation) will vary 1540 with the fourth power of the modulus length. The current best 1541 algorithms for factoring a modulus and breaking RSA security vary 1542 roughly with the 1.6 power of the modulus itself. Thus going from a 1543 640 bit modulus to a 1280 bit modulus only increases the verification 1544 time by a factor of 4 but increases the work factor of breaking the 1545 key by over 2^900. An upper bound of 2552 bits has been established 1546 for the MD5/RSA DNS security algorithm for interoperability purposes. 1548 However, larger keys increase the size of the KEY and SIG RRs. This 1549 increases the chance of DNS UDP packet overflow and the possible 1550 necessity for using higher overhead TCP in responses. 1552 The recommended minimum RSA algorithm modulus size, 640 bits, is 1553 believed by the authors to be secure at this time but high level 1554 zones in the DNS tree may wish to set a higher minimum, perhaps 1000 1555 bits, for security reasons. (Since the United States National 1556 Security Agency generally permits export of encryption systems using 1557 an RSA modulus of up to 512 bits, use of that small a modulus, i.e. 1558 n, must be considered weak.) 1560 For a key used only to secure data and not to secure other keys, 640 1561 bits should be adequate. 1563 7.2 Key Storage 1565 It is recommended that zone private keys and the zone file master 1566 copy be kept and used in off-line non-network connected physically 1567 secure machines only. Periodically an application can be run to add 1568 authentication to a zone by adding SIG and NXT RRs and adding no-key 1569 type KEY RRs for subzones where a real KEY RR is not provided. Then 1570 the augmented file can be transferred, perhaps by sneaker-net, to the 1571 networked zone primary server machine. 1573 The idea is to have a one way information flow to the network to 1574 avoid the possibility of tampering from the network. Keeping the 1575 zone master file on-line on the network and simply cycling it through 1576 an off-line signer does not do this. The on-line version could still 1577 be tampered with if the host it resides on is compromised. For 1578 maximum security, the master copy of the zone file should be off net 1579 and should not be updated based on an unsecured network mediated 1580 communication. 1582 Note, however, that secure resolvers need to be configured with some 1583 trusted on-line public key information (or a secure path to such a 1584 resolver). 1586 Non-zone private keys, such as host or user keys, generally have to 1587 be kept on line to be used for real-time purposes such as DNS 1588 transaction security, IPSEC session set-up, or secure mail. 1590 7.3 Key Generation 1592 Careful key generation is a sometimes overlooked but absolutely 1593 essential element in any cryptographically secure system. The 1594 strongest algorithms used with the longest keys are still of no use 1595 if an adversary can guess enough to lower the size of the likely key 1596 space so that it can be exhaustively searched. Suggestions will be 1597 found in RFC 1750. 1599 It is strongly recommended that key generation also occur off-line, 1600 perhaps on the machine used to sign zones (see Section 7.2). 1602 7.4 Key Lifetimes 1604 No key should be used forever. The longer a key is in use, the 1605 greater the probability that it will have been compromised through 1606 carelessness, accident, espionage, or cryptanalysis. Furthermore, if 1607 key rollover is a rare event, there is an increased risk that, when 1608 the time does come up change the key, no one at the site will 1609 remember how to do it or other problems will have developed in the 1610 procedures. 1612 While key lifetime is a matter of local policy, these considerations 1613 suggest that no zone key should have a lifetime significantly over 1614 four years. A reasonable maximum lifetime for zone keys that are 1615 kept off-line and carefully guarded is 13 months with the intent that 1616 they be replaced every year. A reasonable maximum lifetime for end 1617 entity keys that are used for IP-security or the like and are kept on 1618 line is 36 days with the intent that they be replaced monthly or more 1619 often. In some cases, an entity key lifetime of somewhat over a day 1620 may be reasonable. 1622 7.5 Signature Lifetime 1624 Signature expiration times must be set far enough in the future that 1625 it is quite certain that new signatures can be generated before the 1626 old ones expire. However, setting expiration too far into the future 1627 could, if bad data or signatures were ever generated, mean a long 1628 time to flush such badness. 1630 It is recommended that signature lifetime be a small multiple of the 1631 TTL but not less than a reasonable re-signing interval. 1633 7.6 Root 1635 It should be noted that in DNS the root is a zone unto itself. Thus 1636 the root zone key should only be seen signing itself or signing RRs 1637 with names one level below root, such as .aq, .edu, or .arpa. 1638 Implementations MAY reject as bogus any purported root signature of 1639 records with a name more than one level below root. The root zone 1640 contains the root KEY RR signed by a SIG RR under the root key 1641 itself. 1643 8. Conformance 1645 Several levels of server and resolver conformance are defined. 1647 8.1 Server Conformance 1649 Two levels of server conformance are defined as follows: 1651 Minimal server compliance is the ability to store and retrieve 1652 (including zone transfer) SIG, KEY, and NXT RRs. Any secondary, 1653 caching, or other server for a secure zone must be at least minimally 1654 compliant and even then some things, such as secure CNAMEs, will not 1655 work. 1657 Full server compliance adds the following to basic compliance: 1658 (1) ability to read SIG, KEY, and NXT RRs in zone files and (2) 1659 ability, given a zone file and private key, to add appropriate SIG 1660 and NXT RRs, possibly via a separate application, (3) proper 1661 automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) 1662 suppression of CNAME following on retrieval of the security type RRs, 1663 (5) recognize the CD query header bit and set the AD query header 1664 bit, as appropriate, and (6) proper handling of the two NXT RRs at 1665 delegation points. Primary servers for secure zones MUST be fully 1666 compliant and for completely successful secure operation, all 1667 secondary, caching, and other servers handling the zone should be 1668 fully compliant as well. 1670 8.2 Resolver Conformance 1672 Two levels of resolver compliance are defined: 1674 A basic compliance resolver can handle SIG, KEY, and NXT RRs 1675 when they are explicitly requested. 1677 A fully compliant resolver (1) understands KEY, SIG, and NXT 1678 RRs, (2) maintains appropriate information in its local caches and 1679 database to indicate which RRs have been authenticated and to what 1680 extent they have been authenticated, (3) performs additional queries 1681 as necessary to attempt to obtain KEY, SIG, or NXT RRs from non- 1682 security aware servers, (4) normally sets the CD query header bit on 1683 its queries. 1685 9. Security Considerations 1687 This document describes technical details of extensions to the Domain 1688 Name System (DNS) protocol to provide data integrity and origin 1689 authentication, public key distribution, and optional transaction 1690 security. 1692 If should be noted that, at most, these extensions guarantee the 1693 validity of resource records, including KEY resource records, 1694 retrieved from the DNS. They do not magically solve other security 1695 problems. For example, using secure DNS you can have high confidence 1696 in the IP address you retrieve for a host name; however, this does 1697 not stop someone for substituting an unauthorized host at that 1698 address or capturing packets sent to that address and falsely 1699 responding with packets apparently from that address. Any reasonably 1700 complete security system will require the protection of many other 1701 facets of the Internet. 1703 References 1705 [NETSEC] - Network Security: PRIVATE Communications in a PUBLIC 1706 World, Charlie Kaufman, Radia Perlman, & Mike Speciner, Prentice Hall 1707 Series in Computer Networking and Distributed Communications 1995. 1709 [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 1710 3 June 1991, Version 1.4. 1712 [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 1714 [RFC1033] - Domain Administrators Operations Guide, M. Lottor, 1715 November 1987 1717 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 1718 November 1987 1720 [RFC1035] - Domain Names - Implementation and Specifications 1722 [RFC1305] - Network Time Protocol (v3), D. Mills, April 9 1992. 1724 [RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16 1725 1992. 1727 [RFC1530] - Principles of Operation for the TPC.INT Subdomain: 1728 General Principles and Policy, C. Malamud, M. Rose, October 6 1993. 1730 [RFC1750] - Randomness Requirements for Security, D. Eastlake, S. 1731 Crocker, J. Schiller, December 1994. 1733 [RFC1825] - Security Architecture for the Internet Protocol, R. 1734 Atkinson, August 9 1995. 1736 [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. 1738 Authors Addresses 1740 Donald E. Eastlake, 3rd 1741 CyberCash, Inc. 1742 318 Acton Street 1743 Carlisle, MA 01741 USA 1745 Telephone: +1 508-287-4877 1746 FAX: +1 508-371-7148 1747 EMail: dee@cybercash.com 1749 Charles W. Kaufman 1750 Iris Associates 1751 1 Technology Park Drive 1752 Westford, MA 01886 USA 1754 Telephone: +1 508-392-5276 1755 EMail: charlie_kaufman@iris.com 1757 Expiration and File Name 1759 This draft expires 8 July 1996. 1761 Its file name is draft-ietf-dnssec-secext-08.txt. 1763 Appendix: Base 64 Encoding 1765 The following encoding technique is taken from RFC 1521 by N. Borenstein 1766 and N. Freed. It is reproduced here in an edited form for convenience. 1768 A 65-character subset of US-ASCII is used, enabling 6 bits to be 1769 represented per printable character. (The extra 65th character, "=", 1770 is used to signify a special processing function.) 1772 The encoding process represents 24-bit groups of input bits as output 1773 strings of 4 encoded characters. Proceeding from left to right, a 1774 24-bit input group is formed by concatenating 3 8-bit input groups. 1775 These 24 bits are then treated as 4 concatenated 6-bit groups, each 1776 of which is translated into a single digit in the base 64 alphabet. 1778 Each 6-bit group is used as an index into an array of 64 printable 1779 characters. The character referenced by the index is placed in the 1780 output string. 1782 Table 1: The Base 64 Alphabet 1784 Value Encoding Value Encoding Value Encoding Value Encoding 1785 0 A 17 R 34 i 51 z 1786 1 B 18 S 35 j 52 0 1787 2 C 19 T 36 k 53 1 1788 3 D 20 U 37 l 54 2 1789 4 E 21 V 38 m 55 3 1790 5 F 22 W 39 n 56 4 1791 6 G 23 X 40 o 57 5 1792 7 H 24 Y 41 p 58 6 1793 8 I 25 Z 42 q 59 7 1794 9 J 26 a 43 r 60 8 1795 10 K 27 b 44 s 61 9 1796 11 L 28 c 45 t 62 + 1797 12 M 29 d 46 u 63 / 1798 13 N 30 e 47 v 1799 14 O 31 f 48 w (pad) = 1800 15 P 32 g 49 x 1801 16 Q 33 h 50 y 1803 Special processing is performed if fewer than 24 bits are available 1804 at the end of the data being encoded. A full encoding quantum is 1805 always completed at the end of a quantity. When fewer than 24 input 1806 bits are available in an input group, zero bits are added (on the 1807 right) to form an integral number of 6-bit groups. Padding at the 1808 end of the data is performed using the '=' character. Since all base 1809 64 input is an integral number of octets, only the following cases 1810 can arise: (1) the final quantum of encoding input is an integral 1811 multiple of 24 bits; here, the final unit of encoded output will be 1812 an integral multiple of 4 characters with no "=" padding, (2) the 1813 final quantum of encoding input is exactly 8 bits; here, the final 1814 unit of encoded output will be two characters followed by two "=" 1815 padding characters, or (3) the final quantum of encoding input is 1816 exactly 16 bits; here, the final unit of encoded output will be three 1817 characters followed by one "=" padding character.