Subject: Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt

From: Olaf Kolkman <[email-masked]>
Date: Thu, 21 Jan 2010 12:41:50 +0100

In trying to get a reasonable version 2 out of the door before Anaheim I am trying to identify and where possibly close open issues.

As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has the open issues listed and a per issue highlight of their history.

This thread, about the use of HSMs, is captured in http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs the content of that page is replicated below.

I believe I captured the gist of the discussion in a modified version of paragraph 3.6 (see below). The first two paragraphs are not modified, the text starting with "The ideal situation" has been.

I welcome editorial comments off-list.

If the chair believes the current text captures consensus I will move this issue to the closed issues list.

--Olaf

$Id: cryptography_flawed 14 2009-02-09 18:54:12Z olaf $
20100121
   The use of HSMs
   Shane Kerr/Ed Lewis
   Added: 21 jan 2010
   http://www.ietf.org/mail-archive/web/dnsop/current/msg07190.html
   and
   http://www.ietf.org/mail-archive/web/dnsop/current/msg07193.html   

   The recommendation to use a HSM is far to strong. Arguments of fate sharing
   and operational overhead are being made on the list.

Discussion:

	From: 	Shane Kerr <[email-masked]>
	Subject: 	Re: [DNSOP] I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt
	Date: 	April 21, 2009 1:03:58 PM GMT+02:00
	Cc: 	dnsop WG <[email-masked]>

I believe the key of the thread is captured in the following quotes:

Stephane Bortzmeyer wrote:
> 
> But the risk for the key is not only people modifying it, it is simply
> people *reading* it (a concern which also exists for the database but
> is much less important). 
> 
> I have no practical experience with HSMs but, in my mind, the
> interesting thing is that they guarantee noone will read the key
> without an authorization (that's quite unlike the database where you
> certainly prefer a few unauthorized looks to a complete loss).

This is the key point IMHO.

AIUI, the attack vector that HSM are designed to protect is that someone
makes a copy of your key signing material without you knowing about it.
Once they do that, they can spoof replies until such time as you roll
your key.

If an unauthorized person modifies the contents of the database backing
your zone, you may or may not know about it, but an observant customer
will at least notice that the data has changed.

So the two are not totally equivalent.

Having said that, I agree that HSM hysteria is a bit overblown, and that
the actual DNSSEC signing is very, very unlikely to be the weakest link
in DNS security in any organization.

Resolution:

Following the suggestion from:
	From: 	Peter Koch <[email-masked]>
	Subject: 	Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt
	Date: 	April 27, 2009 1:19:45 PM GMT+02:00
	To: 	IETF DNSOP WG <[email-masked]>

I rewrote the text to highlight the economic tradeoff, the relevant part of section 3.6 is copied below.

3.6.  Private Key Storage

   It is recommended that, where possible, zone private keys and the
   zone file master copy that is to be signed be kept and used in off-
   line, non-network-connected, physically secure machines only.
   Periodically, an application can be run to add authentication to a
   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
   transferred.

   When relying on dynamic update to manage a signed zone [11], be aware
   that at least one private key of the zone will have to reside on the
   master server.  This key is only as secure as the amount of exposure
   the server receives to unknown clients and the security of the host.
   Although not mandatory, one could administer the DNS in the following
   way.  The master that processes the dynamic updates is unavailable
   from generic hosts on the Internet, it is not listed in the NS RRSet,
   although its name appears in the SOA RRs MNAME field.  The
   nameservers in the NS RRSet are able to receive zone updates through
   NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism.  This
   approach is known as the "hidden master" setup.

   The ideal situation is to have a one-way information flow to the
   network to avoid the possibility of tampering from the network.
   Keeping the zone master file on-line on the network and simply
   cycling it through an off-line signer does not do this.  The on-line
   version could still be tampered with if the host it resides on is
   compromised.  For maximum security, the master copy of the zone file
   should be off-net and should not be updated based on an unsecured
   network mediated communication.

   The ideal situation may not be achievable because of economic
   tradeoffs between risks and costs.  For instance, keeping a zone file
   off-line is not practical and will increase the costs of operating a
   DNS zone.  So in practice the machines on which zone files are
   maintained will be connected to a network.  Operators are advised to
   take security measures to shield unauthorized access to the master
   copy in order to prevent modification of DNS data before its signed.

   Similarly the choice for storing a private key in a Cryptographic
   Hardware Security Module (HSM) will be influenced by tradeoff a
   tradeoff between various concerns:

   o  The risks that an unauthorized person has unnoticed read-access to
      the private key

   o  The remaining window of opportunity for the attacker.

   o  The economic impact of the possible attacks (for a TLD that impact
      will in most cases be higher than for an individual users).

   o  The costs of rolling the (compromised) keys: whereby the costs of
      roling a ZSK is lowest and the costs of rolling a KSK that is in
      wide use as a trust anchor is highest

   o  The costs of buying and maintaining an HSM.

   For dynamically updated secured zones [11], both the master copy and
   the private key that is used to update signatures on updated RRs will
   need to be on-line.

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Richard Lamb <[email-masked]>
Date: Thu, 21 Jan 2010 09:22:50 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Olaf Kolkman
> Sent: Thursday, January 21, 2010 3:42 AM
> To: dnsop WG
> In trying to get a reasonable version 2 out of the door before Anaheim
> I am trying to identify and where possibly close open issues.
> 
> As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-
> issues/ has the open issues listed and a per issue highlight of their
> history.
> 
> This thread, about the use of HSMs, is captured in
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs the
> content of that page is replicated below.
> 
> I believe I captured the gist of the discussion in a modified version
> of paragraph 3.6 (see below). The first two paragraphs are not
> modified, the text starting with "The ideal situation" has been.
> 

