Subject: Last Call: Root Name Server Operational Requirements to BCP

From: The IESG <[email-masked]>
Date: Fri, 25 Feb 2000 10:32:40 -0500

Note: This Last Call message obsoletes the previous message which
      contained an incorrect Last Call Expiration date.

The IESG has received a request from the Domain Name Server Operations
Working Group to consider Root Name Server Operational Requirements
<draft-ietf-dnsop-root-opreq-03.txt> as a BCP.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by March 10, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-root-opreq-03.txt

---

From: "D. J. Bernstein" <[email-masked]>
Date: 27 Feb 2000 20:56:43 -0000

[This message is bcc'ed to some of the relevant administrators.]

There is a serious conceptual error behind the ``security'' requirements
in root-opreq-03. See

   http://cr.yp.to/dnscache/bugtraq/20000123114946-2072-qmail@cr-yp-to

for details.

The basic problem is that, when X has an NS record of Y, anyone with
control over the Y name can take control over all X names. For example,
an attacker who breaks into galileo.cc.rochester.edu (which is running
Sendmail 8.8.5 and BIND 8.2) can

   (1) take control over *.utd.rochester.edu, then
   (2) take control over *.rochester.edu, then
   (3) take control over *.cornell.edu, then
   (4) take control over *.se, then
   (5) take control over *.ripe.net, then
   (6) take control over *.root-servers.net, then finally
   (7) take control over the entire network.

It doesn't do any good to secure a high-level server without also
protecting the _name_ of that server, which means securing the servers
for that name, and the servers for the names of _those_ servers, etc.

For a complete list of the servers that currently have this type of
control over (say) aol.com, compile my DNScache package from

   http://cr.yp.to/dnscache/install.html

and run

   dnstrace any aol.com `cat @` > TRUSTED-BY-AOL

The output is over half a megabyte long, showing hundreds of different
computers. Be happy that there aren't thousands!

The simplest fix is an additional configuration requirement to use
in-zone names for all NS records. This also improves the speed and
reliability of DNS, as explained in

   http://cr.yp.to/dnscache/notes.html#gluelessness

This is current practice at many sites, and it's clearly better practice
than what the high-level servers are doing.

Note that NSI's prohibition on different server names with the same IP
address will have to be scrapped. This would be a useless prohibition
even if it weren't a security problem. (One NSI employee has told me
that this prohibition stops people from pointing their domains at other
people's servers without authorization. That's simply not true.)

---Dan

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 08 Mar 2000 19:38:39 -0500

Yes, it is true that DNS was, is, and will remain inherently insecure
until DNSSEC or something equivalent is deployed.

Donald

From:  "D. J. Bernstein" <[email-masked]>
Date:  27 Feb 2000 20:56:43 -0000
Message-ID:  <[email-masked]>
To:  [email-masked]
Cc:  [email-masked]
References:  <[email-masked]>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 9 Mar 2000 02:38:03 -0000

I continue to object to opreq on security grounds.

The following table summarizes the security situation from an attacker's
perspective (assuming unpredictable query ports and IDs---true for many
caches now, and presumably almost all caches in a few years):

   DNS                      Trivial to break from anywhere.
   DNS+opreq                Trivial to break from anywhere.
   DNS+opreq+inzone         Need to sniff or send billions of forgeries.
   DNS+dnssec               Need to subvert one of the signers.
   DNS+dnssec+opreq         Need to subvert one of the signers.
   DNS+dnssec+opreq+inzone  Need to subvert one of the signers.

Explanation of the symbols:

   * opreq: the security practices required in opreq-03 and opreq-04,
     such as avoiding insecure software on central DNS servers;

   * inzone: the very low-cost, and fairly common, practice of using
     in-zone _names_ for NS records;

   * dnssec: the very high-cost, and currently mythical, practice of
     creating and verifying IANA+NSI+... signatures.

The opreq authors appear to believe that opreq by itself adds security.
That belief is incorrect, as my bugtraq message demonstrates.

On the other hand, opreq+inzone would drastically increase the
attacker's expense, at the trivial cost of changing a few NS names.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 12 Mar 2000 01:22:29 -0000

Scott Bradner has asked me to propose specific changes to opreq. Here's
possible text for the security section:

   3.4 The computers that publish a server's address MUST be secured as
       carefully as the server itself.

       3.4.1 If, for example, clients use an NS record that points to
             the server f.root-servers.net, then the computers that
             control the zone root-servers.net have the power to direct
             those clients to the IP address of a fake server. Those
             computers MUST be secured as carefully as the real server.

       3.4.2 This rule applies recursively. If the address of a server
             is published by one computer, whose address in turn is
             published by another computer, then this last computer MUST
             be secured too; and so on.

       3.4.3 Administrators are encouraged to avoid this situation. One
             good way to avoid NS dependencies is to make each NS record
             point to a name in the (child) zone that contains the NS
             record. Note that this strategy will assign several names
             to one IP address when one server handles several zones.

Does anyone know why root-servers.net and gtld-servers.net weren't kept
within the .net zone in the first place?

---Dan

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Mar 2000 17:27:35 -0800

>        carefully as the server itself.

