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

bind 9.3结合mysql数据库

	". KEY IN"

   with a response of entire KEY + SIG(KEY) with the authority and
   additional sections empty:

   	      ZSK/768 and KSK/1024   (real small)
	      Max 12 KSK +  3 ZSK  at 3975
	          10 KSK +  8 ZSK  at 3934
		   8 KSK + 13 ZSK  at 3893

	      ZSK/768 + KSK/1280
	      MAX 10 KSK +  2 ZSK  at 3913
	           8 KSK +  9 ZSK  at 3970
                   6 KSK + 15 ZSK  at 3914

	      ZSK/768 + KSK/1536
	      MAX  8 KSK +  4 ZSK  at 3917
                   7 KSK +  8 ZSK  at 3938
                   6 KSK + 12 ZSK  at 3959

              ZSK/768 + KSK/2048
              MAX  6 KSK +  5 ZSK  at 3936
                   5 KSK + 10 ZSK  at 3942

              ZSK/1024 + KSK/1024
              MAX 12 KSK +  2 ZSK  at 3943
                  11 KSK +  4 ZSK  at 3930
                  10 KSK +  6 ZSK  at 3917
                   8 KSK + 10 ZSK  at 3891

              ZSK/1024 + KSK/1536
              MAX  8 KSK +  3 ZSK  at 3900
                   7 KSK +  6 ZSK  at 3904
                   6 KSK +  9 ZSK  at 3908

              ZSK/1024 + KSK/2048
              MAX  6 KSK +  4 ZSK  at 3951
                   5 KSK +  8 ZSK  at 3972
                   4 KSK + 12 ZSK  at 3993

   Note that these are just examples and this document is not making
   any recommendations on suitable choices of either key lengths nor
   number of different keys employed at a security apex.

   This document does however, based upon the above figures, make the
   recommendation that at a security apex that expects to distribute
   "trusted keys" the KEY RRset should only be signed with the KSKs
   and not with the ZSKs to keep the size of the response packets
   down.


5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver

   In DNSSEC according to RFC2535[RFC2535] validation is the process
   of tracing a chain of signatures (and keys) upwards through the DNS
   hierarchy until a "trusted key" is reached. If there is a known
   trusted key present at a security apex above the starting point
   validation becomes an exercise with a binary outcome: either the
   validation succeeds or it fails. No intermediate states are
   possible.

   With multiple "trusted keys" (i.e. the KEY RRset for the security
   apex signed by multiple KSKs) this changes into a more complicated
   space of alternatives. From the perspective of complexity that may
   be regarded as a change for the worse. However, from a perspective
   of maximizing available trust the multiple KSKs add value to the
   system.

5.1. Possible to do Threshold Validation

   With multiple KSKs a new option that opens for the security
   concious resolver is to not trust a key individually. Instead the
   resolver may decide to require the validated signatures to exceed a
   threshold. For instance, given M trusted keys it is possible for
   the resolver to require N-of-M signatures to treat the data as
   validated.

   I.e. with the following pseudo-configuration in a validating
   resolver

   	security-apex "." IN {
	   keys { ksk-1 .... ;
      	          ksk-2 .... ;
	          ksk-3 .... ; 
		  ksk-4 .... ;
		  ksk-5 .... ;
	        };
	   validation {
	      # Note that ksk-4 is not present below
	      keys { ksk-1; ksk-2; ksk-3; ksk-5; }; 
              # 3 signatures needed with 4 possible keys, aka 75%
              needed-signatures 3;
           };
	};

   we configure five trusted keys for the root zone, but require two
   valid signatures for the top-most KEY for validation to
   succeed. I.e.  threshold validation does not force multiple
   signatures on the entire signature chain, only on the top-most
   signature, closest to the security apex for which the resolver has
   trusted keys.		    

5.2. Not All Trusted Keys Will Be Available

   With multiple KSKs held and managed by separate entities the end
   resolvers will not always manage to get access to all possible
   trusted keys. In the case of just a single KSK this would be fatal
   to validation and necessary to avoid at whatever cost. But with
   several fully trusted keys available the resolver can decide to
   trust several of them individually. An example based upon more
   pseudo-configuration:

   	security-apex "." IN {
	   keys { ksk-1 .... ;
      	          ksk-2 .... ;
	          ksk-3 .... ; 
		  ksk-4 .... ;
		  ksk-5 .... ;
	        };
	   validation {
	      # Only these two keys are trusted independently
	      keys { ksk-1; ksk-4; }; 
              # With these keys a single signature is sufficient
	      needed-signatures 1;
           };
	};

   Here we have the same five keys and instruct the validating
   resolver to fully trust data that ends up with just one signature
   from by a fully trusted key.

   The typical case where this will be useful is for the case where
   there is a risk of the resolver not catching a rollover event by
   one of the KSKs. By doing rollovers of different KSKs with
   different schedules it is possible for a resolver to "survive"
   missing a rollover without validation breaking. This improves
   overall robustness from a management point of view.