I agree, but I am a strong believer in market driven decisions so, yes, encouraging people to make their own decisions is my preference too.
However I will say that even using a $5 HSM (in the form of a smartcard) forces certain good IT security practices.  The guys that developed this industry have really though through process.

May be out of scope but: Trust in the KSK must still be earned through various mechanisms like publicly documented processes, 3rd party auditing, external witnesses, key ceremonies.

> > certainly prefer a few unauthorized looks to a complete loss).

Agreed.  Read or in the case of an infrequently used KSK (low number of ZSK rolls) - make use of the key.

> AIUI, the attack vector that HSM are designed to protect is that
> someone makes a copy of your key signing material without you knowing
> about it.
> Having said that, I agree that HSM hysteria is a bit overblown, and
> that the actual DNSSEC signing is very, very unlikely to be the weakest
> link in DNS security in any organization.
> 

Agree.

Below looks good.  Take my suggestion or leave it. It is only a minor point and might be implemented on a secured o/s as well.

>    o  The risks that an unauthorized person has unnoticed read-access

, or can sign with,

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Jan 2010 12:52:47 -0500 (EST)

> As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has the open issues listed and a per issue highlight of their history.

I still don't see any recommendations regarding NSEC vs NSEC3. I mailed you
some comments about two IETF's ago I believe. Do you still have that email,
or should I try to dig it out?

> This thread, about the use of HSMs, is captured in http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs the content of that page is replicated below.

That looks fine to me. Perhaps clarify that the "someone" who could make a
copy of your key could be the zone operator, and that in some situations
you might want to trust the zone administrator with the ZSK, allow him to
use the HSM based KSK, but not give him access to read or copy the private
key of the KSK. This would allow one to keep using the KSK even after a
zone administrator has left the organisation.

Paul

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 22 Jan 2010 12:04:07 +0100

> or should I try to dig it out?

That was oversight. In fact I need to close/re read the mail (and follow up thread) on your comments on the other topics. But for the benefit of opening discussion here is the relevant open issue (http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3) including your straw man text for the working group to comment on.

--Olaf

$Id: NSEC-NSEC3 36 2010-01-22 11:02:32Z olaf $
20100122
   NSEC-NSEC3
   Paul Wouters
   Added: 22 jan 2010
   
   Discussion missing about NSEC vs NSEC3 Parameters
   from:
   http://www.ietf.org/mail-archive/web/dnsop/current/msg07282.html

Discussion:

	From: 	Paul Wouters <[email-masked]>
	Subject: 	Comments/Additions on I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt
	Date: 	April 28, 2009 12:23:21 AM GMT+02:00
	To: 	Olaf Kolkman <[email-masked]>
	Cc: 	dnsop WG <[email-masked]>, [email-masked] WG <[email-masked]>

I am furthermore missing a discussion on NSEC vs NSEC3 and NSEC3 parameters.
I've tried to write something sensible that is included below, as a presumed
section 5:

5 Next Record type

There are currently two types of next records that are provide
authenticated denial of existence of DNS data in a zone.

- The NSEC (RFC 4034) record builds a linked list of sorted RRlabels
 with their record types in the zone.

- The NSEC3 (RFC5 155) record builds a similar linked list, but
 uses hashes instead of the RRLabels.

5.1 Reasons for the existence of NSEC and NSEC3

The NSEC record requires no cryptographic operations aside from validating
its associated signature record. It is human readable and can be used in
manual queries to determin correct operation.  The disadvantage is that it
allows for "zone walking", where one can request all the entries of a zone
by following the next RRlabel pointed to in each subsequent NSEC record.

