draft-ihren-dnsext-threshold-validation-00.txt

bind 9.3结合mysql数据库

Internet Draft                                          Johan Ihren
draft-ihren-dnsext-threshold-validation-00.txt          Autonomica
February 2003
Expires in six months


                        Threshold Validation: 

	 A Mechanism for Improved Trust and Redundancy for DNSSEC Keys


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 proposal for a different method of validation
   for DNSSEC aware resolvers. The key change is that by changing from
   a model of one Key Signing Key, KSK, at a time to multiple KSKs it
   will be possible to increase the aggregated trust in the signed
   keys by leveraging from the trust associated with the different
   signees. 

   By having multiple keys to chose from validating resolvers get the
   opportunity to use local policy to reflect actual trust in
   different keys. For instance, it is possible to trust a single,
   particular key ultimately, while requiring multiple valid
   signatures by less trusted keys for validation to succeed.
   Furthermore, with multiple KSKs there are additional redundancy
   benefits available since it is possible to roll over different KSKs
   at different times which may make rollover scenarios easier to
   manage.

Contents

	1. Terminology
	2. Introduction and Background

	3. Trust in DNSSEC Keys
	3.1. Key Management, Split Keys and Trust Models
	3.2. Trust Expansion: Authentication versus Authorization

	4. Proposed Semantics for Signing the KEY Resource Record 
           Set
	4.1. Packet Size Considerations

	5. Proposed Use of Multiple "Trusted Keys" in a Validating 
           Resolver
	5.1. Not All Possible KSKs Need to Be Trusted
	5.2. Possible to do Threshold Validation
	5.3. Not All Trusted Keys Will Be Available

	6. Additional Benefits from Having Multiple KSKs
	6.1. More Robust Key Rollovers
	6.2. Evaluation of Multiple Key Distribution Mechanisms

	7. Security Considerations
	8. IANA Considerations.
	9. References
	9.1. Normative.
	9.2. Informative.
	10. Acknowledgments.
	11. Authors' Address


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", is a DNS "client", i.e. an
   entity that sends DNS queries to authoritative nameservers and
   interpret the results. A "validating resolver" is a resolver that
   attempts to perform DNSSEC validation on data it retrieves by doing
   DNS lookups.


2. Introduction and Background

   From a protocol perspective there is no real difference between
   different keys in DNSSEC. They are all just keys. However, in
   actual use there is lots of difference. First and foremost, most
   DNSSEC keys have in-band verification. I.e. the keys are signed by
   some other key, and this other key is in its turn also signed by
   yet another key. This way a "chain of trust" is created. Such
   chains have to end in what is referred to as a "trusted key" for
   validation of DNS lookups to be possible. 

   A "trusted key" is a the public part of a key that the resolver
   acquired by some other means than by looking it up in DNS. The
   trusted key has to be explicitly configured.

   A node in the DNS hierarchy that issues such out-of-band "trusted
   keys" is called a "security apex" and the trusted key for that apex
   is the ultimate source of trust for all DNS lookups within that
   entire subtree.

   DNSSEC is designed to be able to work with more than on security
   apex. These apexes will all share the problem of how to distribute
   their "trusted keys" in a way that provides validating resolvers
   confidence in the distributed keys. 

   Maximizing that confidence is crucial to the usefulness of DNSSEC
   and this document tries to address this issue.


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, aka the KSK holder

	    * trust in the distribution method

	    * trust in extra, out-of-band verification

   The KSK holder needs to be trusted not to accidentally lose private
   keys in public places. Furthermore it needs to be trusted to
   perform correct identification of the ZSK holders in case they are
   separate from the KSK holder itself.

   The distribution mechanism can be more or less tamper-proof. If the
   key holder publishes the public key, or perhaps just a secure
   fingerprint of the key in a major newspaper it may be rather
   difficult to tamper with. A key acquired that way may be easier to
   trust than if it had just been downloaded from a web page.

   Out-of-band verification can for instance be the key being signed
   by a certificate issued by a known Certificate Authority that the
   resolver has reason to trust.

