idnits 2.17.00 (12 Aug 2021) /tmp/idnits34305/draft-ihren-dnsext-threshold-validation-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 525 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 67 instances of lines with control characters 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 431: '... KSK holders SHOULD therefore try to...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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? 'DS' on line 492 looks like a reference -- Missing reference section? 'RFC2535' on line 478 looks like a reference -- Missing reference section? 'RFC3090' on line 481 looks like a reference -- Missing reference section? 'RFC3110' on line 486 looks like a reference -- Missing reference section? 'RFC3225' on line 489 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Johan Ihren 3 draft-ihren-dnsext-threshold-validation-01.txt Autonomica 4 July 2004 Bill Manning 5 Expires in six months EP.NET 7 Threshold Validation: 9 A Mechanism for Improved Trust and Redundancy for DNSSEC Keys 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This memo documents a proposal for a different method of validation 36 for DNSSEC aware resolvers. The key change is that by changing from 37 a model of one Key Signing Key, KSK, at a time to multiple KSKs it 38 will be possible to increase the aggregated trust in the signed 39 keys by leveraging from the trust associated with the different 40 signees. 42 By having multiple keys to chose from validating resolvers get the 43 opportunity to use local policy to reflect actual trust in 44 different keys. For instance, it is possible to trust a single, 45 particular key ultimately, while requiring multiple valid 46 signatures by less trusted keys for validation to succeed. 47 Furthermore, with multiple KSKs there are additional redundancy 48 benefits available since it is possible to roll over different KSKs 49 at different times which may make rollover scenarios easier to 50 manage. 52 Contents 54 1. Terminology 55 2. Introduction and Background 57 3. Trust in DNSSEC Keys 58 3.1. Key Management, Split Keys and Trust Models 59 3.2. Trust Expansion: Authentication versus Authorization 61 4. Proposed Semantics for Signing the KEY Resource Record 62 Set 63 4.1. Packet Size Considerations 65 5. Proposed Use of Multiple "Trusted Keys" in a Validating 66 Resolver 67 5.1. Not All Possible KSKs Need to Be Trusted 68 5.2. Possible to do Threshold Validation 69 5.3. Not All Trusted Keys Will Be Available 71 6. Additional Benefits from Having Multiple KSKs 72 6.1. More Robust Key Rollovers 73 6.2. Evaluation of Multiple Key Distribution Mechanisms 75 7. Security Considerations 76 8. IANA Considerations. 77 9. References 78 9.1. Normative. 79 9.2. Informative. 80 10. Acknowledgments. 81 11. Authors' Address 83 1. Terminology 85 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 86 and "MAY" in this document are to be interpreted as described in 87 RFC 2119. 89 The term "zone" refers to the unit of administrative control in the 90 Domain Name System. "Name server" denotes a DNS name server that is 91 authoritative (i.e. knows all there is to know) for a DNS zone, 92 typically the root zone. A "resolver", is a DNS "client", i.e. an 93 entity that sends DNS queries to authoritative nameservers and 94 interpret the results. A "validating resolver" is a resolver that 95 attempts to perform DNSSEC validation on data it retrieves by doing 96 DNS lookups. 98 2. Introduction and Background 100 From a protocol perspective there is no real difference between 101 different keys in DNSSEC. They are all just keys. However, in 102 actual use there is lots of difference. First and foremost, most 103 DNSSEC keys have in-band verification. I.e. the keys are signed by 104 some other key, and this other key is in its turn also signed by 105 yet another key. This way a "chain of trust" is created. Such 106 chains have to end in what is referred to as a "trusted key" for 107 validation of DNS lookups to be possible. 109 A "trusted key" is a the public part of a key that the resolver 110 acquired by some other means than by looking it up in DNS. The 111 trusted key has to be explicitly configured in the resolver. 113 A node in the DNS hierarchy that issues such out-of-band "trusted 114 keys" is called a "security apex" and the trusted key for that apex 115 is the ultimate source of trust for all DNS lookups within that 116 entire subtree. 118 DNSSEC is designed to be able to work with more than one security 119 apex. These apexes will all share the problem of how to distribute 120 their "trusted keys" in a way that provides validating resolvers 121 with confidence in the distributed keys. 123 Maximizing that confidence is crucial to the usefulness of DNSSEC 124 and this document tries to address this issue. 126 3. Trust in DNSSEC Keys 128 In the end the trust that a validating resolver will be able to put 129 in a key that it cannot validate within DNSSEC will have to be a 130 function of 132 * trust in the key issuer, aka the KSK holder 134 * trust in the distribution method 136 * trust in extra, out-of-band verification 138 A KSK holder needs to be trusted not to accidentally lose private 139 keys in public places. Furthermore it needs to be trusted to 140 perform correct identification of the ZSK holders in case they are 141 separate from the KSK holder itself. 143 The distribution mechanism can be more or less tamper-proof. If the 144 key holder publishes the public key, or perhaps just a secure 145 fingerprint of the key in a major newspaper it may be rather 146 difficult to tamper with. A key acquired that way may be easier to 147 trust than if it had just been downloaded from a web page. 149 Out-of-band verification can for instance be the key being signed 150 by a certificate issued by a known Certificate Authority that the 151 resolver has reason to trust. 153 3.1. Simplicity vs Trust 155 The fewer keys that are in use the simpler the key management 156 becomes. Therefore increasing the number of keys should only be 157 considered when the complexity is not the major concern. A perfect 158 example of this is the distinction between so called Key Signing 159 Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds 160 overall complexity but simplifies real life operations and was an 161 overall gain since operational simplification was considered to be 162 a more crucial issue than the added complexity. 164 In the case of a security apex there are additional issues to 165 consider, among them 167 * maximizing trust in the KSK received out-of-band 169 * authenticating the legitimacy of the ZSKs used 171 In some cases this will be easy, since the same entity will manage 172 both ZSKs and KSKs (i.e. it will authenticate itself, somewhat 173 similar to a self-signed certificate). In some environments it will 174 be possible to get the trusted key installed in the resolver end by 175 decree (this would seem to be a likely method within corporate and 176 government environments). 178 In other cases, however, this will possibly not be sufficient. In 179 the case of the root zone this is obvious, but there may well be 180 other cases. 182 3.2. Expanding the "Trust Base" 184 For a security apex where the ZSKs and KSK are not held by the same 185 entity the KSK will effectively authenticate the identity of 186 whoever does real operational zone signing. The amount of trust 187 that the data signed by a ZSK will get is directly dependent on 188 whether the end resolver trusts the KSK or not, since the resolver 189 has no OOB access to the public part of the ZSKs (for practical 190 reasons). 192 Since the KSK holder is distinct from the ZSK holder the obvious 193 question is whether it would then be possible to further improve 194 the situation by using multiple KSK holders and thereby expanding 195 the trust base to the union of that available to each individual 196 KSK holder. "Trust base" is an invented term intended to signify 197 the aggregate of Internet resolvers that will eventually choose to 198 trust a key issued by a particular KSK holder. 200 A crucial issue when considering trust expansion through addition 201 of multiple KSK holders is that the KSK holders are only used to 202 authenticate the ZSKs used for signing the zone. I.e. the function 203 performed by the KSK is basically: 205 "This is indeed the official ZSK holder for this zone, 206 I've verified this fact to the best of my abilitites." 208 Which can be thought of as similar to the service of a public 209 notary. I.e. the point with adding more KSK holders is to improve 210 the public trust in data signed by the ZSK holders by improving the 211 strength of available authentication. 213 Therefore adding more KSK holders, each with their own trust base, 214 is by definition a good thing. More authentication is not 215 controversial. On the contrary, when it comes to authentication, 216 the more the merrier. 218 4. Proposed Semantics for Signing the KEY Resource Record Set 220 In DNSSEC according to RFC2535 all KEY Resource Records are used to 221 sign all authoritative data in the zone, including the KEY RRset 222 itself, since RFC2535 makes no distinction between Key Signing 223 Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS] 224 it is possible to change this to the KEY RRset being signed with 225 all KSKs and ZSKs but the rest of the zone only being signed by the 226 ZSKs. 228 This proposal changes this one step further, by recommending that 229 the KEY RRset is only signed by the Key Signing Keys, KSK, and 230 explicitly not by the Zone Signing Keys, ZSK. The reason for this 231 is to maximize the amount of space in the DNS response packet that 232 is available for additional KSKs and signatures thereof. The rest 233 of the authoritative zone contents are as previously signed by only 234 the ZSKs. 236 4.1. Packet Size Considerations 238 The reason for the change is to keep down the size of the aggregate 239 of KEY RRset plus SIG(KEY) that resolvers will need to acquire to 240 perform validation of data below a security apex. For DNSSEC data 241 to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be 242 set, and therefore the allowed packet size can be assumed to be at 243 least the EDNS0 minimum of 4000 bytes. 245 When querying for KEY + SIG(KEY) for "." (the case that is assumed 246 to be most crucial) the size of the response packet after the 247 change to only sign the KEY RR with the KSKs break down into a 248 rather large space of possibilities. Here are a few examples for 249 the possible alternatives for different numbers of KSKs and ZSKs 250 for some different key lengths (all RSA keys, with a public 251 exponent that is < 254). This is all based upon the size of the 252 response for the particular example of querying for 254 ". KEY IN" 256 with a response of entire KEY + SIG(KEY) with the authority and 257 additional sections empty: 259 ZSK/768 and KSK/1024 (real small) 260 Max 12 KSK + 3 ZSK at 3975 261 10 KSK + 8 ZSK at 3934 262 8 KSK + 13 ZSK at 3893 264 ZSK/768 + KSK/1280 265 MAX 10 KSK + 2 ZSK at 3913 266 8 KSK + 9 ZSK at 3970 267 6 KSK + 15 ZSK at 3914 269 ZSK/768 + KSK/1536 270 MAX 8 KSK + 4 ZSK at 3917 271 7 KSK + 8 ZSK at 3938 272 6 KSK + 12 ZSK at 3959 274 ZSK/768 + KSK/2048 275 MAX 6 KSK + 5 ZSK at 3936 276 5 KSK + 10 ZSK at 3942 278 ZSK/1024 + KSK/1024 279 MAX 12 KSK + 2 ZSK at 3943 280 11 KSK + 4 ZSK at 3930 281 10 KSK + 6 ZSK at 3917 282 8 KSK + 10 ZSK at 3891 284 ZSK/1024 + KSK/1536 285 MAX 8 KSK + 3 ZSK at 3900 286 7 KSK + 6 ZSK at 3904 287 6 KSK + 9 ZSK at 3908 289 ZSK/1024 + KSK/2048 290 MAX 6 KSK + 4 ZSK at 3951 291 5 KSK + 8 ZSK at 3972 292 4 KSK + 12 ZSK at 3993 294 Note that these are just examples and this document is not making 295 any recommendations on suitable choices of either key lengths nor 296 number of different keys employed at a security apex. 298 This document does however, based upon the above figures, make the 299 recommendation that at a security apex that expects to distribute 300 "trusted keys" the KEY RRset should only be signed with the KSKs 301 and not with the ZSKs to keep the size of the response packets 302 down. 304 5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver 306 In DNSSEC according to RFC2535[RFC2535] validation is the process 307 of tracing a chain of signatures (and keys) upwards through the DNS 308 hierarchy until a "trusted key" is reached. If there is a known 309 trusted key present at a security apex above the starting point 310 validation becomes an exercise with a binary outcome: either the 311 validation succeeds or it fails. No intermediate states are 312 possible. 314 With multiple "trusted keys" (i.e. the KEY RRset for the security 315 apex signed by multiple KSKs) this changes into a more complicated 316 space of alternatives. From the perspective of complexity that may 317 be regarded as a change for the worse. However, from a perspective 318 of maximizing available trust the multiple KSKs add value to the 319 system. 321 5.1. Possible to do Threshold Validation 323 With multiple KSKs a new option that opens for the security 324 concious resolver is to not trust a key individually. Instead the 325 resolver may decide to require the validated signatures to exceed a 326 threshold. For instance, given M trusted keys it is possible for 327 the resolver to require N-of-M signatures to treat the data as 328 validated. 330 I.e. with the following pseudo-configuration in a validating 331 resolver 333 security-apex "." IN { 334 keys { ksk-1 .... ; 335 ksk-2 .... ; 336 ksk-3 .... ; 337 ksk-4 .... ; 338 ksk-5 .... ; 339 }; 340 validation { 341 # Note that ksk-4 is not present below 342 keys { ksk-1; ksk-2; ksk-3; ksk-5; }; 343 # 3 signatures needed with 4 possible keys, aka 75% 344 needed-signatures 3; 345 }; 346 }; 348 we configure five trusted keys for the root zone, but require three 349 valid signatures for the top-most KEY for validation to succeed. 350 I.e. threshold validation does not force multiple signatures on 351 the entire signature chain, only on the top-most signature, closest 352 to the security apex for which the resolver has trusted keys. 354 5.2. Not All Trusted Keys Will Be Available 356 With multiple KSKs held and managed by separate entities the end 357 resolvers will not always manage to get access to all possible 358 trusted keys. In the case of just a single KSK this would be fatal 359 to validation and necessary to avoid at whatever cost. But with 360 several fully trusted keys available the resolver can decide to 361 trust several of them individually. An example based upon more 362 pseudo-configuration: 364 security-apex "." IN { 365 keys { ksk-1 .... ; 366 ksk-2 .... ; 367 ksk-3 .... ; 368 ksk-4 .... ; 369 ksk-5 .... ; 370 }; 371 validation { 372 # Only these two keys are trusted independently 373 keys { ksk-1; ksk-4; }; 374 # With these keys a single signature is sufficient 375 needed-signatures 1; 376 }; 377 }; 379 Here we have the same five keys and instruct the validating 380 resolver to fully trust data that ends up with just one signature 381 from by a fully trusted key. 383 The typical case where this will be useful is for the case where 384 there is a risk of the resolver not catching a rollover event by 385 one of the KSKs. By doing rollovers of different KSKs with 386 different schedules it is possible for a resolver to "survive" 387 missing a rollover without validation breaking. This improves 388 overall robustness from a management point of view. 390 5.3. Not All Possible KSKs Need to Be Trusted 392 With just one key available it simply has to be trusted, since that 393 is the only option available. With multiple KSKs the validating 394 resolver immediately get the option of implementing a local policy 395 of only trusting some of the possible keys. 397 This local policy can be implemented either by simply not 398 configuring keys that are not trusted or, possibly, configure them 399 but specify to the resolver that certain keys are not to be 400 ultimately trusted alone. 402 6. Additional Benefits from Having Multiple KSKs 404 6.1. More Robust Key Rollovers 406 With only one KSK the rollover operation will be a delicate 407 operation since the new trusted key needs to reach every validating 408 resolver before the old key is retired. For this reason it is 409 expected that long periods of overlap will be needed. 411 With multiple KSKs this changes into a system where different 412 "series" of KSKs can have different rollover schedules, thereby 413 changing from one "big" rollover to several "smaller" rollovers. 415 If the resolver trusts several of the available keys individually 416 then even a failure to track a certain rollover operation within 417 the overlap period will not be fatal to validation since the other 418 available trusted keys will be sufficient. 420 6.2. Evaluation of Multiple Key Distribution Mechanisms 422 Distribution of the trusted keys for the DNS root zone is 423 recognized to be a difficult problem that ... 425 With only one trusted key, from one single "source" to distribute 426 it will be difficult to evaluate what distribution mechanism works 427 best. With multiple KSKs, held by separate entitites it will be 428 possible to measure how large fraction of the resolver population 429 that is trusting what subsets of KSKs. 431 KSK holders SHOULD therefore try to use methods as diverse as 432 possible to publish the public part of the KSK. 434 7. Security Considerations 436 From a systems perspective the simplest design is arguably the 437 best, i.e. one single holder of both KSK and ZSKs. However, if that 438 is not possible in all cases a more complex scheme is needed where 439 additional trust is injected by using multiple KSK holders, each 440 contributing trust, then there are only two alternatives 441 available. The first is so called "split keys", where a single key 442 is split up among KSK holders, each contributing trust. The second 443 is the multiple KSK design outlined in this proposal. 445 Both these alternatives provide for threshold mechanisms. However 446 split keys makes the threshold integral to the key generating 447 mechanism (i.e. it will be a property of the keys how many 448 signatures are needed). In the case of multiple KSKs the threshold 449 validation is not a property of the keys but rather local policy in 450 the validating resolver. A benefit from this is that it is possible 451 for different resolvers to use different trust policies. Some may 452 configure threshold validation requiring multiple signatures and 453 specific keys (optimizing for security) while others may choose to 454 accept a single signature from a larger set of keys (optimizing for 455 redundancy). Since the security requirements are different it would 456 seem to be a good idea to make this choice local policy rather than 457 global policy. 459 Furthermore, a clear issue for validating resolvers will be how to 460 ensure that they track all rollover events for keys they trust. 461 Even with operlap during the rollover (which is clearly needed) 462 there is still a need to be exceedingly careful not to miss any 463 rollovers (or fail to acquire a new key) since without this single 464 key validation will fail. With multiple KSKs this operation becomes 465 more robust, since different KSKs may roll at different times 466 according to different rollover schedules. Therefore losing one 467 key, for whatever reason, will not be crucial unless the resolver 468 intentionally chooses to be completely dependent on that exact key. 470 8. IANA Considerations. 472 NONE. 474 9. References 476 9.1. Normative. 478 [RFC2535] Domain Name System Security Extensions. D. Eastlake. 479 March 1999. 481 [RFC3090] DNS Security Extension Clarification on Zone Status. 482 E. Lewis. March 2001. 484 9.2. Informative. 486 [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System 487 (DNS). D. Eastlake 3rd. May 2001. 489 [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. 490 December 2001. 492 [DS] Delegation Signer Resource Record. 493 O. Gudmundsson. October 2002. Work In Progress. 495 10. Acknowledgments. 497 We've had much appreciated help from (in no particular order) Jakob 498 Schlyter, Paul Vixie, Olafur Gudmundson and Olaf Kolkman. 500 11. Authors' Addresses 502 Johan Ihren 503 Autonomica AB 504 Bellmansgatan 30 505 SE-118 47 Stockholm, Sweden 506 johani@autonomica.se 508 Bill Manning 509 EP.NET 510 Marina del Rey, CA, USA 511 bmanning@ep.net