idnits 2.17.1 draft-hardaker-rfc5011-security-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 115 has weird spacing: '... foo bar...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 25, 2016) is 2826 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop W. Hardaker 3 Internet-Draft Parsons, Inc. 4 Intended status: Standards Track W. Kumari 5 Expires: January 26, 2017 Google 6 July 25, 2016 8 Security Considerations for RFC5011 Publishers 9 draft-hardaker-rfc5011-security-considerations-00 11 Abstract 13 This document describes the minimum requirements which a publisher of 14 a zone must wait before using a new DNSKEY advertised using the 15 RFC5011 DNSKEY rollover process. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 26, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 53 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Timing associated with RFC5011 processing . . . . . . . . . . 3 56 5. Denial of Service Attack Considerations . . . . . . . . . . . 3 57 5.1. Numerical Concrete Attack Example . . . . . . . . . . . . 3 58 5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 4 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 7. Operational 61 Considerations . . . . . . . . . . . . . . . . . . . . . . . 5 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 RFC5011 [RFC5011] defines a mechanism by which DNSSEC validators can 70 extend their list of trust anchors when they've seen a new key. 71 However, RFC5011 [intentionally] provides no guidance to publishers 72 of DNSKEYs about how long they must wait before such a new key is 73 actually usable. Because of this lack of guidance, DNSSEC publishers 74 may derive incorrect assumptions about safe usage of the RFC5011 75 process. This document describes the minimum security requirements 76 from a publishers point of view and is indented to compliment the 77 guidance offered in RFC5011 (which is designed to solely represent 78 the Validating Resolvers point of view). 80 The authors reached out to 5 DNSSEC experts and asked them how long 81 they must wait before using a new KSK that was being rolled according 82 to the 5011 process. All 5 experts answered with an insecure value, 83 and thus the authors have determined that this lack of operational 84 guidance is causing security concerns. This document will hopefully 85 help rectify this problem. 87 One important (temporary?) note about ICANN's upcoming KSK rolling 88 plan for the root zone: the timing values, at the time of this 89 writing, chosen for rolling the KSK in the root zone appear 90 completely safe, and are not in any way affected by the timing 91 concerns introduced by this draft 93 1.1. Requirements notation 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Background 101 The RFC5011 process describes a process by which a Validating 102 Resolver may accept a newly published KSK as a trust anchor for 103 validating future DNSSEC signed records. This document augments that 104 information with additional constraints, as required from the DNSKEY 105 publication point of view. Note that it does not define any other 106 operational guidance or recommendations about the RFC5011 process 107 from a publication point of view and restricts itself to solely the 108 security and operational ramifications of switching to a new key too 109 soon. Failure of a DNSKEY publisher to follow the minimum 110 recommendations associated with this draft will result in potential 111 denial-of-service attack opportunities against validating resolvers. 113 3. Terminology 115 foo bar 117 4. Timing associated with RFC5011 processing 119 TBD 121 5. Denial of Service Attack Considerations 123 If an attacker is able to provide a RFC5011 validating engine with 124 past responses, such as when it is in-path or able to otherwise 125 perform any number of cache poising attacks, she may be able to leave 126 the RFC5011-compliant validataor without an appropriate DNSKEY trust 127 anchor. 129 The following timeline illustrates this situation. 131 5.1. Numerical Concrete Attack Example 133 These assumptions are used in the example scenario within this 134 section. 136 TTL (all records) 1 day 138 RRSIG Signature Validity 10 days 140 Zone resigned every 1 day 141 Given these assumptions, the following sequence of events depicts how 142 a Trust Anchor Publisher (XXX: TERM!) which waits for only the 143 RFC5011 hold time timer length of 30 days subjects its users to a 144 potential Denial of Service attack. The timing schedule listed below 145 is based on a new Key Signing Key (KSK) being published at T+0, and 146 where all numbers in this sequence refer to days before and after 147 such an event. Thus, T-1 is the day before the introduction of the 148 new key, and T+15 is the 15th day after the key was introduced into 149 the zone being discussed.. 151 In this dialog, we consider two keys being published: 153 Kold The older KSK being replaced. 155 Knew The new KSK being transitioned into active use, using the 156 RFC5011 process. 158 In this dialog, the following actors are discussed: 160 Zone Maintainer The owner of a zone intending to publish a new Key- 161 Signing-Keys (KSKs) that will become a trust anchor by validators 162 following the RFC5011 process. 164 RFC5011 Validator A DNSSEC validator that is using the RFC5011 165 processes to track and update trust anchors. 167 Attacker An attacker intent on foiling the RFC5011 Validator's 168 ability to successfully adopt the Zone Maintainer's Knew key as a 169 trust anchor. 171 5.1.1. Attack Timing Breakdown 173 The following series of steps depicts the timeline in which an attack 174 occurs that foils the publisher of a new key who revokes the old key 175 too quickly. 177 T-1 The last signatures are published by the Zone Maintainer that 178 signs only Kold using Kold. 180 T-0 The Zone Maintainer adds Knew to his zone and signs the zone's 181 key set with Kold. The RFC5011 Validator retrieves the new key 182 set and corresponding signature set and notices the publication of 183 Knew. The RFC5011 Validator starts the hold-down timer for Knew. 185 T+5 The RFC5011 Validator queries for the zone's keyset per the 186 Active Refresh schedule, discussed in Section 2.3 of RFC5011. 187 Instead of receiving the intended published keyset, the Attacker 188 successfully replays the keyset and associated signatures that 189 they recorded at T-1. Because the signature lifetime is 10 days 190 (in this example), the replayed signature and keyset is accepted 191 as valid (being only 6 days old) and the RFC5011 Validator cancels 192 the hold-down timer for Knew. 194 T+10 The RFC5011 Validator queries for the zone's keyset and 195 discovers Knew again, signed by Kold (the attacker is unable to 196 replay the records at T-1, because they have now expired). It 197 starts the hold-timer for Knew again. 199 ... The RFC5011 Validator continues checking the zone's key set and 200 lets the hold-down timer keep running without resetting it. 202 T+30 The Zone Maintainer believes that this is the first time at 203 which some validators might accept Knew as a new trust anchor. 204 The hold-down timer of our RFC5011 Validator is at 20 days. 206 T+35 The Zone Maintainer mistakenly believes that all validators 207 following the Active Refresh schedule should have accepted Knew as 208 a the new trust anchor (since 30 days + 1/2 the signature validity 209 period would have passed). The hold-time timer of our RFC5011 210 Validator is at 25 days and has not actually reached its 30 day 211 requirement though. 213 T+36 The Zone Maintainer, believing Knew is safe to use, switches 214 their active KSK to Knew and publishes a new key set signature 215 using Knew as the signing key. Because our RFC5011 Validator 216 still has a hold-down timer for Knew at 26 days, it will fail to 217 validate this new key set and the zone contents will be treated as 218 invalid. 220 6. IANA Considerations 222 This document contains no IANA considerations. 224 7. Operational Considerations 226 A companion document to RFC5011 was expected to be published that 227 describes the best operational considerations from the perspective of 228 a zone publisher. However, the companion document was never written 229 but the authors of this document hope that it will at some point in 230 the future. This document is intended only to fill a single 231 operational void that results in security ramifications (specifically 232 a denial of service attack against an RFC5011 Validator). This 233 document does not attempt to document any other missing operational 234 guidance for zone publishers. 236 8. Security Considerations 238 This document, is solely about the security considerations with 239 respect to the publisher of RFC5011 trust anchors / keys. 241 9. Normative References 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, 245 DOI 10.17487/RFC2119, March 1997, 246 . 248 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 249 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 250 September 2007, . 252 Appendix A. Changes / Author Notes. 254 None yet 256 Authors' Addresses 258 Wes Hardaker 259 Parsons, Inc. 260 P.O. Box 382 261 Davis, CA 95617 262 US 264 Email: ietf@hardakers.net 266 Warren Kumari 267 Google 268 1600 Amphitheatre Parkway 269 Mountain View, CA 94043 270 US 272 Email: warren@kumari.net