3.1. Simplicity vs Trust 

   The fewer keys that are in use the simpler the key management
   becomes. Therefore increasing the number of keys should only be
   considered when the complexity is not the major concern. A perfect
   example of this is the distinction between so called Key Signing
   Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
   overall complexity but simplifies real life operations and was an
   overall gain since operational simplification was considered to be
   a more crucial issue than the added complexity.

   In the case of a security apex there are additional issues to
   consider, among them

      * maximizing trust in the KSK received out-of-band

      * authenticating the legitimacy of the ZSKs used

   In some cases this will be easy, since the same entity will manage
   both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
   similar to a self-signed certificate). In some environments it will
   be possible to get the trusted key installed in the resolver end by
   decree (this would seem to be a likely method within corporate and
   government environments).

   In other cases, however, this will possibly not be sufficient. In
   the case of the root zone this is obvious, but there may well be
   other cases.

3.2. Expanding the "Trust Base"

   For a security apex where the ZSKs and KSK are not held by the same
   entity the KSK will effectively authenticate the identity of
   whoever does real operational zone signing. The amount of trust
   that the data signed by a ZSK will get is directly dependent on
   whether the end resolver trusts the KSK or not, since the resolver
   has no OOB access to the public part of the ZSKs (for practical
   reasons).

   Since the KSK holder is distinct from the ZSK holder the obvious
   question is whether it would then be possible to further improve
   the situation by using multiple KSK holders and thereby expanding
   the trust base to the union of that available to each individual
   KSK holder. "Trust base" is an invented term intended to signify
   the aggregate of Internet resolvers that will eventually choose to
   trust a key issued by a particular KSK holder.

   A crucial issue when considering trust expansion through addition
   of multiple KSK holders is that the KSK holders are only used to
   authenticate the ZSKs used for signing the zone. I.e. the function
   performed by the KSK is basically:

   	     "This is indeed the official ZSK holder for this zone,
   	     I've verified this fact to the best of my abilitites."

   Which can be thought of as similar to the service of a public
   notary. I.e. the point with adding more KSK holders is to improve
   the public trust in data signed by the ZSK holders by improving the
   strength of available authentication. 

   Therefore adding more KSK holders, each with their own trust base,
   is by definition a good thing. More authentication is not
   controversial. On the contrary, when it comes to authentication,
   the more the merrier.

   
4. Proposed Semantics for Signing the KEY Resource Record Set

   In DNSSEC according to RFC2535 all KEY Resource Records are used to
   sign all authoritative data in the zone, including the KEY RRset
   itself, since RFC2535 makes no distinction between Key Signing
   Keys, KSK, and Zone Signing Keys, ZSK.  With Delegation Signer [DS]
   it is possible to change this to the KEY RRset being signed with
   all KSKs and ZSKs but the rest of the zone only being signed by the
   ZSKs.

   This proposal changes this one step further, by recommending that
   the KEY RRset is only signed by the Key Signing Keys, KSK, and
   explicitly not by the Zone Signing Keys, ZSK. The reason for this
   is to maximize the amount of space in the DNS response packet that
   is available for additional KSKs and signatures thereof. The rest
   of the authoritative zone contents are as previously signed by only
   the ZSKs.

4.1. Packet Size Considerations

   The reason for the change is to keep down the size of the aggregate
   of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
   perform validation of data below a security apex. For DNSSEC data
   to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
   set, and therefore the allowed packet size can be assumed to be at
   least the EDNS0 minimum of 4000 bytes.

   When querying for KEY + SIG(KEY) for "." (the case that is assumed
   to be most crucial) the size of the response packet after the
   change to only sign the KEY RR with the KSKs break down into a
   rather large space of possibilities. Here are a few examples for
   the possible alternatives for different numbers of KSKs and ZSKs
   for some different key lengths (all RSA keys, with a public
   exponent that is < 254). This is all based upon the size of the
   response for the particular example of querying for