Subject: [dane] an implementor's comments on DANE

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 06 Oct 2012 11:16:13 +0200

Hello,
 In this mail I list the issues I noticed while implementing DANE. No
matter the direct language they are comments in good faith. They may be
wrong because of my misunderstanding of the protocol, so feel free to
correct me if this is the case.

I think that DANE is _too_ complex for its purpose.

1. DANE does not imply DNSSEC, and verified using DANE may mean nothing.
Why? Is there any reason not to require DNSSEC? How would a user that
uses DANE over DNS and a user that uses it over DNSSEC understand the
difference? What is the added value of using DANE over DNS? The RFC
claims that there is no harm, but there is no reason either and in
addition it introduces issues due to misconfiguration. Bottom line: DANE
w/DNS adds no additional security and has the risk of verification false
positives due to misconfiguration, so IMO no point for it.

(DANE w/DNSSEC also introduces the risk of misconfiguration _but_ it
adds additional security if configured properly)

It is also a marketing issue. DANE should mean something better than
before (i.e. dnssec), not just the same thing as before with a new name.

2. Too many certificate usage fields to indicate the _same_ thing.
It is nice to see that there is a document (RFC6394) describing DANE
real-world use-cases, but then the main protocol instead of defining a
single protocol to cover all use cases, it makes several subprotocols
for each use case. There are 4 certificate usage fields but only 2 of
them are actually different.

Certificate usage 0 is exactly the same as 2, and usage 1 is the same as
3. The difference is that if my certificate is signed by a CA I use 1,
but if the CA signature expires but I don't renew I have to notify the
DNS administrator to change it to 3. That's quite interesting. What is
that for? So that the user knows that my certificate is expired? He
already knows that.

The same if I have a self-signed certificate that one can verify using
DANE. If I decide to buy a signature from a CA to increase security, I
actually create confusion for the users of DANE. Users of DANE would see
the certificate usage 3 in my public key, and what should they think?
That they are under attack, or that 3==0 and that this is a common
misconfiguration?

3. Too many options for the selector field.
Note that having more options is not better, it is worse because of
incompatibilities. People will ignore DANE verification due to the many
false positives. Why allow _both_ full X.509 and SubjectPublicKeyInfo
fields? What is the advantage? The answer is none. You could also have
allowed raw RSA keys, raw RSA keys that have e and m reversed and so on.
But more options do not add additional security.

My suggestion would be to simplify DANE by having a profile that is
simple to implement and understand its purpose. That is:
* Restrict DANE only with DNSSEC. If there is no DNSSEC, then there no DANE.
* Deprecate usage fields 2 and 3. The serve no real purpose.
* Only allow selectors for SubjectPublicKeyInfo.

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 6 Oct 2012 16:03:25 +0300

On Sat, Oct 06, 2012 at 11:16:13AM +0200, Nikos Mavrogiannopoulos wrote:
 
> Why? Is there any reason not to require DNSSEC?

DANE (at least as documented by the RFC 6698) _does_ require DNSSEC.
RFC 6698, Section 4.1.

> 2. Too many certificate usage fields to indicate the _same_ thing.

Nope, no two certificate usages are the same.
 
> that for?

Nope, those are not the same. E.g. usage 1 _requires_ performing PKIX path
validation, whereas usage 3 does _not_ require path validation.

(In fact, usage 3 is by far the simplest one to implement; does the
EE cert slot match one of these, yes/no).

You can use 2/3 even if your certificate is signed by public CA. 
You just likely won't get any indications of security above DV level.

0/1 are only really useful if you have a OV or EV certificate.

> the certificate usage 3 in my public key, and what should they think?

If the usage 3 entry matches, ignore your CA certificate and proceed with
the connection.

If those don't match, consider other entries as usual (if none matches,
reject the connection).

Of course, if your CA certificate is EV (or OV), you only get DV security.

> fields? What is the advantage? The answer is none.

This goes to dark territories of PKIX, but sometimes certificates are
internally replaced without changing then SPKI.

As to being able to bind to full certificate, there may be some advantage
under rather contrived scenarios. But it is simpler to implement, since
you won't need to even rip the SPKI out of the certificate...

> You could also have

There selectors truly do not add anything and are thus not there.

