Subject: Re: Netizen's Message (fwd)

From: Robert Watson <[email-masked]>
Date: Thu, 12 Feb 1998 14:58:33 -0500 (EST)

I originally responded by email to Bob only concerning some new technical
limitations that I felt his current high-volume TLD plan did not address.
Because these are also issues that other domain plans will have to
address, I have forwarded a copy to ietf-discuss.  My concerns lie
primarily with the integration of DNSsec into an expanded TLD system.  As
DNSsec becomes available, integration with any future DNS hierarchy will
increasingly become an issue.  As I have not yet read the widely-discussed
GP, I do not know if it attempts to address these issues.  DNSsec does
appear to raise the stakes for any TLD structure, requiring increased
reliability and a more static structure.

The DNSsec working group has certainly discussed these issues, but
possibly not in the context of a radically different TLD structure than
exists today.

To some extent, my email to Bob consists of brain-storming on the issue,
and should perhaps be treated as such. :)  Not all of my concerns may end
up being valid -- I probably also missed several serious ones.

  Robert N Watson 

Carnegie Mellon University http://www.cmu.edu/
SafePort Network Services  http://www.safeport.com/
[email-masked]   http://www.watson.org/~robert/

---------- Forwarded message ----------
Date: Tue, 10 Feb 1998 08:44:24 -0500 (EST)
From: Robert Watson <[email-masked]>
Reply-To: Robert Watson <[email-masked]>
To: Bob Allisat <[email-masked]>
Subject: Re: Netizen's Message

On Mon, 9 Feb 1998, Bob Allisat wrote:

>  As the alleged technical master brains of the
>  Internet drift further and further into error
>  by never actually discussing the issues, we the
>  people of the Internet grow ever more restless.
>  No-one has dared to answered the quite basic
>  questions. We say the current system could easily
>  handle anywhere from ten to thirty thousand new
>  Top Level Domains.

Bob,

With the current DNS mechanism, it does seem that your estimates of
hardware are sufficient.  However, an important issue to consider is the
advent of DNSsec.  Given the current model, it appears that it would be
desirable to modify the root zone as infrequently as possible, as any
modification would require resigning with the root key.

The root zone would at minimum require resigning each time any of the
following events occurred (in order that NXT-based denial could occur): 

1. A new delegation needs to be added

2. An old delegation needs to be modified (including just changing its
nameservers -- a frequent event lower in the domain hierarchy)

3. An old delegation needs to be deleted

4. A key used to sign any immediate sub-zones of the root zone is
compromised, requiring a new KEY RR to be entered in the delegation
(similar to (2)).

5. A root name-server needs to be moved/etc

(Some of this could be avoided if you are willing to give up NXTs --
update keys can be signed by the root, and then used to sign delegation
modifications instead of resigning the whole zone.  I'm not sure I would
want to given up NXT-denial of root-level delegations though!)

A larger root zone (i.e., more delegations) would appear to require more
frequent resigning.  I do not have formal statistics, but would guess that
the number of modifications to nameservers of organizations around the
country is fairly frequent.  Often, changes in service providers or
network topology requires a renumbering of hosts (including name servers). 
Similarly, with a larger root zone, the demand to add and remove
delegations would be far higher -- current estimates that resigning of the
root zone should occur at most once or twice a year clearly cannot apply
to this model.  Companies would be born and die in the time it takes for
their entry to be made in the root zone!  There does seem to be the
expectation that domain updates occur quite frequently, and that the
response time on a requested update be low.  However, more frequent
signing would require more frequent use of the key. 

The DNSsec root key management issues have largely been discussed in the
context of small root zones -- perhaps in the range of 100 to 500
subdomain delegations.  Before seriously considering a dramatic increase
in the size of the root zone, we would have to address these issues.  Jeff
Schiller's closing comments left us facing some astounding new security
issues: how do you protect a root key that has such huge commercial value? 
DNSsec KEY RRs may be the system by which Web browsers some day retrieve
TLS keys for use in financial transactions.  One of the few clear
approaches to the problem was to minimize use and severely restrict access
to the key. Frequent resigning of the root cannot be reconciled with this
approach. 

This is not to say that the zone hierarchy with such crowded second-level
zones is compatible with this either!  A more even distribution of
delegations vertically would have some benefits.  However, the current
demand for the highest level domain usable by an organization is clearly
inappropriate given this model.  Breaking down delegations by country
appears to be a useful model, though.  Perhaps rather than adding new
TLDs, we should be removing TLDs and shifting the emphasis to appropriate
use of national namespaces?

