idnits 2.17.1 draft-ietf-dnsext-delegation-signer-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == 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 a Security Considerations section. ** 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 152: '... DS record MUST only appear at secure...' RFC 2119 keyword, line 153: '...hild's keys that SHOULD sign the child...' RFC 2119 keyword, line 154: '...ecure delegation MUST NOT have a DS re...' RFC 2119 keyword, line 155: '... DS record SHOULD be considered a hin...' RFC 2119 keyword, line 156: '... Resolver MUST only trust KEY records...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2001) is 8320 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 section? 'RFC1035' on line 398 looks like a reference -- Missing reference section? 'RFC2535' on line 401 looks like a reference -- Missing reference section? 'RFC3090' on line 407 looks like a reference -- Missing reference section? 'RFC3008' on line 404 looks like a reference -- Missing reference section? 'Parent' on line 413 looks like a reference -- Missing reference section? 'OKbit' on line 410 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group Olafur Gudmundsson 3 INTERNET-DRAFT July 2001 4 6 Updates: RFC 1035, RFC 2535, RFC 3008. 8 Delegation Signer record in parent. 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Comments should be sent to the authors or the DNSEXT WG mailing list 31 namedroppers@ops.ietf.org 33 This draft expires on January 15, 2002. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All rights reserved. 39 Abstract 41 One of the biggest problems in DNS occur when records of the same type 42 can appear on both sides of an delegation. If the contents of these 43 sets differs clients can get confused. RFC2535 KEY records follows 44 the same model as for NS records, parent is responsible for the 45 records but the child is responsible for the contents. This document 46 proposes to store a different record in the parent that specifies 47 which one of the child's keys are authorized to sign the child's KEY 48 set. This change is not backwards compatible with RFC2535 but 49 simplifies DNSSEC operation. 51 1 - Introduction 53 Familiarity with the DNS system [RFC1035], DNS security extensions 54 [RFC2535] and DNSSEC terminology [RFC3090] is important. 56 When the same data can reside in two administratively different DNS 57 zones sources it is common that the data gets out of sync. NS record 58 in a zone indicates that there is a delegation at this name and the NS 59 record lists the authorative servers for the real zone. Based on 60 actual measurements 10-30% of all delegations in the Internet have 61 differing NS sets at parent and child. There are number of reasons for 62 this, including lack of communication between parent and child and 63 bogus name-servers being listed to meet registrar requirements. 65 DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its 66 KEY set signed by the parent to create a verifiable chain of KEYs. 67 There is some debate, where the signed KEY set should reside, 68 parent[Parent] or child[RFC2535]. If the KEY set resides at the child, 69 frequent communication is needed between the two parties, to transmit 70 key sets up to parent and then the signed set or signatures down to 71 child. If the KEY set resides at the parent[Parent] the communication 72 is reduced having only child send updated key sets to parent. 73 DNSSEC[RFC2535] requires that the parent store NULL key set for 74 unsecure children, this complicates resolution process as in many 75 cases as servers for both parent and child need to be queried for KEY 76 set the [Parent] proposal simplifies this. 78 Further complication of the DNSSEC KEY model is that KEY record is 79 used to store DNS zone keys and public keys for other protocols. This 80 can lead to large key sets at delegation points. There are number of 81 potential problems with this including: 82 1. KEY set may become quite large if many applications/protocols store 83 their keys at the zone apex. Example of protocols are IPSEC, HTTP, 84 SMTP, SSH etc. 85 2. Key set may require frequent updates. 86 3. Probability of compromised/lost keys increases and triggers 87 emergency key rollover. 88 4. Parent may refuse sign key sets with NON DNS zone keys. 89 5. Parent may not have QoS on key changes that meets child's 90 expectations. 92 Given these and other reasons there is good reason to explore 93 alternatives to using only KEY records to create chain of trust. 95 Some of these problems can be reduced or eliminated by operational 96 rules or protocol changes. To reduce the number of keys at apex, rule 97 to require applications to store their KEY records at the SRV name for 98 that application is one possibility. Another is to restrict KEY record 99 to DNS keys only and create a new type for all non DNS keys. Third 100 possible solution is to ban the storage of non DNS related keys at 101 zone apex. There are other possible solutions but they are outside the 102 scope of this document. 104 1.1 - Delegation Signer Record model 106 This document proposes an alternative to the KEY record chain of 107 trust, that uses a special record that can only reside at the parent. 108 This record will identify the key(s) that child will use to self sign 109 its own KEY set. 111 The chain of trust is now established by verifying the parent KEY set, 112 the DS set from the parent and then the KEY set at the child. This is 113 cryptographically equivalent to just using KEY records. 115 Communication between the parent and child is reduced as the parent 116 only needs to know of changes in DNS zone KEY(s) used to sign the apex 117 KEY set. If other KEY records are stored at the zone apex, the parent 118 does not need to be aware of them. 120 This approach has the advantage that it minimizes the communication 121 between the parent and child and the child is the authority for the 122 KEY set with full control over the contents. This enables each to 123 operate and maintain each zone independent of each other. Thus if 124 child wants to have frequent key rollover for its DNS keys parent does 125 not need to be aware of it as the child can use one key to only sign 126 its apex KEY set and other keys to sign the other record sets in the 127 zone. The child can just as well use the same key to sign all records 128 in its zone. 130 Another advantage is that this model fits well with slow rollout of 131 DNSSEC and islands of security model. In the islands of security model 132 someone that trusts "good.example." preconfigures a key from 133 "good.example." as a trusted keys and from then on trusts any data 134 that is signed by that key or has a chain of trust to that key. If 135 "example." starts advertising DS records "good.example." does not have 136 to change operations, by suspending self-signing. If DS records can 137 also be used to identify trusted keys instead of KEY records. 139 The main disadvantage of this approach is double the number of 140 signatures that need to be verified for the each delegation KEY set. 141 There is no impact on verifying other record sets. 143 1.2 - Reserved words 145 The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document 146 are to be interpreted as described in RFC2119. 148 2 - DS (Delegation KEY signer) record: 150 2.1 Protocol change 152 DS record MUST only appear at secure delegations in the parent zone. 153 The record lists the child's keys that SHOULD sign the child's key 154 set. Insecure delegation MUST NOT have a DS record, the presence of 155 DS record SHOULD be considered a hint that the child might be secure. 156 Resolver MUST only trust KEY records that match a DS record. 157 NOTE: It has been suggested that NULL DS record for insecure children 158 is better than no record. The advantage is to have authenticated 159 denial of child's security status, the drawback is for large 160 delegating zones there will be many NULL DS records. If parent uses 161 NXT records adding NXT record to the authority section in the cases 162 when no DS record exists at delegation will give the same result as 163 NULL DS record. 164 WG please comment on which approach is better. 166 Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section 167 2.7: Delegating zones MUST NOT store KEY records for delegations. The 168 only records that can appear at delegation in parent are NS, SIG, NXT 169 and DS. 171 Zone MUST self sign its apex KEY set, it SHOULD sign it with a key 172 that corresponds to a DS record in the parent. The KEY used to sign 173 the apex KEY RRset CAN sign other RRsets in the zone. 175 If child apex KEY RRset is not signed with one of the keys specified 176 in the DS record the child is locally secure[RFC3090] and SHOULD only 177 be considered secure the resolver has been instructed to trust the key 178 used, via preconfiguration. 180 Authorative server answering a query, that has the OK bit set[OKbit], 181 MUST include the DS set in the additional section if the answer is a 182 referral and there is space. Caching servers SHOULD return the DS 183 record in the additional section under the same condition. 185 2.1.1 - Comments on protocol change 187 Over the years there has been various discussions on that the 188 delegation model in DNS is broken as there is no real good way to 189 assert if delegation exists. In RFC2535 version of DNSSEC the 190 authentication of a delegation is the NS bit in the NXT bitmap at the 191 delegation point. Something more explicit is needed and the DS record 192 addresses this for secure delegations. 194 DS record is the first DNS record to be only stored at the upper side 195 of a delegation. NS records appear at both sides as do SIG and NXT. 196 All other records can only appear at the lower side. This will cause 197 some problems as servers authorative for parent may reject DS record 198 even if the server understands unknown types, or not hand them out 199 unless explicitly asked. Similarly a nameserver acting as a 200 authorative for child and as a caching recursive server may never 201 return the DS record. A caching server does not care from which side 202 DS record comes from and thus should not have to be changed if it 203 supports unknown types. Different TTL values on the childs NS set and 204 parents DS set may cause the DS set to expire before the NS set. In 205 this case an non-DS aware server would ask the child server for the DS 206 set and get NXDOMAIN answer. DS aware server will know to ask the 207 parent for the DS record. 209 Secure resolvers need to know about the DS record and how to interpret 210 it. In the worst case, introducing the DS record, doubles the 211 signatures that need to be checked to validate a KEY set. 212 Note: The working group must determine if the tradeoff between more 213 work in resolvers is justified by the operational simplification of 214 this model. The author think this is a small price to pay to have a 215 cleaner delegations structure. One argument put forward is that DNS 216 should be optimized for read when ever possible, and on the face of it 217 adding the DS record makes reading data from DNS more expensive. The 218 operational complexities and legal hurdles that KEY records in parents 219 or children make prevent DNSSEC to ever get deployed. 221 2.2 Wire format of DS record 223 The DS record consists of algorithm, size, key tag and SHA-1 digest of 224 the public key KEY record allowed to sign the child's delegation. 226 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | key tag | size | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | algorithm | SHA-1 digest | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | (20 bytes) | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 241 | | 242 +-+-+-+-+-+-+-+-+ 244 The key tag is calculated as specified in RFC2535, the size is the 245 size of the public key in bits as specified in the document specifying 246 the algorithm. Algorithm MUST be an algorithm number assigned in the 247 range 1..251. The SHA-1 digest is calculated over the canonical name 248 of the delegation followed by the RDATA of the KEY record. 249 The size of the DS RDATA is 25 bytes, regardless of the key size. 250 NOTE: if 160 bits is to large the SHA-1 digest can be shortened but 251 that weakens the overall security of the system. 253 2.2.1 Justifications for fields 255 The algorithm and size fields are here to allow resolvers to quickly 256 identify the candidate KEY records to examine. Key Tag is to allow 257 quick check if this is a good candidate. The key tag is redundant but 258 provides some greater assurance than SHA-1 digest on its own. SHA-1 is 259 a strong cryptographic checksum, it is hard for attacker to generate a 260 KEY record that has the same SHA-1 digest. Making sure that the KEY 261 record is a valid public key is much harder. Combining the name of the 262 key and the key data as input to the digest provides stronger 263 assurance of the binding. Combining the SHA-1 with the other fields 264 makes the task of the attacker is as hard breaking the public key. 265 Even if someone creates a database of all SHA-1 key hashes seen so 266 far, the addition of the name renders that database useless for 267 attacks against random zones. 269 2.3 Presentation format of DS record 271 The presentation format of DS record consists of 2 numbers, followed 272 by either the name of the signature algorithm or the algorithm number. 273 The digest is to be presented in hex. 275 2.4 Justifications for compact format 277 This format allows concise representation of the keys that child will 278 use, thus keeping down the size of the answer for the delegation, 279 reducing the probability of packet overflow. The SHA-1 hash is strong 280 enough to uniquely identify the key. This is similar to the PGP 281 footprint. 283 Each DS record has RDATA size of 25, regardless of the size of the 284 keys, keeping the answers from the parent smaller than if public key 285 was used. The smallest currently defined KEY record RDATA is 70 bytes. 287 Compact DS format is also better suited to list trusted keys for 288 islands of security in configuration files. 290 2.5 Transition issues for installed base 292 RFC2535 compliant resolver will assume that all DS secured delegations 293 are locally secure. This is a bad thing, thus it might be necessary 294 for a transition period to support both DS and SIG@Child. The cost is 295 one more signatures in the answer and that early adopters have to 296 cumbersome communications that DS is supposed to solve. 298 Resolvers will not get confused as they will select signatures with 299 the KEY they trust and ignore the other one. 301 3 Resolver Example 303 To create a chain of trust resolver goes from trusted KEY to DS to 304 KEY. 306 Assume the key for domain example. is trusted. In zone "example." we 307 have 308 example. KEY 309 secure.example. DS tag=12345 size=1024 alg=dsa 310 secure.example. NS ns1.secure.example. 311 NS ns1.secure.example. s 312 secure.example. NXT NS SIG NXT DS tail.example. 313 secure.example. SIG(NXT) 314 secure.example. SIG(DS) 315 In zone "secure.example." we have 316 secure.example. SOA 317 secure.example. NS ns1.secure.example. 318 NS ns1.secure.example. 319 secure.example. KEY 320 KEY 321 KEY 322 secure.example. SIG(KEY) 323 secure.example. SIG(SOA) 324 secure.example. SIG(NS) 326 In this example the trusted key for example signs the DS record for 327 "secure.example.", making that a trusted record. The DS record states 328 what key is supposed to sign the KEY record at secure.example. In 329 this example "secure.example." has three different KEY records and the 330 one corresponding to the KEY identified in the DS record signs the KEY 331 set, thus the key set is validated and trusted. Note that one of the 332 other keys in the keyset actually signs the zone data, and resolvers 333 will trust the signatures as the key appears in the KEY set. 335 This example has only one DS record for the child but there no reason 336 to outlaw multiple DS records. More than one DS record is needed 337 during signing key rollover. It is strongly recommended that the DS 338 set be kept small. 340 3.1 Resolver cost estimates for DS records 342 From a RFC2535 resolver point of view for each delegation followed to 343 chase down an answer one KEY record has to be verified and possibly 344 some other records based on policy, for example the contents of the NS 345 set. Once the resolver gets to the appropriate delegation validating 346 the answer may require verifying one or more signatures. For a simple 347 A record lookup requires at least N delegations to be verified and 1 348 RRset. For a DS enabled resolver the cost is 2N+1. For MX record the 349 cost where the target of the MX record is in the same zone as the MX 350 record the costs are N+2 and 2N+2. In the case of negative answer the 351 same holds ratios hold true. 352 Resolver may require an extra query to get the DS record but and this 353 may add to the overall cost of the query, but this is never worse than 354 chasing down NULL KEY records from the parent in RFC2535 DNSSEC. 355 DS adds processing overhead on resolvers, increases the size of 356 delegation answers. DS requires much less storage in large delegation 357 zones than SIG@Parent. 359 4 Acknowledgments 361 Number of people have over the last few years contributed number of 362 ideas that are captured in this document. The core idea of using one 363 key to that has only the role of signing a key set, comes from 364 discussions with Bill Manning and Perry Metzger on how to put in a 365 single root key in all resolver that lives for a long time. Brian 366 Wellington, Dan Massey, Edward Lewis, Havard Eidnes, Jakob Schlyter, 367 Mark Kosters, Miek Gieben, Roy Arens, Scott Rosen have provided 368 usefull comments. 370 4 - Security Considerations: 372 This document proposes a change to the validation chain of KEY records 373 in DNS. The change in is not believed to reduce security in the 374 overall system, in RFC2535 DNSSEC child must communicate keys to 375 parent and prudent parents will require some authentication on that 376 handshake. The modified protocol will require same authentication but 377 allows the child to exert more local control over its own KEY set. 379 In the representation of DS record, there is a possibility that an 380 attacker can generate an valid KEY that matches all the checks thus 381 starting to forge data from the child. This is considered impractical 382 as on average more than 2**80 keys must be generated before one is 383 found that will match. 385 DS record is a change to DNSSEC protocol and there is some installed 386 base of implementations, as well as text books on how to set up 387 secured delegations. Implementations that do not understand DS record 388 will not be able to follow the KEY to DS to KEY chain and consider all 389 zone secured that way insecure. 391 5 - IANA Considerations: 393 IANA needs to allocate RR type code for DS from the standard RR type 394 space. 396 References: 398 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 399 Specification'', STD 13, RFC 1035, November 1987. 401 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 402 2535, March 1999. 404 [RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing 405 Authority'', RFC 3008, November 2000. 407 [RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone 408 Status'', RFC 3090, March 2001. 410 [OKbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in 411 progress , April 2001. 413 [Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone 414 KEYs'', work in progress , May 2001. 417 Author Address 419 Olafur Gudmundsson 420 3826 Legation Street, NW 421 Washington, DC, 20015 422 USA 423 425 Appendix A: Changes from Prior versions 427 Changes from version 00 428 Changed name from DK to DS based on working group comments. 429 Dropped verbose format based on WG comments. 430 Added text about TTL issue/problem in caching servers. 431 Added text about islands of security and clarified the cost impact. 432 Major editing of arguments and some reordering of text for clarity. 433 Added section on transition issues. 435 Full Copyright Statement 437 Copyright (C) The Internet Society (2001). All Rights Reserved. 439 This document and translations of it may be copied and furnished to 440 others, and derivative works that comment on or otherwise explain it 441 or assist in its implementation may be prepared, copied, published and 442 distributed, in whole or in part, without restriction of any kind, 443 provided that the above copyright notice and this paragraph are 444 included on all such copies and derivative works. However, this 445 document itself may not be modified in any way, such as by removing 446 the copyright notice or references to the Internet Society or other 447 Internet organizations, except as needed for the purpose of developing 448 Internet standards in which case the procedures for copyrights defined 449 in the Internet Standards process must be followed, or as required to 450 translate it into languages other than English. 452 The limited permissions granted above are perpetual and will not be 453 revoked by the Internet Society or its successors or assigns. 455 This document and the information contained herein is provided on an 456 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 457 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 458 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 459 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 460 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."