i thought a resolver got the addresses of the root servers

  o initially from the hints file distributed and pgp signed by the iana

  o and them refreshed these from [any one of] the listed servers

i.e. a resolver does not look up 'a.root-servers.net' to find a root server.

randy

---

From: "D. J. Bernstein" <[email-masked]>
Date: 12 Mar 2000 04:06:32 -0000

The example shows ns2.netsol.com selectively redirecting a victim's
connections to yahoo.com.

Don't you think it looks rather silly to be putting so much effort into
protecting the real .com servers, when the weak point of the system
actually lies in the mechanism by which those servers are located?

Perhaps you'll say that you don't care whether all the TLDs are broken;
you're just worrying about the root zone. But your document says that
``major zone server operators,'' such as TLD operators, may find it
useful too.

By the way, according to RFC 1818, Best Current Practice documents
``describe best current practices.'' Several of your requirements don't
appear to describe current practices, never mind best current practices.
For example, 3.3.2 says that root servers ``MUST be DNSSEC-capable,''
but NSI says that the current servers would choke if DNSSEC were used.

---Dan

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Mar 2000 23:23:25 -0800

> you're just worrying about the root zone.

correct

---

From: Bill Manning <[email-masked]>
Date: Sun, 12 Mar 2000 00:20:52 -0800 (PST)

% 
% > Perhaps you'll say that you don't care whether all the TLDs are broken;
% > you're just worrying about the root zone.
% 
% correct
% 

As has been pointed out in the past, this  document is likely mis-named.
And I believe that simply focusing on root servers is wrong. The "trickledown"
effect is pervasive in the DNS architecture.  RFC 2010 talks about rootserver
expectations and recognises that at the time, there was a co-mingling of
root and TLD service on the same suite of servers. It also comprehended that
the TLD service should be moved to their own sets of servers. This document
seems to retain the view that root and gTLD zones will remain comingled. I
think it is better addressed to the "flat" gTLDs with large numbers of zones.
In any case, I think that Randys focus on just the root is misguided. It is 
important to have compatability betwen parent and child servers. And this 
documents label does not reflect that.

-- 
--bill

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Mar 2000 10:24:27 -0000

I wrote:
: For example, 3.3.2 says that root servers ``MUST be DNSSEC-capable,''
: but NSI says that the current servers would choke if DNSSEC were used.

In fact, it turns out that the current version of BIND _crashes_ if you
give it a secure zone.

I realize that the IESG wants to encourage people to support DNSSEC. But
calling it ``best current practice'' is fraudulent.

---Dan

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Mar 2000 05:01:51 -0800

>> but NSI says that the current servers would choke if DNSSEC were used.

note that it does not say it must be enabled.

randy

---

From: Mark Kosters <[email-masked]>
Date: Tue, 21 Mar 2000 09:43:03 -0500

> calling it ``best current practice'' is fraudulent.

Dan - the next sentence in 3.3.2 says: 

  It is understood that DNSSEC is not yet deployable on some common platforms, 
  but will be deployed when supported.

So, when DNSSEC is ready with a implementation that is robust and scalable,
the root servers must be able to support it. IMHO, there is nothing fraudulent
about that.

Mark

-- 

Mark Kosters             [email-masked]       Network Solutions, Inc.
PGP Key fingerprint =  1A 2A 92 F8 8E D3 47 F9  15 65 80 87 68 13 F6 48

---

From: Ray Plzak <[email-masked]>
Date: Tue, 21 Mar 2000 10:23:03 -0500 (EST)

IMHO this document is ready as it is.  There is no need for another draft.
All issues have been addressed.

Ray

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Mar 2000 16:16:16 -0000

opreq section 3.3.3 says ``Servers MUST use DNSSEC to authenticate root
zones received from other servers.'' That is not current practice.

opreq section 3.3.2 says ``Root servers MUST be DNSSEC-capable.'' That
is not current practice.

opreq section 3.3.1 says ``The root zone MUST be signed by the IANA.''
That does not appear to be current practice.

opreq section 2.2 says ``Each server MUST run software which correctly
implements the IETF standards for the DNS.'' That is not current
practice. BIND violates the IETF ``standards'' in many ways.

According to the FTC, representations made by standards organizations
with respect to testing procedures, standards, etc., must be truthful.
Referring to wishful thinking as ``current practice'' is not truthful.

---Dan

---

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Mar 2000 12:10:49 -0500

> That is not current practice.

[repeated multiple times]

> Referring to wishful thinking as ``current practice'' is not truthful.

Please consult 2026 for the precise definition of BCP and Best Current
Practice. BCP does not necessarily mean that a particular practice is
currently being practiced.

Thomas

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Mar 2000 19:02:14 -0000

Words have meanings. It is simply not true that opreq is ``current
practice.'' Please stop trying to deceive people.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Thu, 23 Mar 2000 03:53:08 +1100

Date:        21 Mar 2000 19:02:14 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Words have meanings. It is simply not true that opreq is ``current
  | practice.'' Please stop trying to deceive people.

You are arguing the wrong point in the wrong forum.   There's no question
(well, IMO) but that BCP is appallingly badly named.  BCP docs usually have
nothing whatever to do with best, current, or practice, and never did.