Though some claim all data in the DNS should be considered public, it
sometimes is considered to be more then private, but less then public data.

The NSEC3 record uses a hashing method of the requested RRlabel.
To increase the workload required to guess entries in the zone, the number
of hashing interations can be specified in the NSEC3 record. Additionally,
a salt can be specified that also modifies the hashes. Note that NSEC3
does not give full protection against information leakage from the zone.

5.2 NSEC or NSEC3

For small zones that only contain contain records in the APEX and a few
common (guessable) RRlabels such as "www" or "mail", NSEC3 provides no
real additional security, and the use of NSEC is recommended to ease
the work required by signers and validating resolvers.

For large zones where there is an implication of "not readilly available"
RRlabels, such as those where one has to sign an NDA before obtaining it,
NSEC3 is recommended.

5.3 NSEC3 parameters

The NSEC3 hashing includes the FQDN in its uncompressed form. This
ensures brute force work done by an attacker for one (FQDN) RRlabel
cannot be re-used for another (FQDN) RRlabel attack, as these entries
are per definition unique.

5.3.1 NSEC3 Algorithm

The NSEC3 algorithm is specified as a version of the DNSKEY algorithm.
The current options are:

Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA.
Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5, RSASHA1.

The algorithm choice therefor depends solely on the DNSKEY algorithm
picked.

[Note that there is an issue here as well as mentioned in Section 3.4
regarding RSASSA-PKCS1-v1_5 vs RSASSA-PSS as well as no algorithm choice
for SHA-256]

5.3.2 NSEC3 Iterations

RFC-5155 describes the useful limits of iterations compared to RSA key
size. These are 150 iterations for 1024 bit keys, 500 iterations for
2048 bit keys and 2,500 iterations for 4096 bit keys. Choosing 2/3rd of
the maximum is deemed to be a sufficiently costly yet not excessive value.

5.3.3 NSEC3 Salt

The salt with NSEC3 is not used to increase the work required by an
attacker attacking multiple domains, but as a method to enable creating a
new set of hash values if at some point that might be required. The salt
is used as a "roll over". The FQDN RRlabel, which is part of the value
that is hashed, already ensures that brute force work for one RRlabel
can not be re-used to attack other RRlabel due to their uniquenes.

Key rollovers limit the amount of time attackers can spend on attacking
a certain key before it is retired. The salt serves the same purpose for
the hashes, which are independant of the key being used, and therefor
do not change when rolling over a key. Changing the salt would cause an
attacker to lose all precalculated work for that zone.

The salt of all NSEC3 records in a zone needs to be the same.
Since changing the salt requires the NSEC3 records to be regenerated,
and thus requires generating new RRSIG's over these NSEC3 records, it
is recommended to only change the salt when changing the Zone Signing Key,
as that process in itself already requires all RRSIG's to be regenerated.

5.3.4 Opt-out

An Opt-Out NSEC3 RR does not assert the existence or non-existence of the
insecure delegations that it may cover. This allows for the addition or
removal of these delegations without recalculating or re- signing RRs in
the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible. A
scenario where one of the authoratative nameservers of a zone does not
have enough resources to hold the additional NSEC3 records in memory is
one of very few reasons to deploy with Opt-Out.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Jan 2010 23:09:11 +1100

Additionally NSEC3 provides no real benefit is highly structured zones
like IP6.ARPA.  It is relatively easy to enumerate a IP6.ARPA zone even
if it is using NSEC3 by making use of the zone's structure.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 22 Jan 2010 13:54:04 +0100

> if it is using NSEC3 by making use of the zone's structure.

ACK good point. Maybe we need a little more descriptive about the methodology how the structure can be explored.

--Olaf

---

From: Alex Bligh <[email-masked]>
Date: Fri, 22 Jan 2010 18:04:12 +0000

--On 22 January 2010 12:04:07 +0100 Olaf Kolkman <[email-masked]> wrote:

> sometimes is considered to be more then private, but less then public

