Subject: Interim signing of the root zone.

From: Johan Ihren <[email-masked]>
Date: 07 Oct 2002 11:17:38 +0200

Hi folks,

I aubmitted this to the ID-editor just before the weekend, so it
should show up anytime now. I'd be most happy to hear comments from
others. 

This is something that has to be done sooner or later and I think that
in this case sooner is to be preferred. 

Regards,

Johan Ihrén
Autonomica
-----------------

Internet Draft                                          Johan Ihren
draft-ihren-dnsop-interim-signed-root-00.txt            Autonomica
October 2002
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 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.

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, as well as,
   when appropriate and possible, also enhancing the functionality of
   DNS.

   In the particular case of the maintenance of the distribution
   mechanisms for the DNS root zone this is exactly what the root
   server operators have been doing for more than fifteen years.

   The time is now right for yet another step of improvement by
   signing the root zone. By doing that any Internet user that so wish
   will obtain the ability of verifying the 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 but 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.

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 even
   possible recover in a graceful way should new operational problems
   turn up.

   Because of these operational and technical issues there is good
   reason to sign the root zone before the status of implementation of
   Delegation Signer support change to "generally available" thereby
   increasing the pressure for signed delegations.

3. Interim signing of the root zone.

   At present all the authoritative servers for the root zone pull the
   zone from a so-called hidden primary master. I.e. any changes at
   the hidden master will propagate via NOTIFY[RFC1996] and subsequent
   AXFR/IXFR[RFC1995, AXFR-clarify] to the slave servers.

   Between the hidden 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.

   A workable interim scheme should fit into this existing structure.

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

3.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. For this task individual operator keys
     are used.

   * The set of operator keys are signed by one key-signing key
     (sometimes referred to as a "master key") at any particular
     time. The key-signing key in use has to be statically configured
     in all resolvers that want to be able to perform validation of
     responses.

   * Key rollover, the operation when an old key-signing key is
     exchanged for a new key-signing key, is managed with minimal
     overlap and on a frequent basis of no less than three times per
     year. 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.

3.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 hidden
   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 hidden
     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, hidden 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 hidden 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 operator 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 actually
     changes 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.

3.2.2. Management of the key-signing keys.

   The key-signing keys are periodically issued by the Regional
   Internet Registries, RIRs, individually. The RIRs should all
   perform the task of generating individual key-signing keys and
   signing the "keyset".  However, only one keyset should be included
   in the signed zone file.

   The RIRs were chosen on the grounds of

   * their proven record of service to the Internet community 

   * not having 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, thereby alleviating the
     risk of the "signing authority" sticking in one place.

   The requirement on the individual RIRs 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.

   * 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)

   Technically the operation of signing the operator keys works by the
   key-signing key signing the set of keys (i.e. itself plus all the
   operator keys). The result is called a "signed keyset".

3.2.3. Management of the operator keys and the signed "keyset".

   A subgroup of the root operators that choose to participate in
   signing the zone each hold an individual "operator key". 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 set of operator keys should be sent as a signed,
     authenticated block of data to all of the RIRs via an out-of-band
     mechanism.

   * Each RIR should generate a new signed keyset and send this back
     to the signing operators via an out-of-band mechanism.

   * The signing operators should include one of the received signed
     keysets in the zone file according to an agreed upon rotation
     schedule.

3.2.4. Management of key rollover.

   The key-signing keys should be 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 the key (to be able to validate
   lookups) will have to change the "trusted key" 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 a key-signing key held by
     one RIR to a keyset signed by a key-signing key held by the next
     RIR in the chain.

   * 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 tissue to deal with.

   * Since the keys expire within a few months the aim is to make it
     impossible 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. 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:

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

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

4.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.2.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.

4.4. What happens if the unsigned zone is compromised between the
     hidden primary master and the signing primaries?

   This is basically the same threat as the zone being compromised
   between the hidden 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 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.

4.5. What are the security implications for the new "signing
     primaries"? Will they not have to be as secure as the hidden
     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 hidden 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.

4.6. What happens if an operator key is compromised?

   If this happens it is necessary to do an emergency rollover of the
   keyset including the compromised key. I.e. a new set of operator
   keys is generated, the new keyset is signed by the "RIR on duty"
   using the active key-signing key and then the root zone is
   re-signed using one of the new operator keys.

   This problem is not unique to a signed root zone, it is inherent in
   any activity involving cryptographic keys.

4.7. What happens if the key-signing key is compromised?

   If this happens 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 signed by a key-signing key issued by the
   next RIR "in line", i.e. just re-schedule the next planned rollover
   to take place immediately..

   The new signed keyset is added to the root zone and then the zone
   is re-signed using one of the new operator keys. In this case,
   since the key-signing key is changed, every resolver will 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.

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