In contrast, SPKI is always a proper substring of the certificate, and
there is no room for interpretation how it should be put together given
certificate.

If there ever will be a raw RSA key type (seems unlikely, as it would
require TLS WG to standardize a raw RSA key type), it will be its own
usage, not its own selector.

-Ilari

---

From: Scott Schmit <[email-masked]>
Date: Sat, 6 Oct 2012 09:32:01 -0400

> 1. DANE does not imply DNSSEC, and verified using DANE may mean nothing.

Incorrect. Re-read section 4.1. If you don't understand the DNSSEC
states cited there, you're going to need to read RFC 4033.

> 3.

They aren't. 0 & 1 validate against your client's trust anchors. 2 & 3
do not.

If we didn't have 2 & 3, then self-signed certificates cannot be used
with DANE. If we didn't have 0 & 1, then certificate revocation and
trust anchor changes would be ignored. (Think DigiNotar.)

Different people care about different things.

> If I decide to buy a signature from a CA to increase security, I
> actually create confusion for the users of DANE. Users of DANE would
> see the certificate usage 3 in my public key, and what should they
> think?  That they are under attack, or that 3==0 and that this is a
> common misconfiguration?

Ignoring whether an end-user should ever be exposed to this level of
detail, they should think that the person configuring the record used a
CA for compatibility with non-DANE clients but doesn't put a lot of
trust in the CA they got their certificate from. Also, maybe, they serve
clients that don't have their CA in their trust store, so they might be
hoping that using 3 lets them reach a few more people without trouble
(I don't think any CA is in 100% of clients -- I usually see 9x.x%
numbers).

> incompatibilities.
Incompatiblities?

> People will ignore DANE verification due to the many
> fields?

Because:
(full X.509) fields other than the SubjectPublicKeyInfo affect X.509
validation, so being able to prevent them from changing may be important
to you.

(SPKI only) transvalidity is evil, but an unfortunate reality.
Sometimes I can't be sure of anything but the key.  See Appendix A.1.

Hope this helps,

-- 
Scott Schmit

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Oct 2012 08:07:18 -0700

Ilari made some good comments, but I need to emphasize one thing:

> allowed raw RSA keys, raw RSA keys that have e and m reversed and so on.

If those ever become valid ways to authenticate TLS sessions, we expect to add those to DANE. We said as much, multiple times, on the mailing list.

--Paul Hoffman

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 07 Oct 2012 09:04:46 +0200

> DANE (at least as documented by the RFC 6698) _does_ require DNSSEC.

At least 3 host names in the list of DANE test sites do not use DNSSEC.
http://www.internetsociety.org/deploy360/resources/dane-test-sites/

> validation, whereas usage 3 does _not_ require path validation.

Well, my point is that they transfer exactly the same data. 0 transfers
an end-entity certificate and so does 2. They differ, as you say, on
what the receiving party does on that data. Why bother? How would a
server operator ever know what the receiving party will do on the data?

Let's say I'm on an company that has it's main web site signed with a CA
certificate that is installed on all employees computers. Do I use 0 or
2? All employees perform PKIX path validation so it should be 0. Now you
connect to this site, but you don't trust this CA. So it should have
been 2, or both?

PKIX path validation is a process that runs on the client and the server
has no indication whether it will actually occur, or that it  will share
a common trusted party at all. DANE would help in the cases the peers do
not share a common trusted party by providing an indication of the
identity of peer. However, the DANE protocol goes to extremes only.
Either the server shares nothing with no-one (self-signed), or shares a
CA with everyone. Reality is somewhere between those extremes.

What the writer of the RFC may have meant, is whether you do a
verification against the commercial CA set in a browser. However, this
set varies from browser to browser and scenarios like the one above will
occur.

> 0/1 are only really useful if you have a OV or EV certificate.

OV or EV are pretty much marketing terms, they shouldn't have been
considered in a protocol.

> If the usage 3 entry matches, ignore your CA certificate and proceed with

Doing that I would reduce the security of the connection. By ignoring
the CA certificate I put the trust on the DNS administrator only. My
goal as an implementor of DANE is to disperse the trust to various
parties and warn the user of any discrepancy. With the mix or 0,2 and
1,3 I see many cases of false alarms and eventually users disabling the
DANE verification.

