diff options
Diffstat (limited to 'doc/draft/draft-ietf-dnsop-interim-signed-root-01.txt')
| -rw-r--r-- | doc/draft/draft-ietf-dnsop-interim-signed-root-01.txt | 769 |
1 files changed, 769 insertions, 0 deletions
diff --git a/doc/draft/draft-ietf-dnsop-interim-signed-root-01.txt b/doc/draft/draft-ietf-dnsop-interim-signed-root-01.txt new file mode 100644 index 00000000..eaa6b8d9 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-interim-signed-root-01.txt @@ -0,0 +1,769 @@ + + +Internet Draft Johan Ihr‰n +draft-ietf-dnsop-interim-signed-root-01.txt Autonomica +February 2003 +Expires in six months + + + An Interim Scheme for Signing the Public DNS Root + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + 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. + + +Abstract + + This memo documents a proposed mechanism for a first stage of a + transition from an unsigned DNS root to a signed root, such that + the data in the root zone is accompanied by DNSSEC signatures to + allow validation. + + The underlying reason for signing the root zone is to be able to + provide a more secure DNS hierarchy, where it is possible to + distinguish false answers from correct answers. + + For the special case of the DNS root zone, an interim scheme is + proposed. This scheme is mostly aimed at securing the root zone + itself for technical and operational reasons, and to give + operational experience of DNSSEC. + + +1. Terminology + + The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", + and "MAY" in this document are to be interpreted as described in + RFC 2119. + + The term "zone" refers to the unit of administrative control in the + Domain Name System. "Name server" denotes a DNS name server that is + authoritative (i.e. knows all there is to know) for a DNS zone, + typically the root zone. A "resolver", finally, is a DNS "client", + i.e. an entity that sends DNS queries to authoritative nameservers + and interpret the results. + + +2. Motivation for signing the DNS root + + In the special case of the root zone there are very strong reasons + to take a slow and conservative approach to any changes with + operational impact. Signing the root is such a change. + + DNSSEC[RFC2535, RFC3090] has been in development for a number of + years now and still has not reached the point where the last flag + day is behind us. + + However, during the years of DNSSEC development and refinement + [RFC2930, RFC3007, RFC3008, RFC3110, RFC3225, RFC3226, AD-secure, + Opt-in, Wild-card-optimize], the Internet has matured and more and + more businesses and other organizations have become dependent on + the stability and constant availability of the Internet. + + It is therefore prudent to do everything in our power to ensure + that the DNS infrastructure works as well as possible and, when + appropriate and possible, adding enhancements and functionality. + + The time is now right for yet another step of improvement by + signing the root zone. By doing that any Internet user that so + wishes will obtain the ability of verifying responses received from + the root nameservers. + + Since this is new operational ground the objective is not maximum + security but rather an "Internet-wide" controlled experiment with a + signed root zone, where the trade off is that we utilize the fact + that there are operators in place that can help even though they + are not sufficiently staffed to do off-line signing in a 24x7 + mode. For this reason it is fully possible to even do automatic + signing, since the purpose is to ensure that DNSSEC works + operationally with a signed root zone and gain experience from the + exercise. + + It should be pointed out, however, that the experimental part is + only the added DNSSEC records. The traditional records in the root + zone remain unchanged and the new records will only be visible to + DNSSEC-aware resolvers that explicitly ask to see these new + records. + + +2.1. Motivation for signing the root zone now + + The reason DNSSEC is not yet widely deployable is that the problem + of key management remains unsolved, especially where communication + between the zone administrators for a parent zone and child zone is + required. + + However, during the past year a solution to this problem has been + found (in the form of a new record type, DS aka Delegation Signer) + [DS], discussed, implemented and tested. Therefore, it is finally + reasonable to consider DNSSEC deployment to be a real possibility + within the next 12 months. + + In the case of the root zone the particular importance of managing + the transition with zero operational mistakes is a strong reason to + separate the signing of the zone itself, with the associated key + management issues, from the future management of signed delegations + (of top level domains). + + Although support for Delegation Signer has been implemented and + tested it is not yet generally available except experimentally. For + this reason signed delegations for productions zones will have to + wait a bit longer. Furthermore, it will take some time to ensure + that the entire RSS aka Root Server System is capable of supporting + the protocol changes that accompany the new support for Delegation + Signer. + + By signing now it will be possible to work through the operational + issues with signing the zone itself without at the same time having + to manage the additional complexity of signed delegations. Also, by + explicitly not supporting any signed delegations, it is also + possible to recover in a graceful way should new operational + problems turn up. + + Because of these operational and technical issues there is a + "window of opportunity" to sign the root zone before the status of + implementation of "full DNSSEC", including Delegation Signer + support, change to "generally available", thereby increasing the + pressure for signed delegations from the root zone. + + +3. Trust in DNSSEC Keys + + In the end the trust that a validating resolver will be able to put + in a key that it cannot validate within DNSSEC will have to be a + function of + + * trust in the key issuer + + * trust in the distribution method + + * trust in extra, out-of-band verification + + For any security apex, i.e. a node in the DNS hierarchy that issues + out-of-band "trusted keys", it is of critical importance that this + function produces a positive result (i.e. the resolver gains + sufficient confidence in the keys to decide to trust them). The + particular case of the root zone is no different, although possibly + it is more crucial than many other security apexes. + + To ensure that the resulting trust is maximized it is necessary to + work with all the parameters that are available. In the case of the + key issuer there is the possibility of chosing a key issuer that + has a large "trust base" (i.e. is already trusted by a large + fraction of the resolver population). However, it is also possible + to expand the aggregated trust base by using multiple simultaneous + key issuers, as described in [Threshold-Validation]. + + Furthermore, with multiple trusted keys it will be possible for a + validating resolver to optimize for the "right compromise" between + + * maximum security (as expressed by all available signatures by all + available keys verifying correctly + + * maximum redundancy (as in the DNS lookup being validated if there + is any signature by any trusted key available) + + Without multiple, independent trusted keys the rollover operation + will always be a dangerous operation where it is likely that some + fraction of the resolver population lose their ability to verify + lookups (and hence start to fail hard). I.e. the validating + resolver will be forced to adopt the "maximum security" policy, + since there is no alternative. + + With multiple, independent trusted keys, however, it is possible to + design for improved redundancy by trusting lookups that are only + validated against a subset of the available keys. This will make + rollovers much less risky to the extent that it will be possible to + "survive" even emergency rollovers without any immediate + configuration chagnes in the validating resolver. + + +4. Interim signing of the root zone + + At present all the authoritative servers for the root zone pull the + zone from a primary master. I.e. any changes at the primary master + will propagate via NOTIFY[RFC1996] and subsequent + AXFR/IXFR[RFC1995, AXFR-clarify] to the slave servers. + + Between the primary master and the slaves transactions are signed + with TSIG[RFC2845] signatures. This mechanism is already in place, + and there is operational experience with periodic key rollover of + the TSIG keys. + + +4.1. Design philosophy + + By introducing a signing step into the distribution of the zone + file complexity is increased. To avoid introducing new single + points of failure it is therefore important to ensure that any + added or changed steps are as redundant as possible. + + The assumption is that the operators of the root servers are + trusted and that consistency of the zone among the root servers is + a crucial property that MUST be preserved in emergencies. + + To ensure that consistency is maintained new single points of + failure SHOULD NOT be introduced by the signing step. Therefore a + structure where several parties have the ability to sign the zone + is proposed. Furthermore, such a design helps avoid any individual + party becoming a de facto single zone signing authority. + + +4.2. Proposed new management structure for the root zone + + Taking into account the already existing infrastructure for + management of TSIG keys and rollover of these keys the following + structure is proposed: + + * Day-to-day signing of the root zone is performed by a subgroup of + the root server operators referred to as "signing operators". For + this task individual, per-operator, Zone Signing Keys, ZSKs, are + used. + + * The set of Zone Signing Keys are signed by several Key Signing + Keys, KSKs, at any particular time. The public part of KSKs in + use have to be statically configured as "trusted keys" in all + resolvers that want to be able to perform validation of + responses. + + * Key rollover, the operation when an old KSK is exchanged for a + new KSK, is managed with minimal overlap and on a frequent basis + of no less than three times per year per KSK. The rollover + schedule is chosen to be frequent enough to not make long-term + trust possible while being low enough to not become operationally + infeasible. + + +4.2.1. Management and distribution of the zone file + + The present, unsigned zone is published by the official slaves, the + "root nameservers", transferring the zone securely from a primary + master and subsequently using the data to respond to queries. This + mechanism is changed into: + + * The unsigned root zone is transferred securely from the primary + master to a set of "signing primaries" managed by the operators + participating in signing the zone. This is done via the + traditional mechanisms NOTIFY + AXFR/IXFR + TSIG. + + * The root nameservers change their configuration so that they + replace the present, single, primary master as the source of the + zone with a set of multiple possible "signing primaries" as + masters that provide the signed zone. + + * When a new, unsigned zone, is published by the primary master it + will automatically be transferred to the pre-signing servers. The + responsible operator will then sign the new zone and publish it + from his signing primary. Since the serial number is higher than + what the official root nameservers presently have the official + root nameservers will all transfer the zone from this source + (because of the redundant configuration with multiple possible + masters for the signed zone). + + * The operators that participate in signing rotate the signing + responsibility among themselves. Should the responsible operator + be unable to do this for any reason then any of the others are + able to do the signing instead. Traceability is maintained since + the zone signing keys are individual. + + * To avoid having several "backup signing operators" possibly sign + at exactly the same time backups are allocated "time windows" + within which they are allowed to publish a signed zone. + + With N signers, each signer is assigned a unique number R in + [1..N]. + + T = 2*k*((S-R) mod N) + + T is time to wait in seconds, S current serial number. The length + of the window is k, thereby separating each signing window with + an interval where signing is not allowed. + + The constant k is used to create sufficient separation of the + signers with respect to time used to sign and time needed to + distribute the zone. A reasonable value for k would be in the + order of 1800 seconds. + + * Because the digital signatures in the signed root zone MUST NOT + expire it is necessary to ensure that the unsigned zone does + change sufficiently often to cause new signing to occur within + the validity period of the old signatures. This is most easily + accomplished by a dummy update that only increments the serial + number in the SOA record. + + This new requirement will not cause any operational problems, + since in fact the root zone is maintained this way since several + years back. + + +4.2.2. Management of the Key Signing Keys + + Key Signing Keys, KSKs, are periodically issued by a several "Key + Signing Key Holders", KSK holders, individually. These KSKs consist + of a private part that should always be kept secret and a public + part that should be published as widely as possible since it will + be used as a "trusted key" in resolver configurations. + + The public part of each KSK should be included in the keyset for + "." as described in [Threshold-Validation]. I.e. the keyset will be + the union of the public parts of all KSKs and all ZSKs, Zone + Signing Keys. + + * Each KSK holder should generate a sequence of KSKs where the + public parts will be used to include in the keyset for "." and + the private parts will be used for signing the keyset. + + * Each KSK holder should, on request from the signing operators, + send in the public part of the KSK. The union of the public parts + of KSKs and the corresponding public parts of ZSKs, as collected + by the signing operators, constitute a "keyset". + + * Each KSK holder should, on request from the signing operators, + sign the complete keyset with the private part of the associated + KSK and send in the resulting signature to the signing operators + for inclusion in the signed zone. + + +4.2.3. Management of the Zone Signing Keys and the keyset signatures + + A subgroup of the root operators that choose to participate in + signing the zone each hold an individual "Zone Signing Key", + ZSK. The subgroup of operators may include all operators, but that + is not necessary as long as a sufficient number to achieve + redundancy in "signing ability" participates. + + * The complete keyset (i.e. all the public parts of KSKs and ZSKs) + should be signed by each KSK holder individually, generating a + new signature for the keyset which is sent back to the signing + operators via an out-of-band mechanism. + + * The signing operators should verify each received signature + against the corresponding key in the keyset and, unless invalid, + accept the signature into the set of signatures associated with + this keyset as described in [Threshold-Validation]. + + * The signing operators should include one of the keysets together + with all the KSK signatures in the zone file according to an + agreed upon rotation schedule. + + +4.2.4. Management of key rollover + + The Key Signing Keys should, for this interim scheme, be relatively + short-lived and rolled over frequently. The direct intent is that + it should not be possible to put long term trust in the keys. + Therefore, by design, every resolver that chooses to configure + these as "trusted keys" (to be able to validate lookups) will have + to change the configuration periodically. + + This is, after all, only an interim method of root zone signing. + + * Key rollover is executed by changing from one signed keyset to + another. I.e. from a keyset signed by one set of KSKs to a keyset + signed by a partially different set of KSKs. By not rolling all + the KSKs at the same time redundancy is improved. + + * Technically the signing operators are able to initiate key + rollover, although except for the case of a suspected key + compromise (with subsequent immediate key rollover) this ability + should only be used according to an established schedule. + + * New Key Signing Keys will be published as widely as possible, + however exactly how and where to publish the keys is by itself an + area where it is necessary to acquire more experience. Especially + for the case of individual hosts and other devices this will be a + significant issue to deal with. + + * Since the keys expire within a few months the aim is to make it + as difficult as possible to configure an interim key and then + forget about it long enough to still trust an interim key when a + long term design for signing the root zone emerges. + + +4.2.5. The role of the KSK holder + + With multiple KSKs it is possible to have multiple individual KSK + holders. Each will perform the role of authenticating the identity + of the signing operators, through the act of signing the keyset + that includes the operator Zone Signing Keys. + + The chain of authority that defines editorial control over the zone + contents is entirely separate from this and is in no way affected. + + I.e. the KSK holder is only asserting identity of the holders of + ZSKs and does not in any way take part in issues regarding zone + contents. In this respect the role of a KSK holder is much like + that of a public notary or a Certificate Authority. + + The primary function that the KSK holder is performing is adding + trust to the authenticity of the Zone Signing Keys and this trust + has to be propagated down to validating resolvers. Therefore an + obvious key characteristic of a KSK holder is that it should + already be trusted by as large a fraction of the "resolver + population" as possible. In this document that fraction is referred + to as the "trust base" of a KSK holder. + + The key characteristics of a KSK holder will be entities that + + * already are trusted by some part of the "resolver population", + i.e. have a "trust base" + + * are multiple entities that complement each other (so that the + aggregated "trust base" grows) + + * are willing to help work on methods for distributing their + trusted keys to the resolvers (hard problem) + + The requirement on the individual KSK holders is that they must be + able to + + * establish a secure out-of-band communication path in + collaboration with the signing operators which will be used for + authenticated exchange of the unsigned keyset and generated + signatures + + * periodically generate strong keys using a good random number + generator + + * manage their keys (i.e. use them for signing the operator keyset + and keeping the private key appropriately secret) + + +4.2.5.6. Suggestions for KSK holders + + Regional Internet Registries, RIRs, are suggested to be one + suitable choice of KSK holders. However, since every KSK holder + will act on its own there is no requirement that all RIRs + participate, although more than one would be good. Other suitable + KSK holders may exist and as long as the requirements are met more + would be better within the packe size limitations that are + discussed in [Threshold-Validation]. + + The basis of the suggestion of RIRs is + + * their neutrality + + * their proven record of service to the Internet community + + * that they don't have the domain name system as their primary + field of activity + + * their geographical diversity + + * the fact that they are, by definition, not a single entity, but + rather a collective of organizations. + + +5. Risk Analysis + + A change in the management of the root zone is always a risk. But + that is all the more reason to do it carefully and after due + consideration, rather than as a result of an immediate and urgent + need. The gains of a signed root zone have to be judged against the + added complexity of the signing step. + + However, added complexity, in one form or another, is basically + unavoidable. It is possible to argue for or against implementation + details, but in the end the benefits of a signed root will have to + be compared against some amount of added complexity. If the cost or + risk of this complexity is deemed to be too high, then it is not + possible to sign the DNS root zone. If that is the conclusion; then + it is obviously important to reach it as soon as possible. + + The same is true for the need for operational experience with a + signed root zone. There is no method of acquiring this experience + except by signing the root zone, so that is what is being proposed. + + Some identified scenarios: + + +5.1. What will the consequences of a signed root zone be for old + resolver software? + + Nameservers that are authoritative for signed zones only give out + these signatures when explicitly asked for them. Therefore, the + presence of signatures in the root zone will not have any impact at + all on the majority of resolvers on the Internet that does not + validate lookups. + + +5.2. What happens if a signing operator fails to sign the zone on + time? + + Literally nothing. I.e. the root zone that is published will be the + version prior to the last change. This is not believed to be a + major problem, since all changes to the data in the root zone are + characterized by long overlaps in time. Furthermore every change is + preceded by an administrative process that takes several days or + even weeks. Because of this, a failure to install a new version of + the root zone for even so long as a day will not noticeably change + the turn-around time for changes in the root zone. + + +5.3. What happens if several signing operators by mistake sign the + same version? + + Literally nothing. One signing operator will be first, according to + the mechanism designed to separate the different backup signing + operators described in 3.3.1. The signed zone published by this + operator will be the version of the signed root zone that all the + root nameservers pick up. + + When the second signing operator signs the zone the serial number + in the zone will be unchanged, and therefore the root nameservers + will not pick this zone up but instead stay with the first version. + + +5.4. What happens if the unsigned zone is compromised between the + primary master and the signing primaries? + + This is basically the same threat as the zone being compromised + between the primary master and the root servers in the traditional + unsigned case. To guard against this possibility every zone + transfer is already protected by a TSIG signature. + + Because of this the root zone file cannot get transferred to the + signing primaries unless the transaction signature matches, thereby + proving that the zone contents are uncompromised. The consequence + is that if the zone transfers are somehow compromised in transit, + they will not get signed and therefore the published root zone will + remain the signed version of the last uncompromised transfer. + + +5.5. What are the security implications for the new "signing + primaries"? Will they not have to be as secure as the primary + master is now? + + Yes. However, the entire root server system is based upon trust, + i.e. the entire Internet is trusting the present root server system + because there is no alternative to doing that. This proposal is not + about changing the need for trust in the root server system. It is + about providing a method of determining authenticity of data, + something that is presently missing. + + The root operators are already trusted to provide a root server + system based upon secure servers lacking validation mechanisms. It + is therefore a bit difficult to argue for not trusting them to + provide an improved system that adds exactly the lacking validation + mechanisms on a basis of not trusting them to secure the servers + involved. In both cases trust is involved, the difference is that + in the latter case validation is possible. + + Furthermore, the proposed signing primaries will not need to have + publicly known addresses (just as the present primary master is not + publicly known), nor will they need to be able to communicate with + anyone outside the well defined set of servers that are part of the + root server system. Because of this it will be significantly easier + to secure the signing primaries than the already present task of + securing the DNS root nameservers. + + +5.6. What happens if a Zone Signing Key is compromised? + + If this happens it is necessary to do an emergency rollover of the + keyset that includes the compromised key. I.e. the old keyset (and + its signatures) is replaced by a new keyset containing new ZSKs but + the same, uncompromised, KSKs and its signatures. Then the root + zone is re-signed using one of the new Zone Signing Keys. + + This problem is not unique to a signed root zone, it is inherent in + any activity involving cryptographic keys. + + Also note that there will be no need to change any configuration in + the resolver end. The rollover is an entirely atomic operation + inside the management structure of the root zone. + + +5.7. What happens if a Key Signing Key is compromised? + + Depending on the trust model used by individual validating + resolvers one of two things will happen. + + Resolvers that through local policy have chosen to trust this KSK + alone will need to change their configuration to instead trust + other KSKs, either available from other KSK holders or a new + trusted key made available by the same KSK holder that held the + compromised key. + + Resolvers that have chosen to require multiple signatures by KSKs + for the root zone will not have to do any emergency key rollover at + all, since validation of lookups will still work, based upon the + integrity of the other trusted keys that have not been compromised. + + In the management end it is necessary to do an emergency rollover + of the keyset including the compromised key and the suggested + method is by switching to a keyset that only changes the + compromised KSK and the ZSKs and keeps all other KSKs. Such keysets + should be prepared and signed in advance. + + The new signed keyset is added to the root zone and then the zone + is re-signed using one of the new Zone Signing Keys. In this case, + since a Key Signing Key is changed, every resolver that choose to + trust that KSK holder will over time have to configure the new key + to be able to validate lookups. + + This problem is not unique to a signed root zone, it is inherent in + any activity involving cryptographic keys. + + +5.8. Does the out-of-band communication between the signing operators + and the RIRs holding the key-signing keys add a new failure mode? + + Yes. The traditional DNSSEC design assumes that (for an arbitrary + zone, not particularly for the root zone) the key-signing key is + managed by the same entity that manages the operator keys and hence + no communication issue exists. + + In this case it is important that the signing operators do not hold + the responsibility for the key-signing keys. The root server + operators should only act as a "publishing service" for the root + zone contents, not as the entity that verifies correctness of the + published data. + + However, apart from established secure methods of out-of-band + communication being available, there is also the very real + possibility of managing these exchanges with actual eye-to-eye + contact. Representatives for the RIRs and the root server operators + already meet on a regular basis during IETF meetings and the + different RIR meetings. + + +6. Security Considerations + + Signing the DNS root zone is all about security. A signed root zone + may aid applications and organizations all over the Internet in + improving their security by enabling validation of DNS lookups. + + Signing the root zone does add a new management step and therefore + it is important to ensure that possible failures in this management + step does not leave the published root zone in a state that is + actually worse than the original unsigned state. + + The various failure modes that have been identified all show this + property of not being any worse than the unsigned case. + + There is however one scenario that changes drastically with the + proposed distributed signing scheme and that is the consequences of + one signing operator intentionally changing the contents of the + root zone prior to the actual signing. In the unsigned case this + will cause the root zone to become inconsistent (i.e. the responses + vary depending upon which server it comes from), while in the + signed case the root zone will remain consistent but with erroneous + data in it. + + It is my belief (this is impossible to prove) that the risk of + human error among the operators, however small, is still far + greater than the risk of willful misconduct. Therefore, the + proposed design that enforces consistency among the roots, is + actually also an improvement in stability and security. + + Se further section 4 for a more complete risk analysis. + + +7. IANA Considerations + + NONE. + + +8. References + +8.1. Normative. + + [RFC2535] Domain Name System Security Extensions. D. Eastlake. + March 1999. + + [RFC3090] DNS Security Extension Clarification on Zone Status. + E. Lewis. March 2001. + + [RFC1995] Incremental Zone Transfer in DNS. M. Ohta. August 1996. + + [RFC1996] A Mechanism for Prompt Notification of Zone Changes + (DNS NOTIFY). P. Vixie. August 1996. + + [RFC2845] Secret Key Transaction Authentication for DNS (TSIG). + P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington. + May 2000. + +8.2. Informative. + + [RFC2930] Secret Key Establishment for DNS (TKEY RR). D. Eastlake. + September 2000. + + [RFC3007] Secure Domain Name System (DNS) Dynamic Update. + B. Wellington. November 2000. + + [RFC3008] Domain Name System Security (DNSSEC) Signing Authority. + B. Wellington. November 2000. + + [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System + (DNS). D. Eastlake 3rd. May 2001. + + [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. + December 2001. + + [RFC3226] DNSSEC and IPv6 A6 aware server/resolver message size + requirements. O. Gudmundsson. December 2001. + + [Delegation-Signer] Delegation Signer Resource Record. + O. Gudmundsson. October 2002. Work In Progress. + + [AXFR-clarify] draft-ietf-dnsext-axfr-clarify-NN.txt DNS Zone + Transfer Protocol Clarifications. A. Gustafsson. March + 2002. Work In Progress. + + [AD-secure] draft-ietf-dnsext-ad-is-secure-NN.txt Redefinition of + DNS AD bit. B. Wellington, O Gudmundsson. June 2002. + Work In Progress. + + [Opt-In] draft-ietf-dnsext-dnssec-opt-in-NN.txt DNSSEC Opt-In + R. Arends, M Kosters, D. Blacka. June 2002. Work In + Progress. + + [Wild-card-optimize] draft-olaf-dnsext-dnssec-wildcard- + optimization-NN.txt DNSSEC Wildcard optimization. + O. Kolkman, J. Ihren, R. Arends. September 2002. + Work In Progress. + + [Threshold-Validation] + draft-ihren-dnsop-threshold-validation-00.txt Threshold + validation: A Mechanism for Improved Trust and Redundancy + for DNSSEC Keys. J. Ihren. February 2003. Work In + Progress. + +9. Acknowledgments. + + To help me produce this document I have received lots and lots of + comments from many people around the Internet with suggestions for + lots and lots sorely needed improvements. Among the folks who + helped out are, in no particular order: Paul Vixie, Bill Manning, + Ôlafur Gumundsson, Rob Austein, Patrik F„ltstr÷m, Olaf Kolkman, + Harald Alvestrand, Suzanne Woolf, John M. Brown, Lars-Johan Liman + and M…ns Nilsson. + + +10. Authors' Address + +Johan Ihr‰n +Autonomica AB +Bellmansgatan 30 +SE-118 47 Stockholm, Sweden +johani@autonomica.se |