5. Security Considerations

   Signing the DNS root zone is all about security. A signed root zone
   will aid applications and organizations all over the Internet in
   improving their security.

   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 stability and security wise.

   Se further section 4 for a more complete risk analysis.

6. IANA Considerations.

   NONE.

7. References

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

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

8. 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 Guðmundsson, Rob Austein, Patrik Fältström, Olaf Kolkman,
   Harald Alvestrand, Suzanne Woolf, John M. Brown and Lars-Johan
   Liman.

9. Authors' Address

Johan Ihren
Autonomica AB
Bellmansgatan 30
SE-118 47 Stockholm, Sweden
[email-masked]

---

From: Bill Manning <[email-masked]>
Date: Mon, 7 Oct 2002 11:10:20 -0700 (PDT)

some concerns:

	DS only works in snapshot code.  And the publicly availble
	snapshots have known, serious operational problems. We -REALLY-
	need more stable code before committing this to production.

	there are some indications from the root testbed that there
	are fatal interactions with some released versions of DNS
	code.  further controlled testing should be done.

	the selection of RIRs.  RIRs -DO- have the DNS as a primary
	field of activity.  (see in-addr.arpa.) The holders of
	forward space (.SE, DE, NL, etc.) become disinfranchised
	"customers". 

	"sufficient number" and "out-of-band" are concepts that
	really need some concrete recommendations.

	key duration should be better fleshed out. Experiences from
	the existing testbed may be useful.

	key publication methods have been explored but do need further
	work.  

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

	this is not exactly true. 
	and your risk-analysis does not exactly match empirical evidence.

--bill

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 07 Oct 2002 22:45:12 -0400

>         need more stable code before committing this to production.

Bill this is version 00 of the draft, your concerns are noted but
this particular experiment is not starting next week or next month.
This is the documentation for the experiment and Johan is seeking feedback.

>         code.  further controlled testing should be done.

Agreed.

>         forward space (.SE, DE, NL, etc.) become disinfranchised

RIR are geographically competent operators for this experiment,
for future production Layer 9 will become involved.

>         really need some concrete recommendations.

Yes, suggestions.

>         the existing testbed may be useful.

yes, suggestions please,
as well as key length key set size etc, etc.

>         key publication methods have been explored but do need further

agreed, this is one of many the research programs that this experiment
will hopefully shed some light on what works and what does not.
Issues involve:
         - DS or KEY as published record
         - where to publish
         - is there a way to auto-configure resolvers trusted keying list

         Olafur

         Olafur

---

From: Bill Manning <[email-masked]>
Date: Mon, 7 Oct 2002 20:37:08 -0700 (PDT)

% At 14:10 2002-10-07, Bill Manning wrote:
% >  some concerns:
% >
% >         DS only works in snapshot code.  And the publicly availble
% >         snapshots have known, serious operational problems. We -REALLY-
% >         need more stable code before committing this to production.
% 
% Bill this is version 00 of the draft, your concerns are noted but
% this particular experiment is not starting next week or next month.
% This is the documentation for the experiment and Johan is seeking feedback.

	documentation for -an- experiment.  an experimental setup has 
	existed and been running for over 2 years.  Signing the root
	zone in this testbed has been operational for three months,
	nearly as long as ther has been DS capable code.  I remain 
	leary of experimentation with the live system.

% >         the selection of RIRs.  RIRs -DO- have the DNS as a primary
% >         field of activity.  (see in-addr.arpa.) The holders of
% >         forward space (.SE, DE, NL, etc.) become disinfranchised
% >         "customers".
% 
% RIR are geographically competent operators for this experiment,
% for future production Layer 9 will become involved.

	"geographically competent"  - now there's a turn of phrase :)
	-IF- this is really an experiment, with the live system,
	then bounding the experiment is prudent.  I'd be -very-
	leary of giving even the suggestion of "early-implementor"
	bias to one vector of the possible keyholder pool.

% >         "sufficient number" and "out-of-band" are concepts that
% >         really need some concrete recommendations.
% 
% Yes, suggestions.

	More experimentation in the operational testbed may generate
	some empirical numbers/processes that work.  Not convinced
	that running this on the live system is reasonable.

% >         key duration should be better fleshed out. Experiences from
% >         the existing testbed may be useful.
% 
% yes, suggestions please,
% as well as key length key set size etc, etc.

	More work within the existing testbed will generate such 
	numbers that have some grounding in experience.

% >         key publication methods have been explored but do need further
% >         work.
% 
% agreed, this is one of many the research programs that this experiment
% will hopefully shed some light on what works and what does not.
% Issues involve:
%          - DS or KEY as published record
%          - where to publish
%          - is there a way to auto-configure resolvers trusted keying list

	So... why are we considering experimenting with the live,
	production root system at this time?  IMHO, this is lunacy.
	We have a working, experimental system in play where most
	(all) of these issues can be tested.  Folks that have 
	serious commercial interests in a stable system will not be 
	amused when we start experimenting with the systems that
	they depend on.