Serious consideration of a plan to have 20,000 delegations in the root
zone cannot be made until the plan outlines the security consequences in a
secure DNS.  Similarly, any plan that suggested millions of entries in
another level of the hierarchy (.com? :) should be carefully considered
before being implemented.

 --begin political blurb--
A better answer to this whole problem would be to reduce the emphasis on
DNS as a directory service, and use it for hierarchal canonical lookup
based on the results of some other directory service?  DNS provides
information about canonical names, not a mechanism for discovering any
company with the name "ABC" in it, or for by-topic searches such as
".shop"  or ".xxx".  Then over-burdening of the name space becomes less of
an issue?  I still like the idea of URLs in the form
http://www.isp.net/company/ or http://company.isp.net/.. (the latter seems
more workable with DNSsec keying also) when the company has only a web
presence, not direct connectivity.  With the increased use of firewalls
and proxies, organizations often need only one or two exposed IPs, making
company.isp.net far more acceptable.
 --end political blurb--

I was not entirely sure this was appropriate for the mailing lists just
yet, as I have not yet put enough thought into the considerations of
DNSsec in such an environment yet, and would appreciate your comments.

Thanks,

  Robert N Watson 

Carnegie Mellon University http://www.cmu.edu/
SafePort Network Services  http://www.safeport.com/
[email-masked]   http://www.watson.org/~robert/

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 17 Feb 1998 13:19:13 -0500 (EST)

On Thu, 12 Feb 1998, Robert Watson wrote:

> Date: Thu, 12 Feb 1998 14:58:33 -0500 (EST)
> To: [email-masked]

No, the GP says nothing about anything at the technical level of DNSsec.  To
some extent, the Green Paper treats the Internet as the sort of static things
that government regulators like rather than the rapidly evolving structure
with continuing engineering work that the Internet and the DNS really are. 

But, while DNSsec increases the size of secured zones and the size of typical
responses from secured zones and uses much more CPU power to authenticate, I
don't see these as making anything impossible.  If you can secure .com, there
is probably not a technical barrier to securing a large root.  By the way,
partially, I believe, in anticipation of this sort of thing many of the
authoritative servers which currently provide the IETF recommended root zone
plus .com, .net, .org, etc., have been upgraded to DEC Alpha's. 

> possibly not in the context of a radically different TLD structure than

While most of the root zone disucssion in the DNSsec WG has related to 
whether or not their should be a "meta-root" key that is only used to 
sign the root key, etc., the mere size of the root zone, at least at the 
kind of sizes that have been talked about here is, as you can tell from 
most of the mail about it, almost a purely political issue, not a 
technical one.

> ...
> ...

Yes, but these changes can be batched.  Given that you want to be very
careful with root, I don't really see any need to update and re-sign the root
zone more often than once a week plus an occasional extra due to some urgent
change. 

> signing would require more frequent use of the key. 

The larger the root zone the more frequently there are change requests but
how often the zone itself is updated is a matter of policy.  By the way, I
believe that for some time now the rate of updates that NSI receives for .com
has been well over 10,000 a month. 

Even with a giant zone (say .com), you can re-sign daily if you want as 
long as the changes are not giant.  If you are signing daily with signature
expiration times of, say, a week plus a few days, then each night you need
only re-sign approximately 1/7 of the zone plus the changes. (Initial 
DNSsec zone signing software may not support such incremental re-signing.)

For the ultimate, I suppose you could even enable secure dynamic update 
of the root zone (See RFCs 2136 and 2137), but I would hesitate to do 
that until secure dynamic update is well deployed and has a rock solid 
implementation and even then I'd think about it very carefully...

> to the key. Frequent resigning of the root cannot be reconciled with this

So you have a very well protected meta-root key which you only take out once
a year for the purpose of signing a bunch of monthly root zone keys or the
like. See draft-ietf-dnssec-secext2-02.txt section 4.5 for example. 

> use of national namespaces?

It is certainly the case that deeper names should be encouraged.  By the way,
the .US zone, which people keep misrepresenting as almost totally unused, has
over a *million* hosts in it according to the latest domain names survey. 
And most of those are *fouth* level names like foo.city.xx.us. A great part
of the DNS problem is simple emotional shallow name jealousy. If, years ago,
a lot of pushback had been applied to new .com registrations and a two level
commercial TLD had been established (say .biz), so that most business would
register as united.airlines.biz or acme.hardware.biz, etc., that is with
third level names, the bloat and name confusion at the second level in .com
and resultant technical and user problems would have been significantly
reduced. 

> ...

Donald
=====================================================================
Donald E. Eastlake 3rd     +1 978-287-4877(tel)     [email-masked]
   318 Acton Street        +1 978-371-7148(fax)
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.privacy.org/ipc

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 17 Feb 1998 13:19:13 -0500 (EST)

Donald