diff --git a/doc/draft/draft-ietf-dnsext-parent-sig-00.txt b/doc/draft/draft-ietf-dnsext-parent-sig-00.txt new file mode 100644 index 0000000000..31349e4467 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-parent-sig-00.txt @@ -0,0 +1,354 @@ +INTERNET-DRAFT R. Gieben +DNSEXT Working Group NLnet Labs +Expires September 2001 T. Lindgreen + NLnet Labs + + Parent's SIG over child's KEY + + draft-ietf-dnsext-parent-sig-00.txt + + +Status of This Document + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other documents + at any time. It is inappropriate to use Internet- Drafts as + reference material or to cite them other than as "work in progress." + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. The list of + Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments should be sent to the authors or the DNSEXT WG mailing + list namedroppers@ops.ietf.org. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All rights reserved. + + +Abstract + + When dealing with large amounts of keys the procedures to update a + zone and to sign a zone need to be clearly defined and practically + possible. The current idea is to have the KEY RR and the parent's + SIG to reside in the child's zone and perhaps also in the parent's + zone. We feel that this would lead to very complicated procedures for + large TLDs. We propose an alternative scheme in which the parent zone + stores the parent's signature over the child's key and also a copy of + the child's key itself. + + The advantage of this proposal is that all signatures signed by a + key are in the same zone file as the producing key. This allows for a + simple key rollover and resigning mechanism. For large TLDs this is + extremely important. + + + + + Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 2] + + + We further discuss the impact on a secure aware resolver/forwarder + and the impact on the authority of KEYs and the NXT record. + +Table of Contents + + Status of This Document....................................2 + Abstract...................................................2 + + Table of Contents..........................................3 + 1 Introduction.............................................3 + 2 Proposal.................................................4 + 3 Impact on a secure aware resolver/forwarder..............4 + 3.1 Impact of key rollovers on resolver/forwarder..........4 + 4 Key rollovers............................................5 + 4.1 Scheduled key rollover.................................5 + 4.2 Unscheduled key rollover...............................5 + 5 Zone resigning...........................................6 + 6. Consequences for KEY and NXT records....................6 + 6.1. KEY bit in NXT records................................6 + 6.2. Authority of KEY records..............................6 + 7. Security Considerations.................................6 + + Authors' Addresses.........................................7 + References.................................................7 + Full Copyright Statement...................................7 + + +1. Introduction + Within a CENTR working group NLnet Labs is researching the impact + of DNSSEC on the ccTLDs and gTLDs. + + In this document we are considering a secure zone, somewhere under + a secure entry point and on-tree [1] validation between the secure + entry point and the zone in question. The resolver we are + considering is security aware and is preconfigured with the KEY of + the secure entry point. + + RFC 2535 [3] states that a zone key must be present in the apex of + a zone. This can be in the at the delegation point in the parent's + zonefile (normally the case for null keys), or in the child's + zonefile, or in both. This key is only valid if it is signed by the + parent, so there is also the question where this signature is + located. + + The original idea was to have the KEY RR and the parent's SIG to + reside in the child's zone and perhaps also in the parent's zone. + There is a draft proposal [4], that describes how a keyrollover can + be handled. + + At NLnet Labs we found that storing the parent's signature over + the child's key in the child's zone: + - makes resigning a KEY by the parent difficult + + + + Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 3] + + + - makes a scheduled keyrollover very complicated + - makes an unscheduled keyrollover virtually impossible + + We propose an alternative scheme in which the parent's signature + over the child's key is only stored in the parent's zone, i.e. where + the signing key resides. This would solve the above problems. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" + in this document are to be interpreted as described in [2]. + + +2. Proposal + The core of the new proposal is that the parent zone stores the + parent's signature over the child's key and also a copy of the + child's key itself. The child zone also contains its zonekey, where + it is selfsigned. + + The advantage of this proposal is that all signatures signed by a + key are in the same zone file as the producing key. This allows for a + simple key rollover and resigning mechanism. For large TLD's this is + extremely important. A disadvantage would be that not all the + information concerning one zone is stored at that zone, namely the + (parent) SIG RR. Note that the same argument can be applied to a + zone's NULL key, which is also stored at the parent. + + +3. Impact on a secure aware resolver/forwarder + The resolver must be aware of the fact that the parent is more + authoritative than a child when it comes to deciding whether a zone + is secured or not. + + Without caching and with on-tree validation, a resolver will + always start its search at a secure entry point. In this way it can + determine whether it must expect SIG records or not. + + Considering caching in a secure aware resolver or forwarder. If + information of a secure zone is cached, its validated KEY should also + be cached. + + If the KEY record expires, because the KEY TTL expires or because + the SIG is no longer valid, the KEY should be discarded. The resolver + or forwarder should then also discard other data concerning the zone + because it is no longer validated and possible bad data should not be + cached. + +3.1. Impact of key rollovers on resolver/forwarder + + When a zone is in the process of a key rollover, there could be a + discrepancy between the KEY and the SIG in the apex of the zone and + the KEY and SIG that are stored in the cache of a resolver. + + + + + Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 4] + + + + Suppose a resolver has cached the NS, KEY and SIG records of a + zone. Next a request comes for an A record in that zone. Also the + zone is in the process of a keyrollover and already has new keys in + its zone. The resolver receives an answer consisting of the A record + and a SIG over the A record. It uses the tag field in the SIG to + determine if it has a KEY which is suitable to validate the SIG. If + it does not has such a KEY the resolver must ask the parent of the + zone for a new KEY and then try it again. Now the resolver has 2 + keys for the zone, according to the tag field in the SIG it can use + either one. + + If the new key also does not validate the SIG the zone is marked + bad. If the KEY found at the parent is the NULL key the resolver + knows that the child is considered insecure. This could for instance + be in the case the private key of the zone is stolen. + + +4. Key rollovers + Private keys can be stolen or a key can become over used. In both + cases a new key must be signed and distributed. This event is called + keyrollover. We further distinguish between a scheduled and an + unscheduled key rollover. A scheduled rollover is announced before + hand. An unscheduled key rollover is needed when a private key is + compromised. + +4.1. Scheduled key rollover + When the signatures, produced by the key to be rolled over, are + all in one zone file, there are two parties involved. Let us look at + an example where a TLD rolls over its zone key. The new key needs to + be signed with the root's key before it can be used to sign the TLD + zone and the zone keys of the TLD's children. The steps that need to + be taken by TLD and root are: + - the TLD adds the new key to its keyset in its zonefile. This + zone and keyset are signed with the old zonekey + - then the TLD signals the parent + - the root copies the new keyset, consisting of the both new + and the old key, in its zonefile, resigns it and signals the + TLD + - the TLD removes the old key from its keyset, resigns its zone + with the new key, and signals the the root + - the root copies the new keyset, now consisting of the new key + only, and resigns it + +4.2. Unscheduled key rollover + Although nobody hopes that this will ever happen, we must be able + to cope with possible key compromises. When such an event occurs, an + immediate keyrollover is needed and must be completed in the shortest + possible time. With two parties involved, it will still be awkward, + but not impossible to update two zonefiles overnight. "Out-of-band" + communication between the two parties will be necessary, since the + compromised old key can not be trusted. We think that between two + + + + Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 5] + + + parties this is doable, but this complicated procedure is beyond the + scope of this document. [5] + + +5. Zone resigning + Resigning a TLD is necessary before the current signatures expire. + When all SIG records, produced by the TLD's zone key are kept in the + TLD's zonefile, and only there, such a resign session is trivial, as + only one party (the TLD) and one zonefile is involved. + + +6. Consequences for KEY and NXT records + A key record is only present in a child zone to facilitate a key + rollover. A resolver should therefore be aware that the zonekey of a + child zone is actually stored in the parent's zone. This also affects + the NXT record and the authority of KEY resource records. + +6.1. KEY bit in NXT records + RFC 2535 [3], section 5.2 states: + + " The NXT RR type bit map format currently defined is one bit per + RR type present for the owner name. A one bit indicates that at + least one RR of that type is present for the owner name. A zero + indicates that no such RR is present. [....] " + + With a KEY still present in a child zone we do not see a compelling + reason to change this default behavior. + +6.2. Authority of KEY records + The parent of a zone generates the signature for the key belonging + to that zone. By making that signature available the parent publicly + states that the child zone is trustworthy: when it comes to security + in DNSSEC the parent is more authoritative than the child. + + From this we conclude that a parent zone MUST set the authority + bit to 1 and child zones MUST set this bit to 0 when dealing with + KEYs from that child zone. + + A secure entry point has a selfsigned key and thus has no parent who + is more authoritative on that key. This is not a problem. If a + resolver knows that a secure entry point is a secure entry point it + must have its key preconfigured. There is no need for a parent in + this scenario, because the resolver itself can check the security of + that zone. A interesting consequence of this is that nobody, but the + resolver is authoritative for a key belonging to a secure entry + point. This authority must established via some out of band + mechanism, like publishing keys in a newspaper. + + +7. Security Considerations + This whole document is about security. + + + + + Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 6] + + + + +Authors' Addresses + + R. Gieben + Stichting NLnet Labs + Kruislaan 419 + 1098 VA Amsterdam + miek@nlnetlabs.nl + + T. Lindgreen + Stichting NLnet Labs + Kruislaan 419 + 1098 VA Amsterdam + ted@nlnetlabs.nl + + +References + + [1] Lewis, E. "DNS Security Extension Clarification on Zone Status", + www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-04.txt + [2] Bradner, S. "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119 + www.ietf.org/rfc/rfc2119.txt + [3] Eastlake, D. "DNS Security Extensions", RFC 2535 + www.ietf.org/rfc/rfc2535.txt + [4] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security Key Rollover" + www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt + [5] Gieben, R. "Chain of trust" + secnl.nlnetlabs.nl/thesis/thesis.html + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished + to others, and derivative works that comment on or otherwise explain + it or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not + be revoked by the Internet Society or its successors or assigns. + + + + Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 7] + + + + This document and the information contained herein is provided on + an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. diff --git a/doc/draft/draft-ietf-dnsext-parent-stores-zone-keys-00.txt b/doc/draft/draft-ietf-dnsext-parent-stores-zone-keys-00.txt new file mode 100644 index 0000000000..a5653fa28f --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-parent-stores-zone-keys-00.txt @@ -0,0 +1,496 @@ +INTERNET-DRAFT R. Gieben +DNSEXT Working Group NLnet Labs +Expires September 2001 T. Lindgreen + NLnet Labs + + Parent stores the child's zone KEYs + + draft-ietf-dnsext-parent-stores-zone-keys-00.txt + + +Status of This Document + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other documents + at any time. It is inappropriate to use Internet- Drafts as + reference material or to cite them other than as "work in progress." + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. The list of + Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments should be sent to the authors or the DNSEXT WG mailing + list namedroppers@ops.ietf.org. + + This document updates RFC 2535 [2]. + + +Copyright Notice + + Copyright (C) The Internet Society (2001). All rights reserved. + + +Abstract + + When dealing with large amounts of keys the procedures to update a + zone and to sign a zone need to be clearly defined and practically + possible. The current idea is to have the zone KEY RR and the + parent's SIG to reside in the child's zone and perhaps also in the + parent's zone. Operational experiences have prompted us to develop an + alternative scheme in which the parent zone stores the parent's + signature over the child's key and also the child's key itself. + + The advantage of this scheme is that all signatures signed by a key + are in the same zone file as the producing key. This allows for a + + + + Gieben Expires September 2001 [Page 2] + +Internet Draft Parent Stores Zone KEYS March 2001 + + simple key rollover and resigning mechanism. For large TLDs this is + extremely important. + + Besides the operational advantages, this also obsoletes the NULL key, + as the absence of child's zone KEY, which is securely verified by the + absence of the KEY-bit in the corresponding NXT RR, now unambiguously + indicates that the child is not secured by this parent. + + We further discuss the impact on a secure aware resolver/forwarder + and the impact on the authority of KEYs and the NXT record. + + +Table of Contents + + Status of This Document....................................2 + Abstract...................................................2 + + Table of Contents..........................................3 + 1 Introduction.............................................3 + 2 Proposal.................................................4 + 2.1. TTL of the KEY and SIG at the parent..................4 + 2.2. No NULL KEY...........................................5 + 3 Impact on a secure aware resolver/forwarder..............5 + 3.1 Impact of key rollovers on resolver/forwarder..........5 + 4 Scheduled key rollover...................................6 + 5 Unscheduled key rollover.................................6 + 6 Zone resigning...........................................7 + 7. Consequences for KEY and NXT records....................7 + 7.1. KEY bit in NXT records................................7 + 7.2. Authority of KEY records..............................8 + 7.3. Selecting KEY sets....................................8 + 8. The zone-KEY and local KEY records......................8 + 9. Security Considerations.................................8 + + Authors' Addresses.........................................9 + References.................................................9 + Full Copyright Statement...................................9 + + +1. Introduction + Within a CENTR working group NLnet Labs is researching the impact of + DNSSEC on the ccTLDs and gTLDs. + + In this document we are considering a secure zone, somewhere under a + secure entry point and on-tree [1] validation between the secure + entry point and the zone in question. The resolver we are + considering is security aware and is preconfigured with the KEY of + the secure entry point. We also make a distinction between a + scheduled and a unscheduled key rollover. A scheduled rollover is + announced before hand. An unscheduled key rollover is needed when a + private key is compromised. + + + + Gieben Expires September 2001 [Page 3] + +Internet Draft Parent Stores Zone KEYS March 2001 + + + RFC 2535 [2] states that a zone KEY must be present in the apex of a + zone. This can be in the at the delegation point in the parent's + zonefile, or in the child's zonefile, or in both. This key is only + valid if it is signed by the parent, so there is also the question + where this signature and this zone KEY are located. + + The original idea was to have the zone KEY RR and the parent's SIG to + reside in the child's zone and perhaps also in the parent's zone. + There is a draft proposal [3], that describes how a keyrollover can + be handled. + + At NLnet Labs we found that storing the parent's signature over the + child's zone KEY in the child's zone: + - makes resigning a KEY by the parent difficult + - makes a scheduled keyrollover very complicated + - makes an unscheduled keyrollover virtually impossible + + We propose an alternative scheme in which the parent's signature over + the child's zone KEY and the child's zone KEY itself are only stored + in the parent's zone, i.e. where the signing key resides. This would + solve the above problems and also obsoletes the NULL KEY. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [2]. + + +2. Proposal + The core of the new proposal is that the parent zone stores the + parent's signature over the child's zone KEY and also the child's + zone KEY itself. The child zone may also contain its zone KEY, in + which case is must be selfsigned. + + The main advantage of this proposal is that all signatures signed by + a key are in the same zone file as the producing key. This allows for + a simple key rollover and resigning mechanism. For large TLDs this is + extremely important. A disadvantage would be that not all the + information concerning one zone is stored at that zone, this is + covered in section 7.2. + + A parent running DNSSEC SHOULD NOT refuse a request from a child to + include and sign its key, but can ask for certain conditions to be + met. These condition could include a fee, sufficient authentication, + signing a non liability clause, the conditions specified in section 8 + of this document, etc. + +2.1. TTL of the KEY and SIG at the parent + Each zone in DNS expresses in its SOA record the maximum and minimum + TTL values that they allow in the zone. Thus it is possible that the + parent will sign with a value that is unacceptable to the child. The + + + + Gieben Expires September 2001 [Page 4] + +Internet Draft Parent Stores Zone KEYS March 2001 + + parent MUST follow the TTL request of the child as long as that is + within the allowed range for the parent. + +2.2. No NULL KEY + This proposal obsoletes the NULL KEY. If there is no child KEY at the + parent, which can be securely verified by inspecting the the unset + KEY-bit in the corresponding NXT RR, the child is not secured by this + parent (of course, the child can then still be secured off-tree). + This updates section 3.1.2 "The zone KEY RR Flag Field" of RFC 2535, + it says: + + " 11: If both bits are one, the "no key" value, there is no key + information and the RR stops after the algorithm octet. + By the use of this "no key" value, a signed zone KEY RR can + authenticatably assert that, for example, a zone is not + secured. See section 3.4 below. " + + As we don't have a NULL KEY anymore this is obsoleted. + Section 3.4 "Determination of Zone Secure/Unsecured Status": + + " A zone KEY RR with the "no-key" type field value (both key type + flag bits 0 and 1 on) indicates that the zone named is unsecured + while a zone KEY RR with a key present indicates that the zone named + is secure. The secured versus unsecured status of a zone may vary + with different cryptographic algorithms. Even for the same + algorithm, conflicting zone KEY RRs may be present. " + + This is rewritten as: + + " A zone is considered secured by on-tree validation [1] when the + there is a zone KEY from that zone present at its parent. If there + is no zone KEY present, and the resolver is also unaware of + alternative algorithms used and/or possible off-tree validation, the + zone is considered unsecured. " + + +3. Impact on a secure aware resolver/forwarder + The resolver must be aware of the fact that the parent is more + authoritative than a child when it comes to deciding whether a zone + is secured or not. + + Without caching and with on-tree validation, a resolver will always + start its search at a secure entry point. In this way it can + determine whether it must expect SIG records or not. + + Considering caching in a secure aware resolver or forwarder. If + information of a secure zone is cached, its validated KEY should also + be cached. + +3.1. Impact of key rollovers on resolver/forwarder + When a zone is in the process of a key rollover, there could be a + + + + Gieben Expires September 2001 [Page 5] + +Internet Draft Parent Stores Zone KEYS March 2001 + + discrepancy between the KEY and the SIG in the apex of the zone and + the KEY and SIG that are stored in the cache of a resolver. + + Suppose a resolver has cached the NS, KEY and SIG records of a zone. + Next a request comes for an A record in that zone. Also the zone is + in the process of a key rollover and already has new keys in its + zone. The resolver receives an answer consisting of the A record and + a SIG over the A record. It uses the tag field in the SIG to + determine if it has a KEY which is suitable to validate the SIG. If + it does not has such a KEY the resolver must ask the parent of the + zone for a new KEY and then try it again. Now the resolver has 2 + keys for the zone, according to the tag field in the SIG it can use + either one. + + If the new key also does not validate the SIG the zone is marked bad. + If the parent indicates by having a not set KEY-bit in the NXT RR + that there is no KEY for this zone, the child must be considered + unsecured by this parent, despite the appearance of an (old) KEY in + the cache. This could for instance happen after an emergency request + from the child, who has suffered a key compromise, and has decided to + prefer being unsecured over either dropping of the Internet or being + exposed to have verifiable secure info added by the key-compromiser + to their zone information. + + +4. Scheduled key rollover + When the signatures, produced by the key to be rolled over, are all + in one zone file, there are two parties involved. Let us look at an + example where a TLD rolls over its zone KEY. The new key needs to be + signed with the root's key before it can be used to sign the TLD zone + and the zone KEYs of the TLD's children. The steps that need to be + taken by TLD and root are: + - the TLD adds the new key to its KEY set in its zonefile. This + zone and KEY set are signed with the old zone KEY + - then the TLD signals the parent + - the root copies the new KEY set, consisting of the both new and + the old key, in its zonefile, resigns it and signals the TLD + - the TLD removes the old key from its KEY set, resigns its zone + with the new KEY, and signals the the root + - the root copies the new KEY set, now consisting of the new key + only, and resigns it + + Note that this procedure is immune to fake signals and spoofing + attacks (as long as there is no key compromise): + - on a fake signal either way the action becomes a null-action as + the new KEY set is identical to the existing one. + - a spoofed new KEY set will not validate with the existing KEY + that the parent holds. + + +5. Unscheduled key rollover + + + + Gieben Expires September 2001 [Page 6] + +Internet Draft Parent Stores Zone KEYS March 2001 + + Although nobody hopes that this will ever happen, we must be able to + cope with possible key compromises. When such an event occurs, an + immediate keyrollover is needed and must be completed in the shortest + possible time. With two parties involved, it will still be awkward, + but not impossible to update two zonefiles overnight. "Out-of-band" + communication between the two parties will be necessary, since the + compromised old key can not be trusted. We think that between two + parties this is doable, but this complicated procedure [5] is beyond + the scope of this document. + + An alternative to an emergency key-rollover is becoming unsecured as + an emercengy measure. This has already been mentioned above in + section 3.1. This only involves an emergency change in the parents + zonefile (deleting the child's zone KEY), and allows the child and + its underlying zones time to clean up before becoming secured again, + without dropping from the Internet or being exposed to having secured + but false zone information. + + +6. Zone resigning + Resigning a TLD is necessary before the current signatures expire. + When all SIGs (produced by the TLD's zone KEY) and the child KEY + records, are kept in the TLD's zonefile, such a resign session is + trivial, as only one party (the TLD) and one zonefile are involved. + + +7. Consequences for KEY and NXT records + There are two reasons to have of the child's zone KEY not only at the + parent but also in the child's own zonefile: + 1. to facilitate a key-rollover + 2. to prevent local lookups for local information to suffer + from possible loss of access to its outside parent + + To cope with 1, secure aware resolvers MUST be aware that during a + key-rollover there may be a conflict, and that in that case the + parent always holds the active KEY set. To cope with 2, the local + resolver/caching forwarder should be preconfigured with the zone-KEY + and thus looks at its own zone as were it a secure entry-point. For + both things to work, the zone-KEY set must be selfsigned in the child + zonefile. + +7.1. KEY bit in NXT records + RFC 2535 [3], section 5.2 states: + + " The NXT RR type bit map format currently defined is one bit per + RR type present for the owner name. A one bit indicates that at + least one RR of that type is present for the owner name. A zero + indicates that no such RR is present. [....] " + + As the zone KEY is present in a child zone, and signed by the + zone KEY (thus selfsigned), the definition of NXT RR type bit states + + + + Gieben Expires September 2001 [Page 7] + +Internet Draft Parent Stores Zone KEYS March 2001 + + in RFC 2535 [3], section 5.2 that the KEY bit must be set. We do not + see a compelling reason to change this default behavior. + +7.2. Authority of KEY records + The parent of a zone generates the signature for the key belonging to + that zone. By making that signature available the parent publicly + states that the child zone is trustworthy: when it comes to security + in DNSSEC the parent is more authoritative than the child. + + From this we conclude that a parent zone MUST set the authority bit + to 1 and child zones MUST set this bit to 0 when dealing with KEYs + from that child zone.This also causes resolvers to pick up and cache + the right KEY set, in case it finds conflicting KEY sets during a + key-rollover. + + Some zones have no parent to make it authoritatively secure, for + instance, the root. To be secure anyway it must be defined a secure + entry point. If a resolver knows that a secure entry point is a + secure entry point it must have its key preconfigured. There is no + need for a parent in this scenario, because the resolver itself can + check the security of that zone. A interesting consequence of this is + that nobody is authoritative for a key belonging to a secure entry + point. This authority must established via some out of band + mechanism, like publishing it in a newspaper. + +7.3. Selecting KEY sets + As the zone KEY set is present in two places, there may be a + possibility to find conflicting KEY sets, and this will at least + really happen during a key-rollover. + + With one exception, a resolver MUST always select the KEY set from + the parent in case of a conflict, as this is the active KEY set. For + this reason, the parent sets the AA-bit on requests, while the child + does not. + + The one exception is when a resolver regards the child's zone as a + secure-entry point, in which case it has the zone KEY preconfigured. + In other words: a preconfigured KEY has even more authority then what + a parent says. Specifying a zone as a secure entry-point makes sense + for a local resolver in its own local zone. + + +8. The zone KEY and local KEY records. + It must be recognized that the zone KEY RR, which is signed by a + non-local organisation, is something special. The external signature + over the public part of the key provides the local zone-administrator + with the authority to use the corresponding private part to sign + everything local, and thus to make his/her own zone secure. Please + also note that the external signer, and NOT the local zone is + authoritative for the zone KEY RRset. + + + + + Gieben Expires September 2001 [Page 8] + +Internet Draft Parent Stores Zone KEYS March 2001 + + Part of the RRs that the zone-administrator may wish to sign are KEY + RRs for local use, for instance for IPSEC. + + To make sure, that the local zone is authoritative for its own local + KEY RRs, and that they get not exported and signed externally, these + local KEY records SHOULD not be part of the zone KEY RRset. + Therefore, they SHOULD be placed under a label in the zonefile, f.i. + keys.child.parent. + + Besides being kept clear of local KEY records, the zone KEY RRset + SHOULD also be kept clear of any other obsolete or otherwise not + strictly needed KEY records, because this increases the number of + possible key compromise attacks and also increases the size of the + parents zone file unnecessarily. + + In other words: the KEY RRset with the toplevel label of a zone + SHOULD only contain its active zone KEY, unless a key-rollover is in + progress. During a keyrollover a new KEY RR must be added to this + RRset. Once the new KEY becomes the active zone KEY, the old KEY + becomes obsolete and SHOULD be removed as soon as practically + possible. + + +9. Security Considerations + This document addresses the operational difficulties that arise if + DNSSEC is deployed as it stands now, with the child's zone KEY not + stored at the parent. By putting that key in the parent's zone the + communication between the two is kept to a minimum thus reducing the + risk of errors. All security considerations from RFC 2535 apply. + + +Authors' Addresses + + R. Gieben T. Lindgreen + Stichting NLnet Labs Stichting NLnet Labs + Kruislaan 419 Kruislaan 419 + 1098 VA Amsterdam 1098 VA Amsterdam + miek@nlnetlabs.nl ted@nlnetlabs.nl + + +References + + [1] Lewis, E. "DNS Security Extension Clarification on Zone + Status", RFC 3090 + www.ietf.org/rfc/rfc3090.txt + [2] Bradner, S. "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119 + www.ietf.org/rfc/rfc2119.txt + [3] Eastlake, D. "DNS Security Extensions", RFC 2535 + www.ietf.org/rfc/rfc2535.txt + [4] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security + + + + Gieben Expires September 2001 [Page 9] + +Internet Draft Parent Stores Zone KEYS March 2001 + + Key Rollover" + www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt + [5] Gieben, R. "Chain of trust" + secnl.nlnetlabs.nl/thesis/thesis.html + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished + to others, and derivative works that comment on or otherwise explain + it or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not + be revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on + an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.