1 Network Working Group M. StJohns
2 Request for Comments: 5011 Independent
3 Category: Standards Track September 2007
4
5
6 Automated Updates of DNS Security (DNSSEC) Trust Anchors
7
8 Status of This Memo
9
10 This document specifies an Internet standards track protocol for the
11 Internet community, and requests discussion and suggestions for
12 improvements. Please refer to the current edition of the "Internet
13 Official Protocol Standards" (STD 1) for the standardization state
14 and status of this protocol. Distribution of this memo is unlimited.
15
16 Abstract
17
18 This document describes a means for automated, authenticated, and
19 authorized updating of DNSSEC "trust anchors". The method provides
20 protection against N-1 key compromises of N keys in the trust point
21 key set. Based on the trust established by the presence of a current
22 anchor, other anchors may be added at the same place in the
23 hierarchy, and, ultimately, supplant the existing anchor(s).
24
25 This mechanism will require changes to resolver management behavior
26 (but not resolver resolution behavior), and the addition of a single
27 flag bit to the DNSKEY record.
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 StJohns Standards Track [Page 1]
53 RFC 5011 Trust Anchor Update September 2007
54
55
56 Table of Contents
57
58 1. Introduction ....................................................2
59 1.1. Compliance Nomenclature ....................................3
60 2. Theory of Operation .............................................3
61 2.1. Revocation .................................................4
62 2.2. Add Hold-Down ..............................................4
63 2.3. Active Refresh .............................................5
64 2.4. Resolver Parameters ........................................6
65 2.4.1. Add Hold-Down Time ..................................6
66 2.4.2. Remove Hold-Down Time ...............................6
67 2.4.3. Minimum Trust Anchors per Trust Point ...............6
68 3. Changes to DNSKEY RDATA Wire Format .............................6
69 4. State Table .....................................................6
70 4.1. Events .....................................................7
71 4.2. States .....................................................7
72 5. Trust Point Deletion ............................................8
73 6. Scenarios - Informative .........................................9
74 6.1. Adding a Trust Anchor ......................................9
75 6.2. Deleting a Trust Anchor ....................................9
76 6.3. Key Roll-Over .............................................10
77 6.4. Active Key Compromised ....................................10
78 6.5. Stand-by Key Compromised ..................................10
79 6.6. Trust Point Deletion ......................................10
80 7. IANA Considerations ............................................11
81 8. Security Considerations ........................................11
82 8.1. Key Ownership vs. Acceptance Policy .......................11
83 8.2. Multiple Key Compromise ...................................12
84 8.3. Dynamic Updates ...........................................12
85 9. Normative References ...........................................12
86 10. Informative References ........................................12
87
88 1. Introduction
89
90 As part of the reality of fielding DNSSEC (Domain Name System
91 Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
92 come to the realization that there will not be one signed name space,
93 but rather islands of signed name spaces each originating from
94 specific points (i.e., 'trust points') in the DNS tree. Each of
95 those islands will be identified by the trust point name, and
96 validated by at least one associated public key. For the purpose of
97 this document, we'll call the association of that name and a
98 particular key a 'trust anchor'. A particular trust point can have
99 more than one key designated as a trust anchor.
100
101 For a DNSSEC-aware resolver to validate information in a DNSSEC
102 protected branch of the hierarchy, it must have knowledge of a trust
103 anchor applicable to that branch. It may also have more than one
104
105
106
107 StJohns Standards Track [Page 2]
108 RFC 5011 Trust Anchor Update September 2007
109
110
111 trust anchor for any given trust point. Under current rules, a chain
112 of trust for DNSSEC-protected data that chains its way back to ANY
113 known trust anchor is considered 'secure'.
114
115 Because of the probable balkanization of the DNSSEC tree due to
116 signing voids at key locations, a resolver may need to know literally
117 thousands of trust anchors to perform its duties (e.g., consider an
118 unsigned ".COM"). Requiring the owner of the resolver to manually
119 manage these many relationships is problematic. It's even more
120 problematic when considering the eventual requirement for key
121 replacement/update for a given trust anchor. The mechanism described
122 herein won't help with the initial configuration of the trust anchors
123 in the resolvers, but should make trust point key
124 replacement/rollover more viable.
125
126 As mentioned above, this document describes a mechanism whereby a
127 resolver can update the trust anchors for a given trust point, mainly
128 without human intervention at the resolver. There are some corner
129 cases discussed (e.g., multiple key compromise) that may require
130 manual intervention, but they should be few and far between. This
131 document DOES NOT discuss the general problem of the initial
132 configuration of trust anchors for the resolver.
133
134 1.1. Compliance Nomenclature
135
136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
138 document are to be interpreted as described in BCP 14, [RFC2119].
139
140 2. Theory of Operation
141
142 The general concept of this mechanism is that existing trust anchors
143 can be used to authenticate new trust anchors at the same point in
144 the DNS hierarchy. When a zone operator adds a new SEP key (i.e., a
145 DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section
146 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
147 validated by an existing trust anchor, then the resolver can add the
148 new key to its set of valid trust anchors for that trust point.
149
150 There are some issues with this approach that need to be mitigated.
151 For example, a compromise of one of the existing keys could allow an
152 attacker to add their own 'valid' data. This implies a need for a
153 method to revoke an existing key regardless of whether or not that
154 key is compromised. As another example, assuming a single key
155 compromise, we need to prevent an attacker from adding a new key and
156 revoking all the other old keys.
157
158
159
160
161
162 StJohns Standards Track [Page 3]
163 RFC 5011 Trust Anchor Update September 2007
164
165
166 2.1. Revocation
167
168 Assume two trust anchor keys A and B. Assume that B has been
169 compromised. Without a specific revocation bit, B could invalidate A
170 simply by sending out a signed trust point key set that didn't
171 contain A. To fix this, we add a mechanism that requires knowledge
172 of the private key of a DNSKEY to revoke that DNSKEY.
173
174 A key is considered revoked when the resolver sees the key in a
175 self-signed RRSet and the key has the REVOKE bit (see Section 7
176 below) set to '1'. Once the resolver sees the REVOKE bit, it MUST
177 NOT use this key as a trust anchor or for any other purpose except to
178 validate the RRSIG it signed over the DNSKEY RRSet specifically for
179 the purpose of validating the revocation. Unlike the 'Add' operation
180 below, revocation is immediate and permanent upon receipt of a valid
181 revocation at the resolver.
182
183 A self-signed RRSet is a DNSKEY RRSet that contains the specific
184 DNSKEY and for which there is a corresponding validated RRSIG record.
185 It's not a special DNSKEY RRSet, just a way of describing the
186 validation requirements for that RRSet.
187
188 N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint
189 than one without the bit set. This affects the matching of a DNSKEY
190 to DS records in the parent [RFC3755], or the fingerprint stored at a
191 resolver used to configure a trust point.
192
193 In the given example, the attacker could revoke B because it has
194 knowledge of B's private key, but could not revoke A.
195
196 2.2. Add Hold-Down
197
198 Assume two trust point keys A and B. Assume that B has been
199 compromised. An attacker could generate and add a new trust anchor
200 key C (by adding C to the DNSKEY RRSet and signing it with B), and
201 then invalidate the compromised key. This would result in both the
202 attacker and owner being able to sign data in the zone and have it
203 accepted as valid by resolvers.
204
205 To mitigate but not completely solve this problem, we add a hold-down
206 time to the addition of the trust anchor. When the resolver sees a
207 new SEP key in a validated trust point DNSKEY RRSet, the resolver
208 starts an acceptance timer, and remembers all the keys that validated
209 the RRSet. If the resolver ever sees the DNSKEY RRSet without the
210 new key but validly signed, it stops the acceptance process for that
211 key and resets the acceptance timer. If all of the keys that were
212
213
214
215
216
217 StJohns Standards Track [Page 4]
218 RFC 5011 Trust Anchor Update September 2007
219
220
221 originally used to validate this key are revoked prior to the timer
222 expiring, the resolver stops the acceptance process and resets the
223 timer.
224
225 Once the timer expires, the new key will be added as a trust anchor
226 the next time the validated RRSet with the new key is seen at the
227 resolver. The resolver MUST NOT treat the new key as a trust anchor
228 until the hold-down time expires AND it has retrieved and validated a
229 DNSKEY RRSet after the hold-down time that contains the new key.
230
231 N.B.: Once the resolver has accepted a key as a trust anchor, the key
232 MUST be considered a valid trust anchor by that resolver until
233 explicitly revoked as described above.
234
235 In the given example, the zone owner can recover from a compromise by
236 revoking B and adding a new key D and signing the DNSKEY RRSet with
237 both A and B.
238
239 The reason this does not completely solve the problem has to do with
240 the distributed nature of DNS. The resolver only knows what it sees.
241 A determined attacker who holds one compromised key could keep a
242 single resolver from realizing that the key had been compromised by
243 intercepting 'real' data from the originating zone and substituting
244 their own (e.g., using the example, signed only by B). This is no
245 worse than the current situation assuming a compromised key.
246
247 2.3. Active Refresh
248
249 A resolver that has been configured for an automatic update of keys
250 from a particular trust point MUST query that trust point (e.g., do a
251 lookup for the DNSKEY RRSet and related RRSIG records) no less often
252 than the lesser of 15 days, half the original TTL for the DNSKEY
253 RRSet, or half the RRSIG expiration interval and no more often than
254 once per hour. The expiration interval is the amount of time from
255 when the RRSIG was last retrieved until the expiration time in the
256 RRSIG. That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
257 1/2*RRSigExpirationInterval))
258
259 If the query fails, the resolver MUST repeat the query until
260 satisfied no more often than once an hour and no less often than the
261 lesser of 1 day, 10% of the original TTL, or 10% of the original
262 expiration interval. That is, retryTime = MAX (1 hour, MIN (1 day,
263 .1 * origTTL, .1 * expireInterval)).
264
265
266
267
268
269
270
271
272 StJohns Standards Track [Page 5]
273 RFC 5011 Trust Anchor Update September 2007
274
275
276 2.4. Resolver Parameters
277
278 2.4.1. Add Hold-Down Time
279
280 The add hold-down time is 30 days or the expiration time of the
281 original TTL of the first trust point DNSKEY RRSet that contained the
282 new key, whichever is greater. This ensures that at least two
283 validated DNSKEY RRSets that contain the new key MUST be seen by the
284 resolver prior to the key's acceptance.
285
286 2.4.2. Remove Hold-Down Time
287
288 The remove hold-down time is 30 days. This parameter is solely a key
289 management database bookeeping parameter. Failure to remove
290 information about the state of defunct keys from the database will
291 not adversely impact the security of this protocol, but may end up
292 with a database cluttered with obsolete key information.
293
294 2.4.3. Minimum Trust Anchors per Trust Point
295
296 A compliant resolver MUST be able to manage at least five SEP keys
297 per trust point.
298
299 3. Changes to DNSKEY RDATA Wire Format
300
301 Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag.
302 If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY)
303 signed by the associated key, then the resolver MUST consider this
304 key permanently invalid for all purposes except for validating the
305 revocation.
306
307 4. State Table
308
309 The most important thing to understand is the resolver's view of any
310 key at a trust point. The following state table describes this view
311 at various points in the key's lifetime. The table is a normative
312 part of this specification. The initial state of the key is 'Start'.
313 The resolver's view of the state of the key changes as various events
314 occur.
315
316 This is the state of a trust-point key as seen from the resolver.
317 The column on the left indicates the current state. The header at
318 the top shows the next state. The intersection of the two shows the
319 event that will cause the state to transition from the current state
320 to the next.
321
322
323
324
325
326
327 StJohns Standards Track [Page 6]
328 RFC 5011 Trust Anchor Update September 2007
329
330
331 NEXT STATE
332 --------------------------------------------------
333 FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
334 ----------------------------------------------------------
335 Start | |NewKey | | | | |
336 ----------------------------------------------------------
337 AddPend |KeyRem | |AddTime| | | |
338 ----------------------------------------------------------
339 Valid | | | |KeyRem |Revbit | |
340 ----------------------------------------------------------
341 Missing | | |KeyPres| |Revbit | |
342 ----------------------------------------------------------
343 Revoked | | | | | |RemTime|
344 ----------------------------------------------------------
345 Removed | | | | | | |
346 ----------------------------------------------------------
347
348 State Table
349
350 4.1. Events
351
352 NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
353 That key will become a new trust anchor for the named trust
354 point after it's been present in the RRSet for at least 'add
355 time'.
356
357 KeyPres The key has returned to the valid DNSKEY RRSet.
358
359 KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
360 this key.
361
362 AddTime The key has been in every valid DNSKEY RRSet seen for at
363 least the 'add time'.
364
365 RemTime A revoked key has been missing from the trust-point DNSKEY
366 RRSet for sufficient time to be removed from the trust set.
367
368 RevBit The key has appeared in the trust anchor DNSKEY RRSet with
369 its "REVOKED" bit set, and there is an RRSig over the DNSKEY
370 RRSet signed by this key.
371
372 4.2. States
373
374 Start The key doesn't yet exist as a trust anchor at the resolver.
375 It may or may not exist at the zone server, but either
376 hasn't yet been seen at the resolver or was seen but was
377 absent from the last DNSKEY RRSet (e.g., KeyRem event).
378
379
380
381
382 StJohns Standards Track [Page 7]
383 RFC 5011 Trust Anchor Update September 2007
384
385
386 AddPend The key has been seen at the resolver, has its 'SEP' bit
387 set, and has been included in a validated DNSKEY RRSet.
388 There is a hold-down time for the key before it can be used
389 as a trust anchor.
390
391 Valid The key has been seen at the resolver and has been included
392 in all validated DNSKEY RRSets from the time it was first
393 seen through the hold-down time. It is now valid for
394 verifying RRSets that arrive after the hold-down time.
395 Clarification: The DNSKEY RRSet does not need to be
396 continuously present at the resolver (e.g., its TTL might
397 expire). If the RRSet is seen and is validated (i.e.,
398 verifies against an existing trust anchor), this key MUST be
399 in the RRSet, otherwise a 'KeyRem' event is triggered.
400
401 Missing This is an abnormal state. The key remains a valid trust-
402 point key, but was not seen at the resolver in the last
403 validated DNSKEY RRSet. This is an abnormal state because
404 the zone operator should be using the REVOKE bit prior to
405 removal.
406
407 Revoked This is the state a key moves to once the resolver sees an
408 RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet
409 contains this key with its REVOKE bit set to '1'. Once in
410 this state, this key MUST permanently be considered invalid
411 as a trust anchor.
412
413 Removed After a fairly long hold-down time, information about this
414 key may be purged from the resolver. A key in the removed
415 state MUST NOT be considered a valid trust anchor. (Note:
416 this state is more or less equivalent to the "Start" state,
417 except that it's bad practice to re-introduce previously
418 used keys -- think of this as the holding state for all the
419 old keys for which the resolver no longer needs to track
420 state.)
421
422 5. Trust Point Deletion
423
424 A trust point that has all of its trust anchors revoked is considered
425 deleted and is treated as if the trust point was never configured.
426 If there are no superior configured trust points, data at and below
427 the deleted trust point are considered insecure by the resolver. If
428 there ARE superior configured trust points, data at and below the
429 deleted trust point are evaluated with respect to the superior trust
430 point(s).
431
432 Alternately, a trust point that is subordinate to another configured
433 trust point MAY be deleted by a resolver after 180 days, where such a
434
435
436
437 StJohns Standards Track [Page 8]
438 RFC 5011 Trust Anchor Update September 2007
439
440
441 subordinate trust point validly chains to a superior trust point.
442 The decision to delete the subordinate trust anchor is a local
443 configuration decision. Once the subordinate trust point is deleted,
444 validation of the subordinate zone is dependent on validating the
445 chain of trust to the superior trust point.
446
447 6. Scenarios - Informative
448
449 The suggested model for operation is to have one active key and one
450 stand-by key at each trust point. The active key will be used to
451 sign the DNSKEY RRSet. The stand-by key will not normally sign this
452 RRSet, but the resolver will accept it as a trust anchor if/when it
453 sees the signature on the trust point DNSKEY RRSet.
454
455 Since the stand-by key is not in active signing use, the associated
456 private key may (and should) be provided with additional protections
457 not normally available to a key that must be used frequently (e.g.,
458 locked in a safe, split among many parties, etc). Notionally, the
459 stand-by key should be less subject to compromise than an active key,
460 but that will be dependent on operational concerns not addressed
461 here.
462
463 6.1. Adding a Trust Anchor
464
465 Assume an existing trust anchor key 'A'.
466
467 1. Generate a new key pair.
468
469 2. Create a DNSKEY record from the key pair and set the SEP and Zone
470 Key bits.
471
472 3. Add the DNSKEY to the RRSet.
473
474 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
475 'A'.
476
477 5. Wait for various resolvers' timers to go off and for them to
478 retrieve the new DNSKEY RRSet and signatures.
479
480 6. The new trust anchor will be populated at the resolvers on the
481 schedule described by the state table and update algorithm -- see
482 Sections 2 and 4 above.
483
484 6.2. Deleting a Trust Anchor
485
486 Assume existing trust anchors 'A' and 'B' and that you want to revoke
487 and delete 'A'.
488
489
490
491
492 StJohns Standards Track [Page 9]
493 RFC 5011 Trust Anchor Update September 2007
494
495
496 1. Set the revocation bit on key 'A'.
497
498 2. Sign the DNSKEY RRSet with both 'A' and 'B'. 'A' is now revoked.
499 The operator should include the revoked 'A' in the RRSet for at
500 least the remove hold-down time, but then may remove it from the
501 DNSKEY RRSet.
502
503 6.3. Key Roll-Over
504
505 Assume existing keys A and B. 'A' is actively in use (i.e. has been
506 signing the DNSKEY RRSet). 'B' was the stand-by key. (i.e. has been
507 in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
508 used to sign the RRSet).
509
510 1. Generate a new key pair 'C'.
511 2. Add 'C' to the DNSKEY RRSet.
512 3. Set the revocation bit on key 'A'.
513 4. Sign the RRSet with 'A' and 'B'.
514
515 'A' is now revoked, 'B' is now the active key, and 'C' will be the
516 stand-by key once the hold-down expires. The operator should include
517 the revoked 'A' in the RRSet for at least the remove hold-down time,
518 but may then remove it from the DNSKEY RRSet.
519
520 6.4. Active Key Compromised
521
522 This is the same as the mechanism for Key Roll-Over (Section 6.3)
523 above, assuming 'A' is the active key.
524
525 6.5. Stand-by Key Compromised
526
527 Using the same assumptions and naming conventions as Key Roll-Over
528 (Section 6.3) above:
529
530 1. Generate a new key pair 'C'.
531 2. Add 'C' to the DNSKEY RRSet.
532 3. Set the revocation bit on key 'B'.
533 4. Sign the RRSet with 'A' and 'B'.
534
535 'B' is now revoked, 'A' remains the active key, and 'C' will be the
536 stand-by key once the hold-down expires. 'B' should continue to be
537 included in the RRSet for the remove hold-down time.
538
539 6.6. Trust Point Deletion
540
541 To delete a trust point that is subordinate to another configured
542 trust point (e.g., example.com to .com) requires some juggling of the
543 data. The specific process is:
544
545
546
547 StJohns Standards Track [Page 10]
548 RFC 5011 Trust Anchor Update September 2007
549
550
551 1. Generate a new DNSKEY and DS record and provide the DS record to
552 the parent along with DS records for the old keys.
553
554 2. Once the parent has published the DSs, add the new DNSKEY to the
555 RRSet and revoke ALL of the old keys at the same time, while
556 signing the DNSKEY RRSet with all of the old and new keys.
557
558 3. After 30 days, stop publishing the old, revoked keys and remove
559 any corresponding DS records in the parent.
560
561 Revoking the old trust-point keys at the same time as adding new keys
562 that chain to a superior trust prevents the resolver from adding the
563 new keys as trust anchors. Adding DS records for the old keys avoids
564 a race condition where either the subordinate zone becomes unsecure
565 (because the trust point was deleted) or becomes bogus (because it
566 didn't chain to the superior zone).
567
568 7. IANA Considerations
569
570 The IANA has assigned a bit in the DNSKEY flags field (see Section 7
571 of [RFC4034]) for the REVOKE bit (8).
572
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
There is an annotation for Section 8 that someone suggested I mention at the top of this document to ensure people see the important changes in the timing and security ramifications.
This RFC is implemented in BIND 9.18 (all versions).
573 8. Security Considerations
574
575 In addition to the following sections, see also Theory of Operation
576 above (Section 2) and especially Section 2.2 for related discussions.
577
578 Security considerations for trust anchor rollover not specific to
579 this protocol are discussed in [RFC4986].
580
581 8.1. Key Ownership vs. Acceptance Policy
582
583 The reader should note that, while the zone owner is responsible for
584 creating and distributing keys, it's wholly the decision of the
585 resolver owner as to whether to accept such keys for the
586 authentication of the zone information. This implies the decision to
587 update trust-anchor keys based on trusting a current trust-anchor key
588 is also the resolver owner's decision.
589
590 The resolver owner (and resolver implementers) MAY choose to permit
591 or prevent key status updates based on this mechanism for specific
592 trust points. If they choose to prevent the automated updates, they
593 will need to establish a mechanism for manual or other out-of-band
594 updates, which are outside the scope of this document.
595
596
597
598
599
600
601
602 StJohns Standards Track [Page 11]
603 RFC 5011 Trust Anchor Update September 2007
604
605
606 8.2. Multiple Key Compromise
607
608 This scheme permits recovery as long as at least one valid trust-
609 anchor key remains uncompromised, e.g., if there are three keys, you
610 can recover if two of them are compromised. The zone owner should
611 determine their own level of comfort with respect to the number of
612 active, valid trust anchors in a zone and should be prepared to
613 implement recovery procedures once they detect a compromise. A
614 manual or other out-of-band update of all resolvers will be required
615 if all trust-anchor keys at a trust point are compromised.
616
617 8.3. Dynamic Updates
618
619 Allowing a resolver to update its trust anchor set based on in-band
620 key information is potentially less secure than a manual process.
621 However, given the nature of the DNS, the number of resolvers that
622 would require update if a trust anchor key were compromised, and the
623 lack of a standard management framework for DNS, this approach is no
624 worse than the existing situation.
625
626 9. Normative References
627
628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
629 Requirement Levels", BCP 14, RFC 2119, March 1997.
630
631 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
632 Signer (DS)", RFC 3755, May 2004.
633
634 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
635 Rose, "DNS Security Introduction and Requirements", RFC
636 4033, March 2005.
637
638 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
639 Rose, "Resource Records for the DNS Security Extensions",
640 RFC 4034, March 2005.
641
642 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
643 Rose, "Protocol Modifications for the DNS Security
644 Extensions", RFC 4035, March 2005.
645
646 10. Informative References
647
648 [RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy,
649 "Requirements Related to DNS Security (DNSSEC) Trust
650 Anchor Rollover", RFC 4986, August 2007.
651
652
653
654
655
656
657 StJohns Standards Track [Page 12]
658 RFC 5011 Trust Anchor Update September 2007
659
660
661 Author's Address
662
663 Michael StJohns
664 Independent
665
666 EMail: mstjohns@comcast.net
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712 StJohns Standards Track [Page 13]
713 RFC 5011 Trust Anchor Update September 2007
714
715
716 Full Copyright Statement
717
718 Copyright (C) The IETF Trust (2007).
719
720 This document is subject to the rights, licenses and restrictions
721 contained in BCP 78, and except as set forth therein, the authors
722 retain all their rights.
723
724 This document and the information contained herein are provided on an
725 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
726 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
727 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
728 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
729 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
730 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
731
732 Intellectual Property
733
734 The IETF takes no position regarding the validity or scope of any
735 Intellectual Property Rights or other rights that might be claimed to
736 pertain to the implementation or use of the technology described in
737 this document or the extent to which any license under such rights
738 might or might not be available; nor does it represent that it has
739 made any independent effort to identify any such rights. Information
740 on the procedures with respect to rights in RFC documents can be
741 found in BCP 78 and BCP 79.
742
743 Copies of IPR disclosures made to the IETF Secretariat and any
744 assurances of licenses to be made available, or the result of an
745 attempt made to obtain a general license or permission for the use of
746 such proprietary rights by implementers or users of this
747 specification can be obtained from the IETF on-line IPR repository at
748 http://www.ietf.org/ipr.
749
750 The IETF invites any interested party to bring to its attention any
751 copyrights, patents or patent applications, or other proprietary
752 rights that may cover technology that may be required to implement
753 this standard. Please address the information to the IETF at
754 ietf-ipr@ietf.org.
755
756
757
758
759
760
761
762
763
764
765
766
767 StJohns Standards Track [Page 14]
768
After a careful timing analysis of the steps defined in RFC5011, issues were found that could lead to denial of service attacks. draft-rfc5011-security-considerations discusses the issues found and the suggested fixes to the timing considerations. Though acknowledged as true by the RFC5011 author, the security considerations draft was never published as an RFC (read the DNSOP email archives for further information).
Specifically, the new attack vector is described fully in the above document but is summarized in the following paragraph:
RFC5011 defines a mechanism by which DNSSEC validators can update their list of trust anchors when they've seen a new key published in a zone or revoke a properly marked key from a trust anchor list. However, RFC5011 [intentionally] provides no guidance to the publishers of DNSKEYs about how long they must wait before switching to exclusively using recently published keys for signing records, or how long they must wait before ceasing publication of a revoked key. Because of this lack of guidance, zone publishers may arrive at incorrect assumptions about safe usage of the RFC5011 DNSKEY advertising, rolling and revocation process. This document describes the minimum security requirements from a publisher's point of view and is intended to complement the guidance offered in RFC5011 (which is written to provide timing guidance solely to a Validating Resolver's point of view).