That does not describe the problem well, in that (1) it is not
the data that is somewhere between public and private, it is
that the mechanisms of access to that data that change, and (2) it
completely ignores opt-out. How about

	Though all agree DNS data should be accessible through query
	mechanisms, a side effect of NSEC is that it allows the contents of
	a zone file to be enumerate in full by sequential query. Whilst for
	some operators this behaviour is acceptable or even desirable, for
	others it is undesirable for policy, regulatory or other reasons.
	This is the first reason for development of NSEC3.
	
	The second reason for the existence of NSEC3 is that NSEC requires
	a signature over every RR in the zonefile, thereby ensuring that
	any denial of existence is cryptographically signed. However, in a
	large zonefile containing many delegations very few of which are to
	signed zones, this may produce unacceptable additional overhead
	especially where insecure delegations are subject to frequent
	update (a typical example might be a TLD operator with few
	registrants using secure delegations). NSEC3 allows intervals
	between two such delegations to "Opt-out" in which case they may
	contain one more more insecure delegations, thus reducing the size
	and cryptographic complexity of the zone.

> the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible.

1. Therefor*e*

2. I don't think the last sentence follows from the foregoing, in that
   this behaviour is desirable for the zone operator! (I know what
   you mean).

3. Aside from that, I don't think an injunction to avoid Opt-Out in
   these terms is sensible in a delegation only zone. In such a zone,
   I don't really see the additional security risk from opt out across
   insecure delegations, given if a spoof can be done, it can be
   done at the delegated zone level. There are considerable operational
   advantages in Opt Out (zone size, cryptographic complexity etc.)
   for large zones only sparsely populated with secure delegations,
   particularly where few queries have DO set anyway.

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Fri, 22 Jan 2010 18:04:58 +0000

> if it is using NSEC3 by making use of the zone's structure.

e164.arpa. is probably the poster child for this.

-- 
Alex Bligh

---

From: Paul Wouters <[email-masked]>
Date: Fri, 22 Jan 2010 14:51:38 -0500 (EST)

> 	and cryptographic complexity of the zone.

Sounds good.

>  done at the delegated zone level.

If I secure example.org, and .org is signed, OPT-OUT might cause a spoofed
exemple.org to not be caught by the user's validating resolver. Therefor,
I do think opt-out should be avoided when possible.

>  There are considerable operational

I understand zone size, though I don't understand "cryptographic complexity".
Having different "security values" attached to data within the same zone seems
more complex to me, not less complex?

>  particularly where few queries have DO set anyway.

I'd like to avoid circular adoption loop arguments :)

Paul

---

From: Alex Bligh <[email-masked]>
Date: Fri, 22 Jan 2010 20:31:12 +0000

Paul,

> I do think opt-out should be avoided when possible.

If I run .org, which is signed, but example.org is NOT signed (i.e.
is an unsigned delegation), there seems to be little reason to avoid opt out
across it. Whilst it might be harder to spoof the absence or existence
of the delegation, I can still spoof the contents (or absence of
contents) in example.org. So, whilst opt-out should be avoided
across intervals containing secure delegations, I see no reason
to avoid it across intervals that don't contain secure delegations.

> more complex to me, not less complex?

I meant computational resource requirements resultant from crypto
operations, not algorithmic complexity.

The owner names in NSEC3 RRs are cryptographic hashes of the original owner
name. Assume you have a delegation only zone consisting of sparse secure
delegations amongst many insecure delegations. If you are using NSEC3 at
all, using opt-out substantially reduces the number of NSEC3 records (since
many insecure delegations will cluster together within the opt-out
interval) and thus the length of the NSEC3 chain, and hence reduce the
number of cryptographic hash calculations. Similarly the zone itself is
smaller, so less work to sign. The situation is exacerbated where the
insecure delegations are volatile.

It might be worth mentioning (but is perhaps blindingly obvious) that
NSEC3 is substantially more complex in terms of implementation than
NSEC. Whilst one can by visual inspection spot the odd problem with
a small zone's NSEC chain, it's far harder with NSEC3. Obviously, if
a tool chain is used to NSECify and sign the zone, that's a problem
for the implementor rather than the operator.

-- 
Alex Bligh

---

From: Edward Lewis <[email-masked]>
Date: Fri, 22 Jan 2010 15:45:54 -0500

>to avoid it across intervals that don't contain secure delegations.

Opt-out is restricted to "intervals" that contain only unsecured delegations.