> internally replaced without changing then SPKI.

Indeed, and this is why only the SubjectPublicKeyInfo should have been
defined.

Now several DANE tools support only the X.509 format but not the
SubjectPublicKeyInfo. I expect other tools from other implementors to
only support the SubjectPublicKeyInfo (we had this in other protocols),
just to be incompatible with them.

Not to mention misconfigured servers that indicate a
SubjectPublicKeyInfo, but send an X.509 hash.

Those are not things that typically occur in a _new_ protocol like DANE.
You see these in a 10 year protocol with a gazillion of options added
through the years. DANE has already too many in its first incarnation.

> you won't need to even rip the SPKI out of the certificate...

Does it really worth it? Was it like 3 lines of code saved, at the cost
of an extra protocol option? Now as a library author, I had to implement
_all_ cases actually coding much more than if only one of the
SubjectPublicKeyInfo or X.509 had been defined.

> There selectors truly do not add anything and are thus not there.

They add the same as X.509 adds to SubjectPublicKeyInfo (or vice-versa).
That is nothing indeed.

regards,
Nikos

---

From: Scott Schmit <[email-masked]>
Date: Sun, 7 Oct 2012 11:31:33 -0400

> server operator ever know what the receiving party will do on the data?

How does any server operator deploy a TLS-protected site if they don't
know what trust anchors their users have available? Today, without DANE,
if you deploy a TLS service and don't pay attention to that, you're
going to get complaints from (some subset of) your users about
certificate errors (or they aren't being checked at all, which isn't
exactly secure).  All CA certificates are not equal.

> connect to this site, but you don't trust this CA. So it should have

If you expect only your employees to connect, then 0.  If it's facing the
public and you want them to be able to use it, then 2.  This is no
different than the decisions you had to make when chosing a CA in the
first place.

This is the same as asking "but what CA should I use for my web site?"
When I go to get a certificate from a CA, they all talk about being
trusted by X% of web browsers, and/or name the browser platforms they
are trusted by.  If your users have the CA in their trust anchor sets
(however that is, whether by local customization or because the clients
have done it for you), then use 0/1. Otherwise, you'll need to use 2/3
or it won't work in some percent of cases.

> CA with everyone. Reality is somewhere between those extremes.

You can always deploy like so:
example.com. IN TLSA 0 0 1 .....
example.com. IN TLSA 2 0 0 .....

If the cert is in their trust store, the first record will work (so will
the second, but will either never get used or get used 50% of the time,
depending on the implementation).  If it's not in their trust store, only
the second will work, but it will work.

I'm not sure how we could have done better--CA certificates are either
trusted or not, there is no in between.  Do you have a proposal, other
than to cut options which would (apparently) make us even more extreme?

> set varies from browser to browser and scenarios like the one above will

DANE is complicated by the fact that PKIX is complicated.

> considered in a protocol.

Who said they were?  You aren't reading very carefully--he said "likely
won't" -- this is all up to the people defining OV/EV, which isn't the
IETF.

> 1,3 I see many cases of false alarms and eventually users disabling the

Read (or reread) Section 8.  If you think that 0/1 isn't putting trust
in the DNS admins I suggest you look into what it takes to get a
certificate from a CA.

> through the years. DANE has already too many in its first incarnation.

You aren't the only one looking to deploy this.  DANE is more complex
than I'd like because PKIX and the reality of its deployment is more
complex than I'd like.  DANE may be new, but PKIX is not.

-- 
Scott Schmit

---

From: Paul Wouters <[email-masked]>
Date: Sun, 7 Oct 2012 15:11:40 -0400 (EDT)

> http://www.internetsociety.org/deploy360/resources/dane-test-sites/

The fedoraproject.org and nohats.ca one require you enable DLV to get
a full DNSSEC chain that can be validated.

> Indeed, and this is why only the SubjectPublicKeyInfo should have been

I tried :)

Paul

---

From: John Gilmore <[email-masked]>
Date: Mon, 08 Oct 2012 18:39:54 -0700

> http://www.internetsociety.org/deploy360/resources/dane-test-sites/

Then it's a good thing that we're testing that case, isn't it?  :-)
DANE implementations should refuse to connect to those test sites,
which don't have DNSSEC signatures all the way back to the root key.
(The fact that DANE should fail with them should be mentioned in that
page tho.)