%          Olafur

-- 
--bill

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 7 Oct 2002 22:53:37 -0500

From: "Bill Manning" <[email-masked]>
"Folks that have serious commercial interests in a stable system will not be
amused when we start experimenting with the systems that they depend on.
======

The entire, "toy", 32-bit, experimental, proof-of-concept network is the perfect place to play.
Companies with a serious commercial interest have all of the labs and facilities they need to
fully test software and systems before they are deployed. The only amusement is that people
from the experimental networks take themselves so seriously. The commercial world does not.

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.ietf.com
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://ipv8.dyndns.tv
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au

---

From: Brad Knowles <[email-masked]>
Date: Wed, 9 Oct 2002 01:03:30 +0200

>  is the perfect place to play.

	Toy?  Are you serious or just sarcastic?

>  Companies with a serious commercial interest have all of the
>  labs and facilities they need to fully test software and
>  systems before they are deployed.

	They may have the facilities, but even they need help in 
performing full interoperability and functionality testing of this 
kind of scale.

>                                    The only amusement is that
>  people from the experimental networks take themselves so
>  seriously. The commercial world does not.

	The commercial world doesn't take them seriously, or doesn't take 
itself seriously?

	Both statements are sufficiently ludicrous that I won't bother 
saying anything else.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w---
O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

---

From: Randy Bush <[email-masked]>
Date: Wed, 09 Oct 2002 18:39:42 +0900

> At 8:37 PM -0700 2002/10/07, Bill Manning wrote:
> At some point, you have to stop testing in an isolated lab and 
> start doing things in the real world.

don't take some folk's comments too seriously.  some of the folk
screaming "caution" are deploying anycast roots without dnssec.

and please stop replying to sociopaths such as jim fleming

randy

---

From: Brad Knowles <[email-masked]>
Date: Wed, 9 Oct 2002 00:56:10 +0200

At some point, you have to stop testing in an isolated lab and 
start doing things in the real world.  I don't know if we are now at 
that point, but this is a good time to start talking about this issue.

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 9 Oct 2002 07:50:56 -0500

----- Original Message ----- 
From: "Brad Knowles" <[email-masked]>
To: "Jim Fleming" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 08, 2002 6:03 PM
Subject: Re: Interim signing of the root zone.

> Both statements are sufficiently ludicrous that I won't bother 

http://isp-planet.com/technology/2002/dns_server.html
DNS Server Choices Broaden

"Industry insiders estimate that 85 percent of ISPs use free BIND (Berkeley Internet Name Domain) software running over generic
server architecture. However, the latest hacker exploits may cause ISPs to rethink their buying habits. BIND has been rated the
number one security risk on the Internet by The SANS Institute."
====

Why does ICANN showcase all of the BIND people as "security experts" ?

Jim Fleming
http://www.netfilter.org/
http://ipv8.yi.org
http://ipv8.no-ip.org
http://ipv8.ods.org

---

From: David Conrad <[email-masked]>
Date: Wed, 09 Oct 2002 16:48:42 -0700

Randy,

OK, I'll bite.

On 10/9/02 2:39 AM, "Randy Bush" <[email-masked]> wrote:
> some of the folk

Can you describe the issues you see with anycast and how DNSSEC would
address those issues?

Rgds,
-drc

---

From: Randy Bush <[email-masked]>
Date: Thu, 10 Oct 2002 16:09:09 +0900

> Can you describe the issues you see with anycast and how DNSSEC would

w/o dnssec, one can not differentiate ancasted root from a routing attack
on that root.  see <http://www.nanog.org/mtg-0206/ppt/massey/index.htm>
for how one might defend against such attacks.

as dnssec is finally approaching deployment, it seems imprudent to rush
into a not obviously critical anycast deployment when a little patience
would seem harmless.

with dnssec, anycast authoritative servers are way cool, clearly safe,
and quite deployable.

without dnssec, it seems grandstanding to no prudent useful end.

randy

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 9 Oct 2002 09:44:30 -0400

Related to the draft topic - I was doing some further research on key
management and I was wondering why the key rollover scheme in the draft was
chosen:  why so often?

There has been some previous work on optimal/practical key lengths.  It goes
from the extreme hardcore to the general rule-of-thumb.  Arjen Lenstra and
Eric Verheul has a paper ("Selecting Cryptographic Key Sizes" in the Journal
of Cryptography Vol14, number 4 November 2001) that goes into great detail
on calculating the necessary key lengths for a given cryptosystem based on
how long the secret must be maintained, key use, and possible attack
strength (possible computing power available).