5.3. Not All Possible KSKs Need to Be Trusted

   With just one key available it simply has to be trusted, since that
   is the only option available. With multiple KSKs the validating
   resolver immediately get the option of implementing a local policy
   of only trusting some of the possible keys.

   This local policy can be implemented either by simply not
   configuring keys that are not trusted or, possibly, configure them
   but specify to the resolver that certain keys are not to be
   ultimately trusted alone.


6. Additional Benefits from Having Multiple KSKs

6.1. More Robust Key Rollovers

   With only one KSK the rollover operation will be a delicate
   operation since the new trusted key needs to reach every validating
   resolver before the old key is retired. For this reason it is
   expected that long periods of overlap will be needed.

   With multiple KSKs this changes into a system where different
   "series" of KSKs can have different rollover schedules, thereby
   changing from one "big" rollover to several "smaller" rollovers.

   If the resolver trusts several of the available keys individually
   then even a failure to track a certain rollover operation within
   the overlap period will not be fatal to validation since the other
   available trusted keys will be sufficient.

6.2. Evaluation of Multiple Key Distribution Mechanisms

   Distribution of the trusted keys for the DNS root zone is
   recognized to be a difficult problem that ...

   With only one trusted key, from one single "source" to distribute
   it will be difficult to evaluate what distribution mechanism works
   best. With multiple KSKs, held by separate entitites it will be
   possible to measure how large fraction of the resolver population
   that is trusting what subsets of KSKs.


7. Security Considerations

   From a systems perspective the simplest design is arguably the
   best, i.e. one single holder of both KSK and ZSKs. However, if that
   is not possible in all cases a more complex scheme is needed where
   additional trust is injected by using multiple KSK holders, each
   contributing trust, then there are only two alternatives
   available. The first is so called "split keys", where a single key
   is split up among KSK holders, each contributing trust. The second
   is the multiple KSK design outlined in this proposal.

   Both these alternatives provide for threshold mechanisms. However
   split keys makes the threshold integral to the key generating
   mechanism (i.e. it will be a property of the keys how many
   signatures are needed). In the case of multiple KSKs the threshold
   validation is not a property of the keys but rather local policy in
   the validating resolver. A benefit from this is that it is possible
   for different resolvers to use different trust policies. Some may
   configure threshold validation requiring multiple signatures and
   specific keys (optimizing for security) while others may choose to
   accept a single signature from a larger set of keys (optimizing for
   redundancy). Since the security requirements are different it would
   seem to be a good idea to make this choice local policy rather than
   global policy.

   Furthermore, a clear issue for validating resolvers will be how to
   ensure that they track all rollover events for keys they
   trust. Even with operlap during the rollover (which is clearly
   needed) there is still a need to be exceedingly careful not to miss
   any rollovers (or fail to acquire a new key) since without this
   single key validation will fail. With multiple KSKs this operation
   becomes more robust, since different KSKs may roll at different
   times according to different rollover schedules and losing one key,
   for whatever reason, will not be crucial unless the resolver
   intentionally chooses to be completely dependent on that exact key.

8. IANA Considerations.

   NONE.


9. References

9.1. Normative.

   [RFC2535] Domain Name System Security Extensions. D. Eastlake. 
	     March 1999.

   [RFC3090] DNS Security Extension Clarification on Zone Status. 
	     E. Lewis.  March 2001.


9.2. Informative.

   [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.

   [DS]      Delegation Signer Resource Record. 
	     O. Gudmundsson. October 2002. Work In Progress.

10. Acknowledgments.

   Bill Manning came up with the original idea of moving complexity
   from the signing side down to the resolver in the form of threshold
   validation. I've also had much appreciated help from (in no
   particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
   Olaf Kolkman.


11. Authors' Address
Johan Ihren
Autonomica AB
Bellmansgatan 30
SE-118 47 Stockholm, Sweden
[e-mail]