idnits 2.17.1 draft-ietf-dnssec-secext-02.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-25) 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-02.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-secext-02.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-secext-02.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-02.txt,', but the file name used is 'draft-ietf-dnssec-secext-02' == 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 8 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 634: '... be 1) SHALL be not less than 512 bi...' RFC 2119 keyword, line 635: '... and e MUST be chosen such that the ...' RFC 2119 keyword, line 636: '... - 1 and SHOULD be chosen such that ...' RFC 2119 keyword, line 703: '...ty aware servers MUST, for every RR th...' RFC 2119 keyword, line 707: '...e zone containing the RR MUST be given...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 466 has weird spacing: '...s where appro...' == 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 (19 May 1995) is 10569 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1032' is defined on line 1223, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1228, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1231, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1233, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' ** Downref: Normative reference to an Unknown state RFC: RFC 1032 ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** Downref: Normative reference to an Informational RFC: RFC 1321 -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA FAQ' Summary: 14 errors (**), 1 flaw (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT DNS Protocol Security Extensions 2 20 November 1994 3 Expires 19 May 1995 5 Domain Name System Protocol Security Extensions 6 ------ ---- ------ -------- -------- ---------- 8 Donald E. Eastlake 3rd & Charles W. Kaufman 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-secext-02.txt, is intended to 13 be become a standards track 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, nic.nordu.net, ftp.isi.edu, or 31 munnari.oz.au. 33 Abstract 35 The Domain Name System (DNS) has become a critical operational part 36 of the Internet infrastructure yet it has no strong security 37 mechanisms to assure data integrity or authentication. Extensions to 38 the DNS are described in detail that provide these services to 39 security aware resolvers or applications through the use of 40 cryptographic digital signatures. These digital signatures are 41 included in secured zones as resource records. Security can still be 42 provided even through non-security aware DNS servers. 44 A explanatory overview of the proposed extensions appears in draft- 45 ietf-dnssec-over-*.txt. 47 The extensions also provide for the storage of authenticated keys in 48 the DNS for DNS use and to support a general public key distribution 49 service. The stored keys enable security aware resolvers to learn 50 the authenticating key of zones in addition to keys for which they 51 are initially configured. Keys associated with DNS names can be 52 retrieved to support other protocols. Provision is made for a 53 variety of key types and algorithms. 55 In addition, the security extensions provide for the optional 56 authentication of DNS protocol transactions. 58 Acknowledgements 60 The significant contributions of the following persons (in alphabetic 61 order) to this draft are gratefully acknowledged: Madelyn Badger, 62 James M. Galvin, Olafur Gudmundsson, Sandy Murphy, Masataka Ohta, 63 Jeffrey I. Schiller. 65 Table of Contents 67 Status of This Document....................................1 69 Abstract...................................................2 70 Acknowledgements...........................................2 72 Table of Contents..........................................3 74 1. Introduction............................................5 76 2. Brief Overview of the Extensions.......................6 77 2.1 Key Distribution.......................................6 78 2.2 Data Origin Authentication.............................6 79 2.2.1 Security Provided...................................6 80 2.2.2 The SIG Resource Record..............................7 81 2.2.3 The NXD Resource Record..............................7 82 2.2.4 Signers Other Than The Zone..........................8 83 2.2.5 Special Problems With Time-to-Live...................8 84 2.3 DNS Transaction Authentication.........................8 86 3. The KEY Resource Record................................10 87 3.1 KEY RDATA format......................................10 88 3.2 Object Types and DNS Names and Keys...................11 89 3.3 The KEY RR Flag Octet.................................11 90 3.4 The KEY Algorithm Version.............................12 91 3.5 KEY RRs in the Construction of Responses..............13 92 3.6 File Representation of KEY RRs........................13 94 4. The SIG Resource Record................................15 95 4.1 SIG RDATA Format......................................15 96 4.1.1 Signature Format....................................17 97 4.1.2 SIG RRs Covering Type ANY...........................18 98 4.1.3 Zone Transfer (AXFR) SIG............................18 99 4.1.4 Transaction SIGs....................................18 100 4.2 SIG RRs in the Construction of Responses..............19 101 4.3 Processing Responses with SIG RRs.....................19 102 4.4 File Representation of SIG RRs........................20 104 5. Non-existent Names.....................................22 105 5.1 The NXD Resource Record...............................22 106 5.2 NXD RDATA Format......................................23 107 5.3 Example...............................................23 108 5.4 Interaction of NXD RRs and Wildcard RRs...............23 109 5.5 Blocking NXD Pseudo-Zone Transfers....................24 111 6. How to Resolve Securely................................25 112 6.1 Boot File Format......................................25 113 6.2 Chaining Through Zones................................26 114 6.3 Secure Time...........................................27 115 7. Operational Considerations.............................28 116 7.1 Key Size Considerations...............................28 117 7.2 Key Storage...........................................28 118 7.3 Key Generation........................................29 119 7.4 Key Lifetimes.........................................29 120 7.5 Revocation............................................29 121 7.6 Root..................................................30 123 8. Conformance............................................31 124 8.1 Server Conformance....................................31 125 8.2 Resolver Conformance..................................31 127 9. Security Considerations................................32 128 References................................................32 130 Authors Addresses.........................................33 131 Expiration and File Name..................................33 133 1. Introduction 135 This draft provides detailed descriptions of the DNS protocol 136 extensions to support DNS security and public key distribution. 138 A broad overview of these extensions is provided in draft-ietf- 139 dnssec-over-*.txt. This draft assumes that the reader is familiar 140 with that overview and with the Domain Name System particularly as 141 described in RFCs 1034 and 1035. The requirements and goals of DNS 142 security are described in the overview document. 144 2. Brief Overview of the Extensions 146 The DNS protocol extensions provide three distinct services: key 147 distribution as described in section 2.1 below, data origin 148 authentication as described in section 2.2 below, and transaction 149 authentication, described in section 2.3 below. 151 2.1 Key Distribution 153 The resource records are defined to associate keys with DNS names. 154 This permits the DNS to be used as a general public key distribution 155 mechanism in support of the data origin authentication and 156 transaction authentication DNS services as well as other security 157 services such as IP level security. 159 The syntax of a KEY resource record is described in Section 3. It 160 includes the name of the entity the key is associated with 161 (frequently but not always the KEY RR owner name), an algorithm 162 identifier, flags indicating the type of entity the key is associated 163 with or asserting that there is no key associated with that entity, 164 and the actual public key parameters. 166 2.2 Data Origin Authentication 168 Adding security requires no change to the "on-the-wire" DNS protocol 169 beyond the addition of the signature resource types (and, as a 170 practical matter, the key resource type needed for key distribution). 171 An additional domain name non-existence resource is added to extend 172 authentication to negative responses. This service can be supported 173 by existing resolver and server implementations so long as they could 174 support the additional resource types. 176 If signatures are always separately retrieved and verified when 177 retrieving the information they authenticate, there will be more 178 trips to the server and performance will suffer. To avoid this, 179 security aware servers mitigate that degradation by automatically 180 send exactly the signature(s) needed. 182 2.2.1 Security Provided 184 Security is provided by associating with resource records in the DNS 185 a cryptographically generated digital signature. Commonly, there 186 will be a single private key that signs for an entire zone. If a 187 security aware resolver reliably learns the public key of the zone, 188 it can verify that all the data read was properly authorized and is 189 reasonably current. The expected implementation is for the zone 190 private key to be kept off-line and used to re-sign all of the 191 records in the zone periodically. 193 The data origin authentication key belongs to the zone and not to the 194 servers that store copies of the data. That means compromise of a 195 server or even all servers for a zone will not affect the degree of 196 assurance that a resolver has that the data is genuine. 198 A resolver can learn the public key of a zone either by reading it 199 from DNS or by having it staticly configured. To reliably learn the 200 public key by reading it from DNS, the key itself must be signed. 201 Thus, to provide a reasonable degree of security, the resolver must 202 be configured with at least the public key of one zone. From that, 203 it can securely read the public keys of other zones if the 204 intervening zones in the DNS tree are secure. It is in principle 205 more secure to have the resolver manually configured with the public 206 keys of multiple zones, since then the compromise of a single zone 207 would not permit the faking of information from other zones. It is 208 also more administratively cumbersome, however, particularly when 209 public keys change. 211 2.2.2 The SIG Resource Record 213 The syntax of a SIG resource record (signature) is described in 214 Section 4. It includes the type of the RR(s) being signed, the name 215 of the signer, the time at which the signature was created, the time 216 it expires (when it is no longer to be believed), its original time 217 to live (which may be longer than its current time to live but cannot 218 be shorter), the cryptographic algorithm in use, and the actual 219 signature. 221 Every name in a zone supporting signed data will have associated with 222 it a SIG resource records for each resource type under that name. A 223 security aware server supporting the performance enhanced version of 224 the DNS protocol security extensions will return with all records 225 retrieved the corresponding SIGs. If a server does not support the 226 protocol, the resolver must retrieve all the SIG records for a name 227 and select the one or ones that sign the resource record(s) that 228 resolver is interested in. 230 2.2.3 The NXD Resource Record 232 The above security mechanism provides only a way to sign existing RRs 233 in a zone. Data origin authentication is not obviously provided for 234 the non-existence of a domain name in a zone. This gap is filled by 235 the NXD RR which authenticatably asserts a range of non-existent 236 names in a zone. The owner of the NXD RR is the start of such a 237 ranger and its RDATA is the end of the range; however, there are 238 additional complexities due to wildcards. Section 6 below covers the 239 NXD RR. 241 2.2.4 Signers Other Than The Zone 243 There are two general cases where a signature is generated by other 244 than the zone private key. One is for future support of dynamic 245 update where an entity is permitted to authenticate/update its own 246 record. The public key of the entity must be present in the DNS and 247 be appropriately signed but the other RR(s) may be signed with the 248 entity's key. The other is for support of transaction authentication 249 as described in 2.3 below. 251 2.2.5 Special Problems With Time-to-Live 253 A digital signature will fail to verify if any change has occurred to 254 the data between the time it was originally signed and the time the 255 signature is verified. This conflicts with our desire to have the 256 time-to-live field tick down when resource records are cached. 258 This could be avoided by leaving the time-to-live out of the digital 259 signature, but that would allow unscrupulous secondaries to set 260 arbitrarily long time to live values undetected. Instead, we include 261 the "original" time-to-live in the signature and communicate that 262 data in addition to the current time-to-live. Unscrupulous servers 263 under this scheme can manipulate the time to live but a security 264 aware resolver will bound the TTL value it uses at the original 265 signed value. Separately, signatures include a time signed and an 266 expiration time. A resolver that knows an absolute time can 267 determine securely whether a signature has expired. 269 2.3 DNS Transaction Authentication 271 The data origin authentication service described above protects 272 resource records but provides no protection for message headers. If 273 header bits are falsely set by a server, there is little that can be 274 done. However, it is possible to add transaction authentication. 275 Such authentication means that a resolver can be sure it is getting 276 messages from the server it thinks it queried and that the response 277 is from the query it sent and that these messages have not been 278 diddled in transit. 280 This is accomplished by optionally adding a special SIG resource 281 record to end of the reply which digitally signs the concatenation of 282 the server's response and the resolver's query. The private key used 283 belongs to the host composing the reply, not to the zone being 284 queried. The corresponding public key is stored in and retrieved 285 from the DNS. Because replies are highly variable, message 286 authentication SIGs can not be precalculated. Thus it will be 287 necessary to keep the private key on-line, for example in software or 288 in a directly connected piece of hardware. 290 The best way to get the security provided by the transaction 291 authentication service would be to use a good IP level security 292 protocol. The authors of this draft decry the every growing number 293 of IP application level security protocols such as Telnet, NTP, FTP, 294 etc., etc. when a single IP-security protocol could secure most of 295 these applications. 297 Unfortunately, an IP-security standard has not yet been adopted. And 298 even if it had, there will be many systems for many years where it 299 will be hard to add IP security but relatively easy to replace the 300 DNS components. Furthermore, the data origin authentication service 301 requires the implementation of essentially all the mechanisms needed 302 for a rudimentary message authentication service. Thus a simple 303 transaction authentication service based on mechanisms already 304 required by DNS security is included as a strictly optional part of 305 these extensions. 307 3. The KEY Resource Record 309 The KEY RR is used to document a key that is associated with a DNS 310 name. It will be a public key as only public keys are stored in the 311 DNS. This can be the public key of a zone owner, of a host or other 312 end entity, or a user. A KEY RR is, like any other RR, authenticated 313 by a SIG RR. Security aware DNS implementations should be designed 314 to handle at least two simultaneously valid keys of the same type 315 associated with a name. 317 The type number for the KEY RR is 25. 319 3.1 KEY RDATA format 321 The RDATA for a KEY RR consists of an object name, flags, the 322 algorithm version, and the public key itself. For the MD5/RSA 323 algorithm, that is the public exponent and the public modulus. The 324 format is as follows: 326 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | / 330 +- object name +---------------+ 331 / | flags | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | algorithm | public key exponent | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | modulus length| | 336 +---------------+ public key modulus -+ 337 / / 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 The object name, and the flags octets are described in Sections 3.2 341 and 3.3 below. The flags must be examined before any following data 342 as they control its the format and even whether there is any 343 following data. 345 The public key exponent and modulus length fields show apply only if 346 the MD5/RSA algorithm is in use and a key is present. The public key 347 exponent is an unsigned 24 bit integer. The public key modulus field 348 is a multiprecision unsigned integer. The "modulus length" is an 349 unsigned octet which is the actual modulus length minus 64. This 350 limits keys to a maximum of 255+64 or 319 octets and a minimum of 64 351 octets. Although moduluses of less than 512 significant bits are not 352 recommended, due to the weak security they provide, they can be 353 represented by using leading zeros. 355 3.2 Object Types and DNS Names and Keys 357 The public key in a KEY RR belongs to the object named in the object 358 name field. Frequently this will also be the owner name of the KEY 359 RR. But they will be different in the case of the key or keys stored 360 under a zone's name for the zone's superzone or keys that are stored 361 for cross certification. 363 The DNS object name may refer to up to three things. For example, 364 dee.lkg.dec.com could be (1) a zone, (2) a host, and (3) the mapping 365 into a DNS name of the user dee@lkg.dec.com . Thus, there are flags 366 in the KEY RR to indicate with which of these roles the object name 367 and public key are associated as described below. It is possible to 368 use the same key for these different things with the same name but 369 this is discouraged. 371 In addition, there are three control bits, the "no key" bit, the 372 "experimental" bit, and the "signatory" bit, as described in 3.3 373 below. 375 It would be desirable for the growth of DNS to be managed so that 376 additional possible simultaneous uses for names are NOT added. New 377 uses should be distinguished by exclusive domains. For example, all 378 IP autonomous system numbers have been mapped into the in-as.arpa 379 domain [draft-ietf-dnssec-as-map-*.txt] and all telephone numbers in 380 the world have been mapped into the tpc.int domain [...]. This is 381 preferable to having the same name possibly be an autonomous system 382 number, telephone number, and/or host as well as a zone and a user. 384 3.3 The KEY RR Flag Octet 386 In the "flags" field: 388 Bit 0 is the "no key" bit. If this bit is on, there is no key 389 information and the RR stopw with the flags octet. 391 Bits 1 is the "experimental" bit. Keys may be associated with 392 zones or entities for experimental, trial, or optional use, in which 393 case this bit will be one. If this bit is a zero, it means that the 394 use or availability of security based on the key is "mandatory". 395 Thus, if this bit is off for a zone, the zone should be assumed 396 secured by SIG RRs and any responses indicating the zone is not 397 secured should be considered bogus. Similarly, if this bit were off 398 for a host key and attempts to negotiate IP-security with the host 399 produced indications that IP-security was not supported, it should be 400 assumed that the host has been compromised or communications with it 401 are being spoofed. On the other hand, if this bit were a one, the 402 host might very well sometimes operate in a secure mode and at other 403 times operate without the availability of IP-security. The 404 experimental bit, like all other aspects of the KEY RR, is only 405 effective if the KEY RR is appropriately signed by a SIG RR. 407 Bit 2 is the "signatory" bit. It indicates that the key can 408 validly sign RRs of the same name. If the owner name is a wildcard, 409 then RRs with any name which is in the wildcard's scope can be signed 410 including NS and corresponding KEY RRs to carve out a subzone. This 411 bit is meaningless for zone keys which always have authority to sign 412 any RRs in the zone. The signatory bit, like all other aspects of 413 the KEY RR, is only effective if the KEY RR is appropriately signed 414 by a SIG RR. 416 Bits 3-4 are reserved and must be zero. If they are found non- 417 zero, they should be ignored and the KEY RR used as indicated by the 418 other flags. 420 Bit 5 on indicates that this is a key associated with a "user" 421 or "account" at an end entity, usually a host. The coding of the 422 owner name is that used for the responsible individual mailbox in the 423 SOA record: The owner name is the user name as the name of a node 424 under the entity name. For example, "j.random_user" on 425 host.subdomain.domain could have a public key associated through an 426 KEY RR with name j\.random_user.host.subdomain.domain. It could be 427 used in an IP-security protocol where authentication of a user was 428 desired. This key would be useful in IP or other security for a user 429 level service such a telnet, ftp, rlogin, etc. 431 Bit 6 on indicates that this is a key associated with the non- 432 zone entity whose name is the RR owner name. This will commonly be a 433 host but could, in some parts of the DNS tree, be some other type of 434 entity such as an Autonomous System [draft-ietf-dnssec-as-map-*.txt]. 435 This is the public key used in connection with the optional DNS 436 transaction authentication service that can be used if the owner name 437 is a DNS server host. It could also be used in an IP-security 438 protocol where authentication of a host was desired. 440 Bit 7 on indicates that this is a zone key for the zone whose 441 name is the RSA RR owner name. This is the fundamental type of DNS 442 data origin authentication public key. 444 3.4 The KEY Algorithm Version 446 This octet is the key algorithm version parallel to the same field 447 for the SIG resource. The MD5/RSA algorithm described in this draft 448 is number 1. Version numbers 2 through 253 are available for 449 assignment should sufficient reason arise. However, the designation 450 of a new version could have a major impact on interoperability 451 requires an IETF standards action. Version 254 is reserved for 452 private use and will never be assigned a specific algorithm. For 453 version 254, the combined "public exponent", "modulus length" and 454 "modulus" area shown above will actually begin with an Object 455 Identifier (OID) indicating the private algorithm in use and the 456 remainder of the combined area is whatever is required by that 457 algorithm. Algorithm versions 0 and 255 are illegal. 459 3.5 KEY RRs in the Construction of Responses 461 A request for KEY RRs does not cause any special additional 462 information processing except, of course, for the corresponding SIG 463 RR from a security aware server. 465 Security aware DNS servers will include KEY RRs as additional 466 information in responses where appropriate as follows: 468 On the retrieval of NS RRs, the zone key KEY RR(s) for the zone 469 served by these name servers will be included. If not all additional 470 info will fit, the KEY RR(s) have lower priority than type A glue 471 RRs. 473 On retrieval of type A RRs, the end entity KEY RR(s) for the 474 host named will be included. On inclusion of A RRs as additional 475 information, their KEY RRs will also be included but with lower 476 priority than the relevant A RRs. 478 3.6 File Representation of KEY RRs 480 KEY RRs may appear as lines in a zone data file. 482 The object name appears first. 484 The flag octet and algorithm version octets are then represented as 485 unsigned integers; however, if the "no key" flag is on in the flags, 486 nothing appears after the flag octet. 488 If the algorithm specified is the MD5/RSA algorithm, then the 489 exponent and modulus appear. The public key exponent is an unsigned 490 integer from 3 to 16777215. The public key modulus can be quite 491 large, up to 319 octets. It is the last data field and is 492 represented in hex and may be divided up into any number of white 493 space separated substrings, down to single hex digits, which are 494 concatenated to obtain the full signature. These hex substrings can 495 span lines using the standard parenthesis. 497 If an algorithm from 2 through 253 is specified, the public key 498 parameters required by that algorithm are given. If the algorithm 499 specified is number 254, then an OID appears followed by whatever is 500 required for the private algorithm. Algorithm versions 0 and 255 are 501 illegal. 503 4. The SIG Resource Record 505 The SIG or "signature" resource record (RR) is the fundamental way 506 that data is authenticated in the secure DNS. As such it is the 507 heart of the security provided. 509 The SIG RR unforgably authenticates other RRs of a particular type 510 and binds them to a time interval and the signer's fully qualified 511 domain name. This is done using cryptographic techniques and the 512 signer's private key. The signer is usually the owner of the zone 513 from which the RR originated. 515 4.1 SIG RDATA Format 517 The RDATA portion of a SIG RR is as shown below. The integrity of 518 the RDATA information and that of the SIG RRs owner, type, and class 519 are protected by the signature field. 521 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | type covered | algorithm | labels | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | original TTL | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | signature expiration | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | time signed | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | key footprint | / 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name / 534 / / 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | signature / 537 / / 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 The value of the SIG type is 24. 542 The "type covered" is the type of the other RRs covered by this SIG. 544 The algorithm version number is an octet specifying the digital 545 signature algorithm used. The MD5/RSA algorithm described in this 546 draft is version one. Version numbers 2 through 253 are available 547 for assignment should sufficient reason arise to allocate them. 548 However, the designation of a new version could have a major impact 549 on the interoperability of the global DNS systems and requires an 550 IETF standards action. Version 254 is reserved for private use and 551 will never be assigned a specific algorithm. For version 254, the 552 "signature" area shown above will actually begin with an Object 553 Identified (OID) indicating the private algorithm in use and the 554 remainder of the signature area is whatever is required by that 555 algorithm. Version numbers 0 and 2555 are illegal. 557 The "labels" octet is an unsigned count of how many labels there are 558 in the original SIG RR owner name not counting the null label for 559 root and not counting any initial "*" for a wildcard. If, on 560 retrieval, the RR appears to have a longer name, the resolver can 561 tell it is the result of wildcard substitution. If the RR owner name 562 appears to be shorter than the labels count, the SIG RR should be 563 considered corrupt and ignored. The maximum number of labels 564 possible in the current DNS is 127 but the entire octet is reserved 565 and would be required should DNS names ever be expanded to 255 566 labels. If a secured retrieval is the result of wild card 567 substitution, it is necessary for the resolver to use the original 568 form of the name in verifying the digital signature. The field helps 569 optimize the determination of the original form. 571 The "original TTL" field is included in the RDATA portion to avoid 572 authentication problems that caching servers would otherwise cause by 573 decrementing the real TTL field and security problems that 574 unscrupulous servers could otherwise cause by manipulating the real 575 TTL field. This original TTL is protected by the signature while the 576 real TTL field is not. 578 The SIG is valid until the "signature expiration" time which is an 579 unsigned number of seconds since the start of 1 January 1970. 581 The "time signed" field is an unsigned number of seconds since the 582 start of 1 January 1970. 584 The "key footprint" is a 16 bit quantity that is used to help 585 efficiently select between multiple keys which may be applicable and 586 as a quick check that a public key about to be used for the 587 computationally expensive effort to decode the signature is possibly 588 valid. Its exact meaning is algorithm dependent. For the MD5/RSA 589 algorithm, it is the next to the bottom two octets of the public key 590 modulus needed to decode the signature field. That is to say, the 591 most significant 16 of the lest significant 24 bits of this quantity. 593 The "signer's name" field is the fully qualified domain name of the 594 signer generating the SIG RR. This is usually the zone which 595 contained the RR(s) being authenticated. 597 The structured of the "signature" field depends on the algorithm 598 chosen and is described below. 600 4.1.1 Signature Format 602 The actual signature portion of the SIG RR binds the owner, signer, 603 class, original TTL, time signed, flags, and expiration time of the 604 SIG RR to all of the "type covered" RRs with that owner name. These 605 covered RRs are thereby authenticated. To accomplish this, a data 606 sequence is constructed as follows: 608 data = algorithm | original TTL | Expiration Time | Time signed | 609 Signer's Name | RR(s)... 611 where | is concatenation and RR(s) are all the expanded (no name 612 abbreviation) RR(s) of the type covered with the same owner name as 613 the SIG RR in canonical order. The canonical order for RRs is to 614 sort them in ascending order as left justified unsigned octet 615 sequences where a missing octet sorts before a zero octet. 617 How this data sequence is processed into the signature is algorithm 618 dependent. 620 For the MD5/RSA algorithm, the signature is as follows 622 hash = MD5 ( data ) 624 signature = ( 01 | FF* | 00 | hash ) ** e (mod n) 626 where "|" is concatenation, "e" is the secret key exponent of the 627 signer, and "n" is the public modulus that is the signer's public 628 key. 01, FF, and 00 are fixed octets of the corresponding 629 hexadecimal value. The FF octet is repeated the maximum number of 630 times such that the value of the quantity being exponentiated is one 631 octet shorter than the value of n. 633 The size of n, including most and least significant bits (which will 634 be 1) SHALL be not less than 512 bits and not more than 2552 bits. n 635 and e MUST be chosen such that the public exponent is less than 2**24 636 - 1 and SHOULD be chosen such that the public exponent is small. 638 The above specifications are similar to Public Key Cryptographic 639 Standard #1 [PKCS1]. 641 (A public exponent of 3 minimizes the effort needed to decode a 642 signature. Use of 3 as the public exponent may be weak for 643 confidentiality uses since, if the same data can be collected 644 encrypted under three different keys with an exponent of 3 then, 645 using the Chinese Remainder Theorem [ref], the original plain text 646 can be easily recovered. This weakness is not significant for DNS 647 because we seek only authentication, not confidentiality.) 649 4.1.2 SIG RRs Covering Type ANY 651 The SIG RR described above protects all the RRs with a particular 652 owner name and type. Thus a server must supply them all to convince 653 a security aware resolver. However, an unscrupulous server could 654 claim there were no RRs of a particular type under an owner name 655 while presenting signed RRs of other types. To provide a means of 656 protection against this, one SIG RR is added for each owner name that 657 covers the type ANY. It is calculated as indicated above except that 658 all RRs for that owner name, except the SIG RR covering type ANY 659 itself, are included in the data string which is processed into the 660 signature. 662 4.1.3 Zone Transfer (AXFR) SIG 664 The above SIG mechanisms assure the authentication of all the RRs of 665 a particular name and type and all the RRs of a particular name and 666 any type. However, to secure complete zone transfers, a SIG RR owned 667 by the zone name must be created with a type covered of AXFR that 668 covers all other zone signed RRs. It will be calculated by hashing 669 together all other static zone RRs, including SIGs. The RRs are 670 ordered and concatenated for hashing as described in Section 4.1.1. 671 This SIG, other than having to be calculated last of all zone key 672 signed SIGs in the zone, is the same as any other SIG. 674 Dynamic zone RRs which might be added by some future dynamic zone 675 update protocol and signed by an end entity or user key rather than a 676 zone key (see Section 3.2) are not included. They originate in the 677 network and will not, in general, be migrated to the recommended off 678 line zone signing procedure (see Section 8.2). Thus such dynamic RRs 679 are not directly signed by the zone and are not generally protected 680 against omission during zone transfers. 682 4.1.4 Transaction SIGs 684 A response message from a security aware server may optionally 685 contain a special SIG as the last item in the additional information 686 section to authenticate the transaction. 688 This SIG has a "type covered" field of zero, which is not a valid RR 689 type. It is calculated by using a "data" (see section 4.1.1) of the 690 entire preceding DNS reply message, including header, concatenated 691 with the entire DNS query message that produced this response, 692 including the query's header. That is 694 data = full response (less trailing message SIG) | full query 696 Verification of the message SIG (which is signed by the server host 697 key, not the zone key) by the requesting resolver shows that the 698 query and response were not tampered with in transit and that the 699 response corresponds to the intended query. 701 4.2 SIG RRs in the Construction of Responses 703 Security aware servers MUST, for every RR the query will return, 704 attempt to send the available SIG RRs which authenticate the 705 requested RR. If multiple such SIGs are available, there may be 706 insufficient space in the response to include them all. In this 707 case, SIGs whose signer is the zone containing the RR MUST be given 708 highest priority and retained even if SIGs with other signers must be 709 dropped. 711 To minimize possible truncation problems, if a SIG covers any RR that 712 would be in the answer section of the response, its automatic 713 inclusion MUST be the answer section. If it covers an RR that would 714 appear in the authority section, its automatic inclusion MUST be in 715 the authority section. If it covers an RR that would appear in the 716 additional information section it MUST appear in the additional 717 information section. 719 Optionally, DNS transactions may be authenticated by a SIG RR at the 720 end of the response in the additional information section (section 721 4.1.4). Such SIG RRs are signed by the DNS server originating the 722 response. Although the signer field must be the name of the 723 originating server host, the name, class, TTL, and original TTL, are 724 meaningless. The class and TTL fields can be zero. To save space, 725 the name should be root (a single zero octet). 727 [There may be a problem with SIG and NXD RR's associated with domain 728 names that are CNAMEs. The DNS RFCs prohibit other types of RRs 729 appearing with a CNAME RR. This problem is being ignored until it is 730 clear if DNS servers will really have a problem with this.] 732 4.3 Processing Responses with SIG RRs 734 If SIG RRs are received in response to a query specifying the SIG 735 type, no special processing is required but a security aware client 736 may wish to authenticate them by decoding the signature and applying 737 consistency checks. 739 If SIG RRs are received in any other response, a security aware 740 client should decoded them using the public key of the signer. The 741 result of such decoding should thenbe verified against the 742 appropriate other RRs retrieved. 744 If the message does not pass reasonable checks or the SIG does not 745 check against the signed RRs, the SIG RR is invalid and should be 746 ignored. The time of receipt of the SIG RR must be in the inclusive 747 range of the time signed and the signature expiration but the SIG can 748 be retained and remains locally valid until the expiration time plus 749 the authenticated TTL. 751 If the SIG RR is the last RR in a response in the additional 752 information section and has a type covered of zero, it is a 753 transaction signature of the the response and the query that produced 754 the response. It may be optionally checked and the message rejected 755 if the checks fail. But even it the checks succeed, such a 756 transaction authentication SIG does NOT authenticate any RRs in the 757 message. Only proper direct or hashed RR signets signed by the zone 758 can authenticate RRs. If a resolver does not implement transaction 759 SIGs, it MUST at least ignore them without error. 761 If all reasonable checks indicate that the SIG RR is valid then RRs 762 verified by it should be considered authenticated and all other RRs 763 in the response should be considered with suspicion. 765 4.4 File Representation of SIG RRs 767 A SIG RR covering RRs can be represented as a single logical line in 768 a zone data file [RFC1033] but there are some special problems as 769 described below. (It does not make sense to include a transaction 770 authenticating SIG RR in a file as it is a transient authentication 771 that must be calculated in real time by the DNS server.) 773 There is no particular problem with the signer, covered type, and 774 times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY 775 is the year, the first MM is the month number (01-12), DD is the day 776 of the month (01-31), HH is the hour in 24 hours notation (00-23), 777 the second MM is the minute (00-59), and SS is the second (00-59). 779 The original TTL and algorithm fields appears as unsigned integers. 781 The "labels" field does not appear in the file representation as it 782 can be calculated from the owner name. 784 The key footprint appears as an eight digit unsigned hexadecimal 785 number. 787 However, the signature itself can be very long. It is the last data 788 field and is represented in hex and may be divided up into any number 789 of white space separated substrings, down to single hex digits, which 790 are concatenated to obtain the full signature. These hex substrings 791 can be split between lines using the standard parenthesis. 793 5. Non-existent Names 795 The SIG RR mechanism described in section 4 above provides strong 796 authentication of RRs that exist in a zone. But is it not 797 immediately clear how to authenticatably deny the existence of a name 798 in a zone. 800 The nonexistence of a name in a zone is indicates by the NXD RR for a 801 name interval containing the nonexistent name. An NXD RR and its SIG 802 are returned in the additional information section, along with the 803 error, if the resolver is security aware. NXD RRs can also be 804 returned if an explicit query is made for the NXD type. 806 The existence of a complete set of NXD records in a zone means that 807 any query for any name to a security aware server serving the zone 808 should result in an reply containing at least one signed RR. 810 5.1 The NXD Resource Record 812 The NXD resource record is used to securely indicate that no RRs with 813 an owner name in a certain name interval exist in a zone. 815 The owner name of the NXD RR is an existing name in the zone. It's 816 RDATA is another existing name in the zone. The presence of the NXD 817 RR means that no name between its owner name and the name in its 818 RDATA area exists. This implies a canonical ordering of all domain 819 names in a zone. 821 The ordering is to sort labels as unsigned left justified octet 822 strings where the absence of a byte sorts before a zero byte. Names 823 are then sorted by sorting on the highest level label and then, 824 within those names with the same highest level label by the next 825 lower label, etc. Since we are talking about a zone, the zone name 826 itself always exists and all other names are the zone name with some 827 prefix of lower level labels. Thus the zone name itself always sorts 828 first. 830 There is a slight problem with the last NXD in a zone as it wants to 831 have an owner name which is the last existing name in sort order, 832 which is easy, but it is not obvious what name to put in its RDATA to 833 indicate the entire remainder of the name space. This is handled by 834 treating the name space as circular and putting the zone name in the 835 RDATA of the last NXD. 837 There are additional complexities due to interaction with wildcards 838 as explained below. 840 The NXD RRs for a zone can be automatically calculated and added to 841 the zone by the same recommended off-line process that signs the 842 zone. The NXD RRs TTL should not exceed the zone minimum TTL. 844 The type number for the NXD RR is xxx. 846 5.2 NXD RDATA Format 848 The RDATA for an NXD RR consists simply of a domain name. 850 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | next domain name / 854 / / 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 5.3 Example 859 Assume a zone has entries for 861 big.foo.bar 862 medium.foo.bar 863 small.foo.bar 864 tiny.foo.bar 866 Then a query to a security aware server for huge.foo.bar would 867 produce an error reply with the additional information section 868 containing 870 big.foo.bar NXD medium.foo.bar 872 5.4 Interaction of NXD RRs and Wildcard RRs 874 As a wildcard RR causes all possible names in an interval to exist, 875 there should not be an NXD record that would cover any part of this 876 interval. Thus if *.X.ZONE exists you would expect an NXD RR that 877 ends at X.ZONE and one that starts with the last name covered by 878 *.X.ZONE. However, this "last name covered" is something very ugly 879 and long like \255\255\255....X.zone. So the NXD for the interval 880 following is simply given the owner name *.X.zone. This "*" type 881 name is not expanded when the NXD is returned as additional 882 information in connection with a query for a non-existent name. 884 If there could be any wildcard RRs in a zone and thus wildcard NXDs, 885 care must be taken in interpreting the results of explicit NXD 886 retrievals as the owner name may be a wildcard expansion. 888 The existence of one or more wildcard RRs covering a name interval 889 makes it possible for a malicious server to hide any more specificly 890 named RRs in the internal. The server can just falsely return the 891 wildcard match NXD instead of the more specificly named RRs. If 892 there is a zone wide wildcard, there will be only one NXD RR whose 893 owner name and RDATA are both the zone name. In this case a server 894 could conceal the existence of any more specific RRs in the zone. It 895 would be possible to make a more complex NXD feature, taking into 896 account the types of RRs that did not exist in a name interval, and 897 the like, which would eliminate this possibility. But it would be 898 more complex and would be so constraining as to make any future 899 dynamic update feature that could create new names very difficult 900 (see Section 3.2). 902 5.5 Blocking NXD Pseudo-Zone Transfers 904 In a secure zone, a resolver can query for the initial NXD associated 905 with the zone name. Using the RDATA field from that RR, it can query 906 for the next NXD RR. By repeating this, it can walk through all the 907 NXDs in the zone. If there are no wildcards, it can use this 908 technique to find all names in a zone. If it does type ANY queries, 909 it can incrementally get all information in the zone and perhaps 910 defeat attempts to administratively block zone transfers. 912 If there are any wildcards, this NXD walking technique will not find 913 any more specific RR names in the part of the name space the wildcard 914 covers. By doing explicit retrievals for wildcard names, a resolver 915 could determine what intervals are covered by wildcards but still 916 could not, with these techniques, find any names inside such 917 intervals except by trying every name. 919 If it is desired to block NXD walking, the recommended method is to 920 add a zone wide wildcard of the KEY type which asserts the 921 nonexistence of any keys. This will cause there to be only one NXD 922 RR in the zone for the zone name and leak no information about what 923 real names exist in the zone. This protection from pseudo-zone 924 transfers is bought at the expense of eliminating the data origin 925 authentication of the non-existence of names that NXD RRs can 926 provide. If an entire zone is covered by a wildcard, a malicious 927 server can return an RR produced by matching that wildcard and can 928 thus hide all the real data and delegations with more specific names 929 in the zone. 931 6. How to Resolve Securely 933 Retrieving or resolving authentic data from the DNS involves starting 934 with one or more trusted public keys and, in general, progressing 935 securely from them through the DNS zone structure to the zone of 936 interest. Such trusted public keys would normally be configured in a 937 manner similar to that described in section 6.1. However, as a 938 practical matter, a security aware resolver would still gain some 939 confidence in the results it returns even if it was not configured 940 with any keys but trusted what it got from a local well known server 941 as a starting point. 943 6.1 Boot File Format 945 The recommended format for a boot file line to configure starting 946 keys is as follows: 948 zonekey f.q.d.n algorithm [exponent modulus] 950 for a zone public key or 952 hostkey f.q.d.n algorithm [exponent modulus] 954 for a host public key. f.q.d.n is the domain name of the zone or 955 host. Algorithm is the algorithm in use where one is the MD5/RSA 956 algorithm and 254 indicates a private algorithm. The material after 957 the algorithm is algorithm dependent and, for private algorithms, 958 starts with the algorithm's identifying OID. For the RSA algorithm, 959 it is the public key exponent as a decimal number between 3 and 960 16777215, and the modulus in hex. 962 While it might seem logical for everyone to start with the key for 963 the root zone, this has problems. The logistics of updating every 964 DNS resolver in the world when the root key changes would be 965 excessive. It may be some time before there even is a root key. 966 Furthermore, many organizations will explicitly wish their "interior" 967 DNS implementations to completely trust only their own zone. These 968 interior resolvers can then go through the organization's zone server 969 to access data outsize the organization's domain. 971 If desired, the IP address for the f.q.d.n's with configured keys can 972 generally also be configured via an /etc/hosts or similar local file. 974 6.2 Chaining Through Zones 976 Starting with one trusted zone key, it is possible to retrieve signed 977 keys for subzones which have a key. Every secure zone (except root) 978 should also include the RSA record for its super-zone signed by the 979 secure zone. This makes it possible to climb the tree of zones if 980 one starts below root. A secure sub-zone is generally indicated by a 981 KEY RR appearing with the NS RRs for the sub-zone. These make it 982 possible to descend within the tree of zones. 984 A resolver should keep track of the number of successive secure zones 985 traversed from a starting point to any secure zone it can reach. In 986 general, the lower such a distance number is, the greater the 987 confidence in the data. Data configured via a boot file should be 988 given a distance number of zero. Should a query encounter different 989 data with different distance values, that with a larger value should 990 be ignored. 992 A security conscious resolver should completely refuse to step from a 993 secure zone into a non-secure zone unless the non-secure zone is 994 certified to be non-secure or only experimentally secure by the 995 presence of an authenticated KEY RR for the non-secure zone with a no 996 key flag or the presence of a KEY RR with the experimental bit set. 997 Otherwise the resolver is probably getting completely bogus or 998 spoofed data. 1000 If legitimate non-secure zones are encountered in traversing the DNS 1001 tree, then no zone can be trusted as secure that can be reached only 1002 via information from such non-secure zones. Since the non-secure zone 1003 data could have been spoofed, the "secure" zone reach via it could be 1004 counterfeit. The "distance" to data in such zones or zones reached 1005 via such zones could be set to 512 or more as this exceeds the 1006 largest possible distance through secure zones in the DNS. 1007 Nevertheless, continuing to apply secure checks within "secure" zones 1008 reached via non-secure zones will, as a practical matter, provide 1009 some increase in security. 1011 The existence of cross certifications adds further policy questions. 1012 Assume we have a zone B.A and a zone Y.X. Many possibilities exist 1013 for a secure resolver configured with the B.A key to get to Y.X. If 1014 all the zones along the way are secure, it could climb to root and 1015 then descend the other side, a total of four hops (B.A -> A -> . -> X 1016 -> Y.X). If the B.A administrator had installed a cross certified 1017 key for Y.X in the B.A zone, using that would be a shorter and 1018 presumably more secure way to find Y.X's key which would be immune to 1019 the non-security or even compromise of the servers for A or root or 1020 X. But what if some less trusted subzone of B.A, say C.B.A installed 1021 a cross certified key for Y.X? If there is a conflict, should this 1022 be preferred to a hierarhically derived key obtained by climbing to 1023 root and descending? Such questions are a matter of local resolver 1024 policy. 1026 6.3 Secure Time 1028 Coordinated interpretation of the time fields in SIG RRs requires 1029 that reasonably consistent time be available to the hosts 1030 implementing the DNS security extensions. 1032 A variety of time synchronization protocols exist including the 1033 Network Time Protocol (NTP, RFC1305). If such protocols are used, 1034 they should be used securely so that time can not be spoofed. 1035 Otherwise, for example, a host could get its clock turned back and 1036 might then believe old SIG and KEY RRs which were valid but no longer 1037 are. 1039 7. Operational Considerations 1041 This section discusses a variety of considerations in secure 1042 operation of DNS using these proposed protocol extensions. 1044 7.1 Key Size Considerations 1046 There are a number of factors that effect public key size choice for 1047 use in the DNS security extension. Unfortunately, these factors 1048 usually do not all point in the same direction. Choice of a key size 1049 should be made by the zone administrator depending on their local 1050 conditions. 1052 For most schemes, larger keys are more secure but slower. 1053 Verification (the most common operation) for the MD5/RSA algorithm 1054 will vary roughly with the square of the modulus length, signing will 1055 vary with the cube of the modulus length, and key generation (the 1056 least common operation) will vary with the fourth power of the 1057 modulus length. The current best algorithms for factoring a modulus 1058 and breaking RSA security vary roughly with the square of the modulus 1059 itself. Thus going from a 640 bit modulus to a 1280 bit modulus only 1060 increases the verification time by a factor of 4 but vastly increases 1061 the work factor of breaking the key. [RSA FAQ] 1063 However, larger keys increase size of the KEY RR and usually the SIG 1064 RR. This increases the change of UDP packet flow and the possible 1065 necessity for using higher overhead TCP. 1067 The recommended minimum RSA algorithm modulus size, 640 bits, is 1068 believed by the authors to be secure at this time and for some years 1069 but high level nodes in the DNS tree may wish to set a higher 1070 minimum, perhaps 1000 bits, for security reasons. (Since the United 1071 States National Security Agency generally permits export of 1072 encryption systems using an RSA modulus of up to 512 bits, use of 1073 that small a modulus, i.e. n, must be considered weak.) 1075 7.2 Key Storage 1077 It is strongly recommended that zone private keys and the zone file 1078 master copy be kept and used in off-line non-network connected 1079 physically secure machines only. Periodically an application can be 1080 run to re-sign the RRs in a zone by adding NXD and SIG RRs. Then the 1081 augmented file can be transferred, perhaps by sneaker-net, to the 1082 networked zone primary server machine. 1084 The idea is to have a one way information flow to the network to 1085 avoid the possibility of tampering from the network. Keeping the 1086 zone master file on-line on the network and simply cycling it through 1087 an off-line signer does not do this. The on-line version could still 1088 be tampered with if the host it resides on is compromised. The 1089 master copy of the zone file should be off net and should not be 1090 updated based on an unsecured network mediated communication. 1092 Non-zone private keys, such as host keys, may have to be kept on line 1093 to be used for real-time purposes such a IP secure session set-up. 1095 7.3 Key Generation 1097 Careful key generation is a sometimes over looked but absolutely 1098 essential element in any cryptographically secure system. The 1099 strongest algorithms used with the longest keys are still of no use 1100 if an adversary can guess enough to lower the size of the likely key 1101 space so that it can be exhaustively searched. Suggestions will be 1102 found in draft-ietf-security-randomness-*.txt. 1104 It is strongly recommended that key generation also occur off-line, 1105 perhaps on the machine used to sign zones (see Section 7.2). 1107 7.4 Key Lifetimes 1109 No key should be used forever. The longer a key is in use, the 1110 greater the probability that it will have been compromised through 1111 carelessness, accident, espionage, or cryptanalysis. 1113 No zone key should have a lifetime significantly over five years. 1114 The recommended maximum lifetime for zone keys that are kept off-line 1115 and carefully guarded is 13 months with the intent that they be 1116 replaced every year. The recommended maximum lifetime for end entity 1117 keys that are used for IP-security or the like and are kept on line 1118 is 36 days with the intent that they be replaced monthly or more 1119 often. In some cases, an entity key lifetime of a little over a day 1120 may be reasonable. 1122 7.5 Revocation 1124 [This is new and should probably be moved to someplace above...] 1125 Data in the DNS is authenticated via keyed digital signatures. Thus 1126 to revoke data, we need to alter the time period of the key's 1127 effectiveness to not include the date signed of the data to be 1128 remoked. Note that the case of a compromised key, where we wish to 1129 make its period of effectiveness null, we generally need only think 1130 of the KEY RR as data and make the period of effectiveness of the 1131 superzone's key not include the time of the previous superzone 1132 signing of the key. 1134 Normally, a KEY retrieved from the DNS appears to be effective from 1135 the beginning of time until the expiration of the SIG that 1136 authenticated it. (If this were not so, a secure zone would have to 1137 be resigned every time its superzone is resigned.) When data is 1138 being revoked, a zone can be resigned with a later date signed but a 1139 mechanism is need to make the earlier SIG of the now revoked data not 1140 longer valid. 1142 A dawn for the effectiveness of a node's KEY RR is provided, when 1143 desired, by having the key appear self-signed. This declares the 1144 time signed of the self signature as the time of effectiveness of the 1145 key(s). Note this is entirely under the control of a zone and 1146 asynchronous with its superzone's signings. 1148 This technique covers non-zone entities as well. For an owner to 1149 have a dawn to the effectiveness of its delegated key (which is 1150 signed by the zone key), it need only self-sign its key and the date 1151 signed is the dawn. 1153 7.6 Root 1155 The root zone includes its own key self-signed. 1157 It should also be noted that in DNS the root is a zone unto itself. 1158 Thus the root zone key should only be see signing itself or signing 1159 RRs with names one level below root, such as .aq, .edu, or .arpa. 1160 Implementations MAY reject as bogus any purported root signature of 1161 records with a name more than one level below root. 1163 8. Conformance 1165 Several levels of server and resolver conformance are defined. 1167 8.1 Server Conformance 1169 Three levels of server conformance are defined as follows: 1171 Zilch server compliance is the ability to store and retrieve 1172 (including zone transfer) SIG, KEY, and NXD RRs. It is believed that 1173 most current servers meet this level of compliance. 1175 Minimal server compliance adds the following to zilch 1176 compliance: (1) ability to read SIG, KEY, and NXD RRs in zone files 1177 and (2) ability, given a zone file and private key, to add 1178 appropriate SIG and NXD RRs, possibly via a separate application. 1179 Primary servers for secure zones must be at least minimally 1180 compliant. 1182 Full server compliance is ability to automatically include SIG, 1183 KEY, and NXD RRs in responses as appropriate, as well as meeting 1184 minimal compliance. 1186 8.2 Resolver Conformance 1188 Two levels of resolver compliance are defined: 1190 A Zilch compliance resolver can handle SIG, KEY, and NXD RRs 1191 when they are explicitly requested. It is believed that current 1192 resolvers are Zilch compliant. 1194 A fully compliant resolver understands KEY, SIG, and NXD RRs, 1195 maintains appropriate information in its local caches and database to 1196 indicate which RRs have been authenticated and to what extent they 1197 have been authenticated, and performs additional queries as necessary 1198 to obtain KEY, SIG, or NXD RRs from non-security aware servers. 1200 9. Security Considerations 1202 This document concerns technical details of extensions to the Domain 1203 Name System (DNS) protocol to provide data integrity and data origin 1204 authentication, public key distribution, and optional transaction 1205 security. 1207 If should be noted that, at most, these extensions guarantee the 1208 validity of resource records, including KEY resource records, 1209 retrieved from the DNS. They do not magically solve other security 1210 problems. For example, using secure DNS you can have high confidence 1211 in the IP address you retrieve for a host; however, this does not 1212 stop someone for substituting an unauthorized host at that address or 1213 capturing packets sent to that address and responding with packets 1214 apparently from that address. Any reasonably complete security 1215 system will require the protection of many other facets of the 1216 Internet. 1218 References 1220 [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 1221 3 June 1991, Version 1.4. 1223 [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 1225 [RFC1033] - Domain Administrators Operations Guide, M. Lottor, 1226 November 1987 1228 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 1229 November 1987 1231 [RFC1035] - Domain Names - Implementation and Specifications 1233 [RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16 1234 1992. 1236 [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. 1238 Authors Addresses 1240 Donald E. Eastlake 3rd 1241 Digital Equipment Corporation 1242 550 King Street, LKG2-1/BB3 1243 Littleton, MA 01460 1245 Telephone: +1 508 486 6577(w) +1 508 287 4877(h) 1246 EMail: dee@lkg.dec.com 1248 Charles W. Kaufman 1249 Iris Associates 1251 Telephone: +1 508-392-5276 1252 EMail: charlie_kaufman@iris.com 1254 Expiration and File Name 1256 This draft expires 19 May 1995. 1258 Its file name is draft-ietf-dnssec-secext-02.txt.