A more practical approach is to follow RSA Security's suggested key lengths.
Every year, RSA sets the limit of what they believe a "reasonable" key
length should be (pointer):
http://www.rsasecurity.com/rsalabs/faq/3-1-5.html

They recommend a min length of 2048 for RSA keys used by Certificate
Authorities.  These keys are usually rolled over every 2 years.  Since a
root key signing key will be very rarely used (only sign the root zone key),
it will be used less often than a CA signing key.  Any root zone keys could
be rolled over more frequently, and shorter.  And that there should be
procedures in place to adapt to new cryptanalysis advances.

The DNS has a similar "crypto profile" as a certificate scheme (i.e.. known
plaintext, public key, etc).  So looking at the key management schemes
sounds reasonable to me, but I'm not a hardcore security guy.

Scott

---

From: Johan Ihren <[email-masked]>
Date: 10 Oct 2002 15:32:57 +0200

"Scott Rose" <[email-masked]> writes:

> Related to the draft topic - I was doing some further research on
> key management and I was wondering why the key rollover scheme in
> the draft was chosen: why so often?

Wow, a technical comment. Thanks, Scott.

There are two reasons:

1. This is an *interim* scheme and as such it is important not to give
   the impression that the trusted key is something to file and
   forget. I.e. I'm trying to avoid anyone putting long term trust
   into these keys.

2. One of the main objectives is to, in the particular context of the
   root zone, gain operational experience with key mgmt, rollovers,
   exchanges between the holders of key signing keys and operational
   keys (since they are likely to continue being separate entities for
   the root zone), etc.

   With long lived keys we won't get nearly as much experience, since
   we'll hang off the same key signing key for years. Furthermore we
   won't get as much experience in how to publish new trusted keys to
   actually get them into as many resolvers as possible.

The bottom line is that this is not a production design that is
optimized for maximum security with minimum cost. Rather it is
designed to be staging area to gain experience while at the same time
not fooling end users into believing they got the final product.

Regards,

Johan

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 10 Oct 2002 15:11:03 +0200

> without dnssec, it seems grandstanding to no prudent useful end.

This is an excellent argument for DNSSEC, in my eyes at least. 

Seems there is a to-do list forming here. 

* Get more eyeballs on the BIND 9<some version> failure scenarios with
  signed root. Can those who reported these speak up? 

* Fix those issues and get a stable 9.3 out.

* Discuss this in RSSAC. Thoroughly. 

* Polish the draft and advance it. 

* Perform the test, including preparations. 

* Stop the test and think things over. 

Just this moderately clued observers view, while looking for asbestos
underwear... 
-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 10 Oct 2002 15:02:26 +0200

> should show up anytime now. I'd be most happy to hear comments from

I like the idea. What seems complicated (the signing scheme, the
involvement of the RIRen, etc) is to me the result of a careful
consideration. 

I especially like the RIR involvement. While most domain name holders have
issues with some of the gTLD or ccTLD registries, I sense no such amount of
"issue" with the RIR trio. In a less than perfect world the RIRen are
trusted by most, and they are to me a natural place for the root zone "key
work".

Bonus points for not using a not-for-profit company in California ;-)

---

From: Bill Manning <[email-masked]>
Date: Thu, 10 Oct 2002 09:46:49 -0700 (PDT)

% This is an excellent argument for DNSSEC, in my eyes at least. 

	Yup. One of the best.

% Seems there is a to-do list forming here. 
 
% * Get more eyeballs on the BIND 9<some version> failure scenarios with
%   signed root. Can those who reported these speak up? 

	sure.  -caching failures with -0722 master and 9.2.1 cache.
	       only the NXT/SIG records are cached.
	       -apparent inability for 922rc1 slaves of -0722 masters
	 	from responding w/ SIG/KEY/NXT RRs from a signed zone.
		(+trace indicates the DNSSEC rrs are available from 
		 -another authoritative server- but dig does not show
		this w/o the trace flag envolked.
	sam had some other information on resolver behaviour.

% * Fix those issues and get a stable 9.3 out.

	I'd be happy with another public snapshot.

--bill

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 11 Oct 2002 10:09:59 +0859 ()

Randy;

> for how one might defend against such attacks.

As was discussed severail times in past meetings, the routing attack
on unicasted root is equally harmful.

A simple protection for an ISP is not to blindly receive any route
from customers and to have peering relationship only with reliable
ISPs, both of which are the current practice of sane ISPs.

Another protection for an ISP is to have its own root servers
with the anycast address, which means anycasted root IMPROVES
the security.

> into a not obviously critical anycast deployment when a little patience

DNSSEC, or any CA-based security, is not really secure and is
undeployable for any practical security.

> with dnssec, anycast authoritative servers are way cool, clearly safe,

The fundamental question is who assures that it is safe.

That is, how much is compensated from who, if the security is
compromized?

							Masataka Ohta