BCPs are simply docs that the IETF wants to give special recognition to
(as in, this is how it should be) but where the requirements of the standards
processes (multiple implementations of all features, and multiple versions at
different levels of standardisation, ...) make no sense at all - which is
the case here, and in the IETF procedure docs, and lots of other places.

If you want to argue about this, the place is in the poisson WG, which is
where the doc series was created.   When it was being created, all these
arguments were held, but when no-one could come up with an obviously better
name (and particularly one with a TLA) the current name simply stuck, as
bad as it is.

The opreq doc meets the requirements of a BCP doc as BCP docs are defined,
regardless of how well it might meet the expanded form of the name interpreted
as an English phrase.   But that should not be done any more than one should
argue whether any doc should be an RFC or not, based upon how well the doc
fits as a "request for comments".

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Mar 2000 23:25:55 -0000

Robert Elz writes:
> BCP docs usually have

According to BCP 1, RFC 1818, by Jon Postel et al., the BCP documents
``describe best current practices for the Internet community.''

I've read several BCPs, and I don't recall any of them trying to deceive
the reader as to what practices were current. The evaluation of ``best''
is often based on amazingly naive criteria, but that's a separate issue.

Anyway, no matter what the history was, and no matter what's been
published before, when you label something as ``current practice,''
you're telling readers that it's current practice. In this case, it
certainly isn't current practice.

---Dan

---

From: Larry Sheldon <[email-masked]>
Date: Wed, 22 Mar 2000 18:07:49 CST

> certainly isn't current practice.

Y'all certainly are tedious.

--
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
.                                                                       .
- L. F. (Larry) Sheldon, Jr.                                            -
. Unix Systems and Network Administration                               .
- Creighton University Computer Center-Old Gym                          -
. 2500 California Plaza                                                 .
- Omaha, Nebraska, U.S.A.  68178       Two identifying characterstics   -
. [email-masked]                  of System Administrators:     .
- 402 280-2254 (work)                Infallibility, and the ability to  -
. 402 681-4726 (cellular)               learn from their mistakes.      .
- 402 332-4622 (residence)                                              -
. http://www.creighton.edu/~lsheldon    Adapted from Stephen Pinker     .
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Mar 2000 09:38:13 +0900

> zones received from other servers.'' That is not current practice.

somehow your ascii text display program seems to have dropped the following
sentence.  the entire paragraph reads

       3.3.3 Transfer of the root zone between root servers MUST be
             authenticated and be as secure as reasonably possible.  Out
             of band security validation of updates MUST be supported.
             Servers MUST use DNSSEC to authenticate root zones received
             from other servers.  It is understood that DNSSEC is not
             yet deployable on some common platforms, but will be
             deployed when supported.

> opreq section 3.3.2 says ``Root servers MUST be DNSSEC-capable.'' That
  
somehow your ascii text display program seems to have dropped the following
sentence.  the entire paragraph reads

       3.3.2 Root servers MUST be DNSSEC-capable so that queries may be
             authenticated by clients with security and authentication
             concerns.  It is understood that DNSSEC is not yet
             deployable on some common platforms, but will be deployed
             when supported.

> That does not appear to be current practice.

somehow your ascii text display program seems to have dropped the following
sentence.  the entire paragraph reads

       3.3.1 The root zone MUST be signed by the IANA in accordance with
             DNSSEC, see [RFC2535] or its replacements.  It is
             understood that DNSSEC is not yet deployable on some common
             platforms, but will be deployed when supported.

randy

---

From: Ray Plzak <[email-masked]>
Date: Tue, 28 Mar 2000 01:31:05 -0500 (EST)

Since the IESG last call there has been some discussion concerning the
draft.  The authors of the draft believe that all technical concerns have
been addressed.  A hum was taken at the WG meeting to proceed. Is there
anyone on the list who has any technical objection to the draft?  If so,
please say so now.  If not the draft will proceed.

Ray

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Mar 2000 16:08:58 -0000

Ray Plzak writes:
> Is there anyone on the list who has any technical objection to the draft?

A PGP-signed root zone file, installed locally and kept up to date by
ISPs, would achieve the stated goals at vastly lower cost.

---Dan

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 29 Mar 2000 17:54:41 +1000 (EST)

On 28 Mar 2000, D. J. Bernstein wrote:

djb> Ray Plzak writes:
djb> > Is there anyone on the list who has any technical objection to the draft?
djb> 
djb> A PGP-signed root zone file, installed locally and kept up to date by
djb> ISPs, would achieve the stated goals at vastly lower cost.

You mispelt ``I like diagnosing problems caused by ISPs failing to update
their copy of the root zone''.

If people are still running Bind (insert scarily low release here, see
David Conrad's survey), changing the method by which the root zone is
distributed will take a considerable amount of time (many years) to be
effective. 

--==--
Bruce.

Speaking for myself.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Apr 2000 16:12:13 -0000

> their copy of the root zone''.

Are you claiming that the cost of automatically handling PGP-signed root
zone files is comparable to the cost of making DNSSEC work?

---Dan