> server operator ever know what the receiving party will do on the data?

This is a protocol.  It defines what both parties do -- not just
one party.  Two parties interoperate in a protocol when BOTH implement
it correctly.

The whole reason for the "duplication" in certificate usages is to
protect the business models of the CA operators.  For 98% of web
sites, there is no real need for usage 0 or 1 or 2.  Just use 3 and
the DNS will let your TLS application know that it can trust the
public key that the TLS server provides.  Indeed, the CA companies
tried to kill off usage 3 -- and succeeded to the extent that you have
to read between the lines of a complicated RFC to figure out that you
don't need the CAs anymore.

You can continue to pay a CA for your TLS server's cert, so that
clients who don't implement DANE can still access your server with the
same security that you and they had last year.  But any client that
does implement DANE will just use your "usage 3" TLSA record, will
ignore the CAs, and will have higher security.

But the CA companies can say, "Use DANE with our certificates" and
still sucker a bunch of businesses into paying them $$$$$ that they
don't need to pay, for security that isn't really there.  And indeed
DANE does provide a way to improve the security of the CA model, by
limiting the number of CAs who can betray you, from hundreds down to
one.  Of course, if you use DANE with usage model 3, NONE of the CAs
can betray you to a DANE client -- but they won't tell you that.

By the way, you're confused about which cert usage numbers do what.
The TLS server always sends the client a chain of certs, containing at
least one cert.  The client only has to pay attention to the first of
those, which is the "end-entity" cert for this TLS server.  The rest
are "hints" about how the client might determine whether to trust that
"end-entity" (TLS server's) cert.  Unfortunately the process that the
client goes through is undocumented and unstandardized and will remain
so for business reasons (different clients do it differently and none
of them wants to be declared non-compliant).  They all rely on "trust
anchors" which are keys that are inherently trusted by that particular
client, usually because those keys were installed automatically along
with its OS or along with its browser.  DANE provides three ways to
*modify* that undocumented process, and one way to bypass it
completely:

  0 = I'm telling you one of the PKIX CA certs (or its key)
  1 = I'm telling you the PKIX end-endity cert (or its key)
  2 = I'm giving you a PKIX cert that provides a new trust anchor (or 
      a key of one that the server sent in its chain)
  3 = I'm telling you the non-PKIX key or cert of this TLS server.

3 is the complete bypass of the PKIX hierarchy of certs.  0,1,2 all
use the PKIX certs and require that the TLS connection fail if the
undocumented PKIX client processing says "insecure".  They also require
that the TLS connection fail if PKIX says "secure" but its ultimate
trust-chain doesn't match any cert or key that DANE provides.  (That's
DANE protecting you from corrupt CAs.)

Normally, usage 2 does NOT use an end-entity cert.  There's a way to
bastardize usage 2 by providing the end-entity cert or key as the
"trust anchor", but that's just a slow way to do usage 3, so there's
no point to it.  What it's really for is to provide a CA "trust
anchor" certificate that you don't expect clients to already trust.
For example, IBM might run its own CA for all its internal machines,
and could provide this CA's trust anchor cert in its internal DNS with
DANE usage 2, rather than having to reconfigure every machine in its
network to add a trust anchor manually.

	John Gilmore

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 9 Oct 2012 09:04:38 +0200

> one party.  Two parties interoperate in a protocol when BOTH implement

Indeed, but DANE is not a verification protocol. It defines (or should
define) a _part_ of a verification protocol. And this should be
because DANE can be used in many more scenarios than the typical web
browser HTTPS scenario which is implied all over the document. The
"PKIX certification path validation" that is mentioned in the document
happens (or not) in those browsers irrespective of DANE, so there is
no point for DANE to mandate it. What DANE provides is an alternative
method to this path verification. It can be used in addition to path
verification or instead of it. The server operator shouldn't care or
bother how each client would use it (eg. by specifying usage 1 or 3).
He should only specify the key of its server.

> sites, there is no real need for usage 0 or 1 or 2.

Ok thanks for providing some context. The reason of the bloat in the
usage field is now apparent.

best regards,
Nikos

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 09 Oct 2012 01:07:41 -0700

> He should only specify the key of its server.

