draft-ietf-dnsext-trustupdate-threshold-00.txt

bind 源码 最新实现 linux/unix/windows平台

Ihren, et al.            Expires April 18, 2005                [Page 16]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



6.  Security Considerations


6.1  Threshold-based Trust Update Security Considerations


   A clear issue for resolvers will be how to ensure that they track all
   rollover events for the zones they have configure trust anchors for.
   Because of temporary outages validating resolvers may have missed a
   rollover of a KSK.  The parameters that determine the robustness
   against failures are: the length of the period between rollovers
   during which the KSK set is stable and validating resolvers can
   actually notice the change; the number of available KSKs (i.e.  N)
   and the number of signatures that may fail to validate (i.e.  N-M).


   With a large N (i.e.  many KSKs) and a small value of M this
   operation becomes more robust since losing one key, for whatever
   reason, will not be crucial.  Unfortunately the choice for the number
   of KSKs is a local policy issue for the zone owner while the choice
   for the parameter M is a local policy issue for the resolver
   administrator.


   Higher values of M increase the resilience against attacks somewhat;
   more signatures need to verify for a rollover to be approved.  On the
   other hand the number of rollover events that may pass unnoticed
   before the resolver reaches the UNSYNCABLE state goes down.


   The threshold-based trust update intentionally does not provide a
   revocation mechanism.  In the case that a sufficient number of
   private keys of a zone owner are simultaneously compromised the the
   attacker may use these private keys to roll the trust anchors of (a
   subset of) the resolvers.  This is obviously a bad situation but it
   is not different from most other public keys systems.


   However, it is important to point out that since any reasonable trust
   anchor rollover policy (in validating resolvers) will require more
   than one RRSIG to validate this proposal does provide security
   concious zone administrators with the option of not storing the
   individual private keys in the same location and thereby decreasing
   the likelihood of simultaneous compromise.


6.2  Priming Key Security Considerations


   Since priming keys are not included in the DNSKEY RR set they are
   less sensitive to packet size constraints and can be chosen
   relatively large.  The private parts are only needed to sign the
   DNSKEY RR set during the validity period of the particular priming
   key pair.  Note that the private part of the priming key is used each
   time when a DNSKEY RRset has to be resigned.  In practice there is
   therefore little difference between the usage pattern of the private




Ihren, et al.            Expires April 18, 2005                [Page 17]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



   part of key signing keys and priming keys.



















































Ihren, et al.            Expires April 18, 2005                [Page 18]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



7.  IANA Considerations


   NONE.

















































Ihren, et al.            Expires April 18, 2005                [Page 19]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



8.  References


8.1  Normative References


   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.


   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
        RFC 3757, May 2004.


   [3]  Arends, R., "Resource Records for the DNS Security Extensions",
        draft-ietf-dnsext-dnssec-records-10 (work in progress),
        September 2004.


8.2  Informative References


   [4]  Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
        "DNS Security Introduction and Requirements",
        draft-ietf-dnsext-dnssec-intro-12 (work in progress), September
        2004.


   [5]  Kolkman, O., "DNSSEC Operational Practices",
        draft-ietf-dnsop-dnssec-operational-practices-01 (work in
        progress), May 2004.


   [6]  Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
        Public Key Infrastructure Certificate and CRL Profile", RFC
        2459, January 1999.



Authors' Addresses


   Johan Ihren
   Autonomica AB
   Bellmansgatan 30
   Stockholm  SE-118 47
   Sweden


   EMail: [e-mail]












Ihren, et al.            Expires April 18, 2005                [Page 20]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



   Olaf M. Kolkman
   RIPE NCC
   Singel 256
   Amsterdam  1016 AB
   NL


   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.ripe.net/



   Bill Manning
   EP.net
   Marina del Rey, CA  90295
   USA





































Ihren, et al.            Expires April 18, 2005                [Page 21]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



Appendix A.  Acknowledgments


   The present design for in-band automatic rollovers of DNSSEC trust
   anchors is the result of many conversations and it is no longer
   possible to remember exactly who contributed what.


   In addition we've also had appreciated help from (in no particular
   order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
   Larson and Mark Kosters.











































Ihren, et al.            Expires April 18, 2005                [Page 22]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



Appendix B.  Document History


   This appendix will be removed if and when the document is submitted
   to the RFC editor.


   The version you are reading is tagged as $Revision: 1.1.232.1 $.


   Text between square brackets, other than references, are editorial
   comments and will be removed.


B.1  prior to version 00


   This draft was initially published as a personal submission under the
   name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt.


   Kolkman documented the ideas provided by Ihren and Manning.  In the
   process of documenting (and prototyping) Kolkman changed some of the
   details of the M-N algorithms working.  Ihren did not have a chance
   to review the draft before Kolkman posted;


   Kolkman takes responsibilities for omissions, fuzzy definitions and
   mistakes.


B.2  version 00
   o  The name of the draft was changed as a result of the draft being
      adopted as a working group document.
   o  A small section on the concept of stale trust anchors was added.
   o  The different possible states are more clearly defined, including
      examples of transitions between states.
   o  The terminology is changed throughout the document.  The old term
      "M-N" is replaced by "threshold" (more or less).  Also the
      interpretation of the constants M and N is significantly
      simplified to bring the usage more in line with "standard"
      threshold terminlogy.


















Ihren, et al.            Expires April 18, 2005                [Page 23]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Ihren, et al.            Expires April 18, 2005                [Page 24]