| blob | 67f9b2d6e5735cd370ac74543839e77ecda61c11 |
7 Network Working Group D. Massey
8 Request for Comments: 3445 USC/ISI
9 Updates: 2535 S. Rose
10 Category: Standards Track NIST
11 December 2002
14 Limiting the Scope of the KEY Resource Record (RR)
16 Status of this Memo
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
24 Copyright Notice
26 Copyright (C) The Internet Society (2002). All Rights Reserved.
28 Abstract
30 This document limits the Domain Name System (DNS) KEY Resource Record
31 (RR) to only keys used by the Domain Name System Security Extensions
32 (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC
33 keys and arbitrary application keys. Storing both DNSSEC and
34 application keys with the same record type is a mistake. This
35 document removes application keys from the KEY record by redefining
36 the Protocol Octet field in the KEY RR Data. As a result of removing
37 application keys, all but one of the flags in the KEY record become
38 unnecessary and are redefined. Three existing application key sub-
39 types are changed to reserved, but the format of the KEY record is
40 not changed. This document updates RFC 2535.
42 1. Introduction
44 This document limits the scope of the KEY Resource Record (RR). The
45 KEY RR was defined in [3] and used resource record sub-typing to hold
46 arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys.
47 This document eliminates the existing Email, IPSEC, and TLS sub-types
48 and prohibits the introduction of new sub-types. DNSSEC will be the
49 only allowable sub-type for the KEY RR (hence sub-typing is
50 essentially eliminated) and all but one of the KEY RR flags are also
51 eliminated.
58 Massey & Rose Standards Track [Page 1]
59 \f
60 RFC 3445 Limiting the KEY Resource Record (RR) December 2002
63 Section 2 presents the motivation for restricting the KEY record and
64 Section 3 defines the revised KEY RR. Sections 4 and 5 summarize the
65 changes from RFC 2535 and discuss backwards compatibility. It is
66 important to note that this document restricts the use of the KEY RR
67 and simplifies the flags, but does not change the definition or use
68 of DNSSEC keys.
70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
72 document are to be interpreted as described in RFC 2119 [1].
74 2. Motivation for Restricting the KEY RR
76 The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an
77 Algorithm type, and a Public Key. The Protocol Octet identifies the
78 KEY RR sub-type. DNSSEC public keys are stored in the KEY RR using a
79 Protocol Octet value of 3. Email, IPSEC, and TLS keys were also
80 stored in the KEY RR and used Protocol Octet values of 1,2, and 4
81 (respectively). Protocol Octet values 5-254 were available for
82 assignment by IANA and values were requested (but not assigned) for
83 applications such as SSH.
85 Any use of sub-typing has inherent limitations. A resolver can not
86 specify the desired sub-type in a DNS query and most DNS operations
87 apply only to resource records sets. For example, a resolver can not
88 directly request the DNSSEC subtype KEY RRs. Instead, the resolver
89 has to request all KEY RRs associated with a DNS name and then search
90 the set for the desired DNSSEC sub-type. DNSSEC signatures also
91 apply to the set of all KEY RRs associated with the DNS name,
92 regardless of sub-type.
94 In the case of the KEY RR, the inherent sub-type limitations are
95 exacerbated since the sub-type is used to distinguish between DNSSEC
96 keys and application keys. DNSSEC keys and application keys differ
97 in virtually every respect and Section 2.1 discusses these
98 differences in more detail. Combining these very different types of
99 keys into a single sub-typed resource record adds unnecessary
100 complexity and increases the potential for implementation and
101 deployment errors. Limited experimental deployment has shown that
102 application keys stored in KEY RRs are problematic.
104 This document addresses these issues by removing all application keys
105 from the KEY RR. Note that the scope of this document is strictly
106 limited to the KEY RR and this document does not endorse or restrict
107 the storage of application keys in other, yet undefined, resource
108 records.
114 Massey & Rose Standards Track [Page 2]
115 \f
116 RFC 3445 Limiting the KEY Resource Record (RR) December 2002
119 2.1 Differences Between DNSSEC and Application Keys
121 DNSSEC keys are an essential part of the DNSSEC protocol and are used
122 by both name servers and resolvers in order to perform DNS tasks. A
123 DNS zone key, used to sign and authenticate RR sets, is the most
124 common example of a DNSSEC key. SIG(0) [4] and TKEY [3] also use
125 DNSSEC keys.
127 Application keys such as Email keys, IPSEC keys, and TLS keys are
128 simply another type of data. These keys have no special meaning to a
129 name server or resolver.
131 The following table summarizes some of the differences between DNSSEC
132 keys and application keys:
134 1. They serve different purposes.
136 2. They are managed by different administrators.
138 3. They are authenticated according to different rules.
140 4. Nameservers use different rules when including them in
141 responses.
143 5. Resolvers process them in different ways.
145 6. Faults/key compromises have different consequences.
147 1. The purpose of a DNSSEC key is to sign resource records
148 associated with a DNS zone (or generate DNS transaction signatures in
149 the case of SIG(0)/TKEY). But the purpose of an application key is
150 specific to the application. Application keys, such as PGP/email,
151 IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and
152 the purpose and proper use of application keys is outside the scope
153 of DNS.
155 2. DNSSEC keys are managed by DNS administrators, but application
156 keys are managed by application administrators. The DNS zone
157 administrator determines the key lifetime, handles any suspected key
158 compromises, and manages any DNSSEC key changes. Likewise, the
159 application administrator is responsible for the same functions for
160 the application keys related to the application. For example, a user
161 typically manages her own PGP key and a server manages its own TLS
162 key. Application key management tasks are outside the scope of DNS
163 administration.
170 Massey & Rose Standards Track [Page 3]
171 \f
172 RFC 3445 Limiting the KEY Resource Record (RR) December 2002
175 3. DNSSEC zone keys are used to authenticate application keys, but
176 by definition, application keys are not allowed to authenticate DNS
177 zone keys. A DNS zone key is either configured as a trusted key or
178 authenticated by constructing a chain of trust in the DNS hierarchy.
179 To participate in the chain of trust, a DNS zone needs to exchange
180 zone key information with its parent zone [3]. Application keys are
181 not configured as trusted keys in the DNS and are never part of any
182 DNS chain of trust. Application key data is not needed by the parent
183 and does not need to be exchanged with the parent zone for secure DNS
184 resolution to work. A resolver considers an application key RRset as
185 authenticated DNS information if it has a valid signature from the
186 local DNS zone keys, but applications could impose additional
187 security requirements before the application key is accepted as
188 authentic for use with the application.
190 4. It may be useful for nameservers to include DNS zone keys in the
191 additional section of a response, but application keys are typically
192 not useful unless they have been specifically requested. For
193 example, it could be useful to include the example.com zone key along
194 with a response that contains the www.example.com A record and SIG
195 record. A secure resolver will need the example.com zone key in
196 order to check the SIG and authenticate the www.example.com A record.
197 It is typically not useful to include the IPSEC, email, and TLS keys
198 along with the A record. Note that by placing application keys in
199 the KEY record, a resolver would need the IPSEC, email, TLS, and
200 other key associated with example.com if the resolver intends to
201 authenticate the example.com zone key (since signatures only apply to
202 the entire KEY RR set). Depending on the number of protocols
203 involved, the KEY RR set could grow unwieldy for resolvers, and DNS
204 administrators to manage.
206 5. DNS zone keys require special handling by resolvers, but
207 application keys are treated the same as any other type of DNS data.
208 The DNSSEC keys are of no value to end applications, unless the
209 applications plan to do their own DNS authentication. By definition,
210 secure resolvers are not allowed to use application keys as part of
211 the authentication process. Application keys have no unique meaning
212 to resolvers and are only useful to the application requesting the
213 key. Note that if sub-types are used to identify the application
214 key, then either the interface to the resolver needs to specify the
215 sub-type or the application needs to be able to accept all KEY RRs
216 and pick out the desired sub-type.
218 6. A fault or compromise of a DNS zone key can lead to invalid or
219 forged DNS data, but a fault or compromise of an application key
220 should have no impact on other DNS data. Incorrectly adding or
221 changing a DNS zone key can invalidate all of the DNS data in the
222 zone and in all of its subzones. By using a compromised key, an
226 Massey & Rose Standards Track [Page 4]
227 \f
228 RFC 3445 Limiting the KEY Resource Record (RR) December 2002
231 attacker can forge data from the effected zone and for any of its
232 sub-zones. A fault or compromise of an application key has
233 implications for that application, but it should not have an impact
234 on the DNS. Note that application key faults and key compromises can
235 have an impact on the entire DNS if the application key and DNS zone
236 keys are both stored in the KEY RR.
238 In summary, DNSSEC keys and application keys differ in most every
239 respect. DNSSEC keys are an essential part of the DNS infrastructure
240 and require special handling by DNS administrators and DNS resolvers.
241 Application keys are simply another type of data and have no special
242 meaning to DNS administrators or resolvers. These two different
243 types of data do not belong in the same resource record.
245 3. Definition of the KEY RR
247 The KEY RR uses type 25 and is used as resource record for storing
248 DNSSEC keys. The RDATA for a KEY RR consists of flags, a protocol
249 octet, the algorithm number octet, and the public key itself. The
250 format is as follows:
252 ---------------------------------------------------------------------
255 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
256 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
257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
258 | flags | protocol | algorithm |
259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
260 | /
261 / public key /
262 / /
263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
265 KEY RR Format
267 ---------------------------------------------------------------------
269 In the flags field, all bits except bit 7 are reserved and MUST be
270 zero. If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
271 key. If Bit 7 is set to 0, the KEY is not a zone key. SIG(0)/TKEY
272 are examples of DNSSEC keys that are not zone keys.
274 The protocol field MUST be set to 3.
276 The algorithm and public key fields are not changed.
282 Massey & Rose Standards Track [Page 5]
283 \f
284 RFC 3445 Limiting the KEY Resource Record (RR) December 2002
287 4. Changes from RFC 2535 KEY RR
289 The KEY RDATA format is not changed.
291 All flags except for the zone key flag are eliminated:
293 The A/C bits (bits 0 and 1) are eliminated. They MUST be set to 0
294 and MUST be ignored by the receiver.
296 The extended flags bit (bit 3) is eliminated. It MUST be set to 0
297 and MUST be ignored by the receiver.
299 The host/user bit (bit 6) is eliminated. It MUST be set to 0 and
300 MUST be ignored by the receiver.
302 The zone bit (bit 7) remains unchanged.
304 The signatory field (bits 12-15) are eliminated by [5]. They MUST
305 be set to 0 and MUST be ignored by the receiver.
307 Bits 2,4,5,8,9,10,11 remain unchanged. They are reserved, MUST be
308 set to zero and MUST be ignored by the receiver.
310 Assignment of any future KEY RR Flag values requires a standards
311 action.
313 All Protocol Octet values except DNSSEC (3) are eliminated:
315 Value 1 (Email) is renamed to RESERVED.
317 Value 2 (IPSEC) is renamed to RESERVED.
319 Value 3 (DNSSEC) is unchanged.
321 Value 4 (TLS) is renamed to RESERVED.
323 Value 5-254 remains unchanged (reserved).
325 Value 255 (ANY) is renamed to RESERVED.
327 The authoritative data for a zone MUST NOT include any KEY records
328 with a protocol octet other than 3. The registry maintained by IANA
329 for protocol values is closed for new assignments.
331 Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
332 RRs with a value other than 3. If out of date DNS zones contain
333 deprecated KEY RRs with a protocol octet value other than 3, then
334 simply dropping the deprecated KEY RRs from the KEY RR set would
338 Massey & Rose Standards Track [Page 6]
339 \f
340 RFC 3445 Limiting the KEY Resource Record (RR) December 2002
343 invalidate any associated SIG record(s) and could create caching
344 consistency problems. Note that KEY RRs with a protocol octet value
345 other than 3 MUST NOT be used to authenticate DNS data.
347 The algorithm and public key fields are not changed.
349 5. Backward Compatibility
351 DNSSEC zone KEY RRs are not changed and remain backwards compatible.
352 A properly formatted RFC 2535 zone KEY would have all flag bits,
353 other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
354 Octet set to 3. This remains true under the restricted KEY.
356 DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
357 but the distinction between host and user keys (flag bit 6) is lost.
359 No backwards compatibility is provided for application keys. Any
360 Email, IPSEC, or TLS keys are now deprecated. Storing application
361 keys in the KEY RR created problems such as keys at the apex and
362 large RR sets and some change in the definition and/or usage of the
363 KEY RR would have been required even if the approach described here
364 were not adopted.
366 Overall, existing nameservers and resolvers will continue to
367 correctly process KEY RRs with a sub-type of DNSSEC keys.
369 6. Storing Application Keys in the DNS
371 The scope of this document is strictly limited to the KEY record.
372 This document prohibits storing application keys in the KEY record,
373 but it does not endorse or restrict the storing application keys in
374 other record types. Other documents can describe how DNS handles
375 application keys.
377 7. IANA Considerations
379 RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
380 values. Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
381 values 5-254 were made available for assignment by IANA. This
382 document makes two sets of changes to this registry.
384 First, this document re-assigns DNS KEY RR Protocol Octet values 1,
385 2, 4, and 255 to "reserved". DNS Key RR Protocol Octet Value 3
386 remains unchanged as "DNSSEC".
394 Massey & Rose Standards Track [Page 7]
395 \f
396 RFC 3445 Limiting the KEY Resource Record (RR) December 2002
399 Second, new values are no longer available for assignment by IANA and
400 this document closes the IANA registry for DNS KEY RR Protocol Octet
401 Values. Assignment of any future KEY RR Protocol Octet values
402 requires a standards action.
404 8. Security Considerations
406 This document eliminates potential security problems that could arise
407 due to the coupling of DNS zone keys and application keys. Prior to
408 the change described in this document, a correctly authenticated KEY
409 set could include both application keys and DNSSEC keys. This
410 document restricts the KEY RR to DNS security usage only. This is an
411 attempt to simplify the security model and make it less user-error
412 prone. If one of the application keys is compromised, it could be
413 used as a false zone key to create false DNS signatures (SIG
414 records). Resolvers that do not carefully check the KEY sub-type
415 could believe these false signatures and incorrectly authenticate DNS
416 data. With this change, application keys cannot appear in an
417 authenticated KEY set and this vulnerability is eliminated.
419 The format and correct usage of DNSSEC keys is not changed by this
420 document and no new security considerations are introduced.
422 9. Normative References
424 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
425 Levels", BCP 14, RFC 2119, March 1997.
427 [2] Eastlake, D., "Domain Name System Security Extensions", RFC
428 2535, March 1999.
430 [3] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
431 2930, September 2000.
433 [4] Eastlake, D., "DNS Request and Transaction Signatures
434 (SIG(0)s)", RFC 2931, September 2000.
436 [5] Wellington, B., "Secure Domain Name System (DNS) Dynamic
437 Update", RFC 3007, November 2000.
450 Massey & Rose Standards Track [Page 8]
451 \f
452 RFC 3445 Limiting the KEY Resource Record (RR) December 2002
455 10. Authors' Addresses
457 Dan Massey
458 USC Information Sciences Institute
459 3811 N. Fairfax Drive
460 Arlington, VA 22203
461 USA
463 EMail: masseyd@isi.edu
466 Scott Rose
467 National Institute for Standards and Technology
468 100 Bureau Drive
469 Gaithersburg, MD 20899-3460
470 USA
472 EMail: scott.rose@nist.gov
506 Massey & Rose Standards Track [Page 9]
507 \f
508 RFC 3445 Limiting the KEY Resource Record (RR) December 2002
511 11. Full Copyright Statement
513 Copyright (C) The Internet Society (2002). All Rights Reserved.
515 This document and translations of it may be copied and furnished to
516 others, and derivative works that comment on or otherwise explain it
517 or assist in its implementation may be prepared, copied, published
518 and distributed, in whole or in part, without restriction of any
519 kind, provided that the above copyright notice and this paragraph are
520 included on all such copies and derivative works. However, this
521 document itself may not be modified in any way, such as by removing
522 the copyright notice or references to the Internet Society or other
523 Internet organizations, except as needed for the purpose of
524 developing Internet standards in which case the procedures for
525 copyrights defined in the Internet Standards process must be
526 followed, or as required to translate it into languages other than
527 English.
529 The limited permissions granted above are perpetual and will not be
530 revoked by the Internet Society or its successors or assigns.
532 This document and the information contained herein is provided on an
533 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
534 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
535 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
536 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
537 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
539 Acknowledgement
541 Funding for the RFC Editor function is currently provided by the
542 Internet Society.
562 Massey & Rose Standards Track [Page 10]
563 \f