This is awfully late to raise an objection.  I believe the argument for
the current design was that a server operator may care: he may want a
revocation via the CA to be effective on DANE clients without having to
also pull the certificate from the DNS, particularly if he has to revoke
via the CA anyway for the benefit of non-DANE clients.  To ensure this,
he has to use usage 1 rather than 3.  (Or for an intermediate
certificate, usage 0 rather than 2 for revocations at or above the
intermediate certificate to be effective.  Revocations below the
intermediate certificate break the chain from the server certificate to
the RR, so they are effective under either usage.)

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 9 Oct 2012 13:14:56 +0100

John,

Your model for why people buy certs is completely wrong.

The biggest cost in providing SSL certs is training the customer how to use
and deploy them. An SSL cert is a heck of a lot cheaper than a course on
PKI. The typical cost of training is $800 per person per day. How many days
does it take to know enough crypto for it to be more good than harm?
Probably more than one.

DNSSEC deployment is far, far beyond the capabilities of the average
Internet user. It is also far beyond the capabilities of the typical ISP.
We both have more than twenty years experience using this stuff and neither
of us is signing our emails, that should say something about the
technology. Attacking the service industry that supports crypto does
nothing to advance the cause of making crypto ubiquitous, quite the reverse.

Those DNS registrars that you hope are going to provide free crypto to the
masses are what CAs call their sales channel. Selling DNS names is not a
profitable business, most are sold at a loss in order to acquire customers
that the registrar then monetizes though sales of added value services, in
particular SSL certificates.

>From a security point of view, I think the whole approach taken in DANE is
wrong. It regards security policy statement as commands from the server to
the client rather than as evidence that a client MAY chose to evaluate in
making a security decision.

No client is going to interpret the DANE MUSTs as mandates no matter how
hard people stamp their feet. The client providers refuse to deploy
software that hardfails on OCSP status requests despite a considerably
cleaner path to the client than is available in the DNS world.

On Tue, Oct 9, 2012 at 2:39 AM, John Gilmore <[email-masked]> wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

-- 
Website: http://hallambaker.com/

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Oct 2012 10:50:36 -0400 (EDT)

On Tue, 9 Oct 2012, Matt McCutchen wrote:

> also pull the certificate from the DNS

Why would you _ever_ want to keep a revoked key in the DNS? If the key
is revoked, it should not be in use, and therefor should not be in the
DNS. While you will still need to revoke the key at the CA, because
someone else might have a stolen copy of your private key and not be
DANE aware, that's the slow offline process that in no way has to slow
down your key update mechanism inside your own DNS tree.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Oct 2012 11:09:06 -0400 (EDT)

On Tue, 9 Oct 2012, Phillip Hallam-Baker wrote:

> The biggest cost in providing SSL certs is training the customer how to use and deploy them.

I could not have summarized the failure of the CA industry better.

If they had made $5 certs for everyone, we would have never seen the
explosion in people using unvalidatable self-signed certificates.

DANE is indeed a method where obtaining the validation is totally free,
and it does not raise the bar for any non-enterprise that cannot afford
a training budget.

> An SSL cert is a heck of a lot cheaper than a course on PKI.

The fact that one would need a course on PKI to secure one's webserver
is a pretty bad failure of the security industry. We're paying the price
now (and offloading that mostly to the browser vendors to fixup in gui
elements)

> The typical cost of training is $800 per person per day. How many days does it take to know enough crypto for it to be more good
> than harm? Probably more than one.

I would cost me $800 to go on a locksmith course for one day, yet I can
easilly buy a lock or cylinder and install it myself. All one needs is
knowledge of a generic tool such as a screw driver.  Another example
would be getting my drivers license, which was far cheaper then the
price of my car.

> DNSSEC deployment is far, far beyond the capabilities of the average Internet user.

Funny, because these days signing your zone takes 4 commands you don't
have to understand, and one more website visit to get your DS published.

(Willing to give a 5 minute / 2 slide training at ICANN Toronto for less then $800)

> We both have more than twenty years experience using this stuff and neither of us is signing our emails, that should say something about the
> technology.