RFC 5155:
6.  Opt-Out
... (first paragraph's last sentence):
    name of the delegation.  Setting the Opt-Out flag modifies this by
    allowing insecure delegations to exist within the signed zone without
    a corresponding NSEC3 RR at the hashed owner name of the delegation.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 22 Jan 2010 20:54:20 +0000

> Opt-out is restricted to "intervals" that contain only unsecured

Doh! Yes indeed. In which case I stand by my original argument: I can't
see how opt-out really increase spoofability. It can't affect
a secure delegation, and the contents of an insecure delegation
or denial thereof (if not the delegation itself) are spoofable
with or without opt-out. Paul's example of a secure delegation
with opt-out across it can't exist.

-- 
Alex Bligh

---

From: Paul Wouters <[email-masked]>
Date: Fri, 22 Jan 2010 19:01:38 -0500 (EST)

> If I run .org, which is signed, but example.org is NOT signed (i.e.

I was talking about the situation where example.org is signed, the .org
is optout and exemple.org does not exist. For many, it is impossible
to register all typo-squat domains, so this is a real scenario.

> across it.

Having verifiable deniability for typo-squated domaims is very useful.

> operations, not algorithmic complexity.

I had no problems doing this on a 1.2M domains TLD zone, using off the
shelf hardware, integrating into the TLD's hourly update interval.
(http://www.cira.ca/dnssec/)

The only issues encountered were indeed the increased memory usage
on the nameservers, but those can still run fine on commodity hardware.
Though I recommend 64bit to avoid and 3G or 4G memory allocation per 
process issues.

> for the implementor rather than the operator.

Commercial and free tools are readilly available.

Paul

---

From: Alex Bligh <[email-masked]>
Date: Sat, 23 Jan 2010 04:56:33 +0000

Paul,

> to register all typo-squat domains, so this is a real scenario.

Ah, didn't spot the 'e'.

> Having verifiable deniability for typo-squated domaims is very useful.

If expensive, where 99% of your domains are unsigned.

> Though I recommend 64bit to avoid and 3G or 4G memory allocation per

And on a 100M TLD zone that needs near real time updates? I don't
know whether zone growth predictions exceed Moore's law or vice
versa, to see whether this is a growing problem or not. I agree
that the computational complexity argument is a minority problem.

> Commercial and free tools are readilly available.

Sure. Just rehearsing an argument I've heard others use against NSEC3.

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Sat, 23 Jan 2010 05:06:50 +0000

> If expensive, where 99% of your domains are unsigned.

By which I mean expensive given this isn't the cheapest attack vector.
If I want to typo squat with a non-existent domain (and it's only
non-existent domains where verification of denial of existence is
an issue), I could just register the domain which would be far
more reliable than all the hocus pocus needed to get spoofing to
work. It's not that hard to get an SSL cert either. And if I
have got the technology to spoof, why not attack one of the 99%
unsigned domains in the zone, rather than an unregistered typo-squat
of a signed one, as the pickings will be far greater?

-- 
Alex Bligh

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 23 Jan 2010 12:25:00 -0500

At 15:54 22/01/2010, Alex Bligh wrote:

>--On 22 January 2010 15:45:54 -0500 Edward Lewis <[email-masked]> wrote:
>

Lets say example is signed, bank.example is signed using NSEC3 with opt-out
in one span to hide one division.
Lets say secure.bank.example by co-incidence falls into the opt-ed-out gap.
Now a phisher can attempt to insert an insecure delegation called 
secure.bank.example
into caches and send mails telling people to visit this site to claim 
their price

Opt-out was designed for large delegation-only/mostly zones, in almost all
other cases it should not be used.

The use of NSEC vs NSEC3 in zone is a different discussion.

A zone that contains guess-able names gains almost nothing from using NSEC3.
A zone operator may still feel better using NSEC3 :-)
If you really want to hide the content of your zone only epsilon 
signing will work
RFC4470+RFC4471.

         Olafur

---

From: Alex Bligh <[email-masked]>
Date: Sat, 23 Jan 2010 18:16:15 +0000

> other cases it should not be used.

And this was the only use case I was suggesting was excepted from
the blanket "should not" (in fact I went further and said it should
only apply to large delegation-only/mostly zones where secure
delegations were sparse).

-- 
Alex Bligh

---

From: Matt Larson <[email-masked]>
Date: Sat, 23 Jan 2010 20:00:17 -0500

> (http://www.cira.ca/dnssec/)

Try 100M delegations, updated every 15 seconds, and sending the
resulting large non-Opt-out zone to places with poor connectivity such
as Nairobi, Kenya.

Arguments such as "I did it on once on commodity hardware with freely
available tools" or "you can implement that in an afternoon" do not
transfer well to large, critically important TLDs (or any large-scale,
critical service).

Matt

---

From: [email-masked]
Date: Sun, 24 Jan 2010 04:30:01 +0000

> transfer well to large, critically important TLDs (or any large-scale,

	to be honest, there are a few more delegation points that fit the
	1.xM domains using cots technology than there are delegations that
	have delegations with 100M+ entries and running dynamic udates.

	on more than one occasion (perhaps first at the IETF in SLC) I have
	heard folks who would like the business model of such a delegation 
	refer to it as "a goiter on the neck of the DNS" in envy.

--bill