no it says something about the value of signed emails. A few months ago I
had to use SMIME for the first time ever. With thunderbird this took me
about an hour (most time wasted on a website's interface for validating
my generated cert). It also took one person to spend a little more time,
and writing up a simple step by step manual. It did not take a full day
course (nor knowledge of crypto - anything more then "red wax dot means
your software signed the email"

> Those DNS registrars that you hope are going to provide free crypto to the masses are what CAs call their sales channel. Selling DNS names is
> not a profitable business, most are sold at a loss in order to acquire customers that the registrar then monetizes though sales of added value
> services, in particular SSL certificates.

If only they had started to give away free SSL certs 10 years ago, and
perhaps by now port 443 would be the default instead of port 80. Forgive
me for not having much sympathy for the CAs economic struggles.

> From a security point of view, I think the whole approach taken in DANE is wrong. It regards security policy statement as commands from the
> server to the client rather than as evidence that a client MAY chose to evaluate in making a security decision. 
> 
> No client is going to interpret the DANE MUSTs as mandates no matter how hard people stamp their feet. The client providers refuse to deploy
> software that hardfails on OCSP status requests despite a considerably cleaner path to the client than is available in the DNS world.

That could be said for any MUST in any Security Considerations RFC
section.  We set out to write what's best. If local policy dictates
shooting yourself in the foot, we can at best help you not pull the
trigger again.

Paul

---

From: John Gilmore <[email-masked]>
Date: Wed, 10 Oct 2012 01:24:46 -0700

> Selling DNS names is not a profitable business...

There's no need to pick apart Phillip's message in detail.  Let's just
pick that one phrase apart, and leave the rest behind.  It happens to
be something I know something about.

I guess everybody wants to "lose money" selling DNS names, since when
ICANN offered people the chance to sell names in their own TLD, only
1,930 applications arrived, at a non-refundable $185K apiece, bringing
in only $357 million, completely on speculation, long before ICANN
would promise them ANYTHING.

Even before the gTLD goldrush, ICANN certainly seemed to raise and
spend a pile of money selling DNS names.  The Internet Society
certainly has a *lot* more money since they won the ICANN "lottery" to
run the .ORG domain.  (I used to be on their board, back when
fundraising was a significant issue for them.)

I personally started a domain name business (Moniker) and was closely
involved in starting up the CORE registry and working out all the
details among the CORE registrars, most of whom went on to become
ICANN registrars.  The costs involved in *providing* domain name
service are fixed and trivial compared to most businesses.  People are
basically buying small numbers of bits on a disk drive from you.  The
prices are more than a dozen times the total costs.  And the costs are
spread over a huge volume of registrations, which has been created by
domain-name speculators (which of course the registrars/registries
have taken pains to encourage).  In .COM with 100,000,000 domains, it
should cost a few cents a year to handle a domain registration;
in other domains, perhaps a dime.  And the cost of servers and
storage is going... down.  See for example:

  http://www.solorwell.com/ex-icann-board-member-verisigns-cost-per-domain-is-014/
  http://web.archive.org/web/20070409034330/http://dev.blog.domaintools.com/2007/04/ex-icann-board-member-says-com-costs-014/

Now it's possible for incompetent or corrupt businesses to waste even
a 1200% profit margin -- not to name any names or anything.  But if
there was actual competition in domain names, they would retail for
something like 30c/year rather than $10-20 per year.  The incentives
of everyone inside the domain business are to keep prices high, not to
lower them.  Normally, competition would restrict that behavior, but
look at what they're selling: monopolies on virtual real estate.  The
ultimate rulemaker is a corrupt nonprofit monopolist that is
accountable to exactly nobody (I know the lawyer who set up its
structure; that was their main goal, and they largely succeeded), that
sets its own prices.  ICANN sets a base price per domain by charging
registries 25c per domain, which is already 2x to 20x the actual costs
at the registry.  100 million .com's bring ICANN 25 million dollars -
every year - for the "service" of having your input ignored by the
ICANN insiders.  At each level below ICANN, those obscene prices only
get multiplied more (e.g. $6+ at VeriSign) -- and oh, they hate it all
the way to the bank.

	John

---

From: Warren Kumari <[email-masked]>
Date: Wed, 10 Oct 2012 10:53:37 -0400

[ Top-post ] 

…and we've finally gone sufficiently off-topic that I'm (unfortunately) going to jump in and ask that we take this elsewhere…

W