Subject: [keyassure] Charter discussion - Use of DNSSEC in applications

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Aug 2010 11:17:30 -0400

I disagree with the statement in the proposed charter

We have a pki infrastructure that has certain capabilities and certain
limitations. We have the expectation of a dnssec infrastructure with
other capabilities and limitations

I am not too interested in just re-doing the features already
supported in existing pki at lower out of pocket expense

What we should do here is to work out how we can use dnssec plus pki
to move beyond current capabilities. In particular.

* ubiquitous encryption
* downgrade attack prevention
* best possible security

Of course getting rid of the out of pocket expense is a necessary
condition for ubiquitous crypto. But you are only going to get a
limited amount of security for free.

I want to make EV certs work well with Dnssec as an option. If 100% of
Internet traffic is encrypted, people may start to see the value of
the service that CAs really provide.

I don't agree with the idea that a single root of trust is desirable
or provides any advantage whatsoever. It is one of the features we
need to fix. The Internet is a network of peers, not serfs. The Icann
scheme has it's uses but it does not have to be the only scheme people
are allowed to use.

I am my own root of trust. And that is what everyone else should demand.

As a practical matter we can't escape from x.509 entirely. Ssl is set
up to use certs. We will do much better to put certs or cert hashes in
the dns than raw keys. If we use raw keys we then have to do much More
drastic revision to ssl libraries. We have to recode both the client
and the server rather than just the client. I hate asn1 as much as
anyone, but it's no real pain to wrap a key as a self signed cert.

We should look to make the best system we can, not simply replicate
what already exists for cheap.

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

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 08:40:07 -0700

> scheme has it's uses but it does not have to be the only scheme people

Yet at the same time you argue that the CA vendors provide something?  This seems strange.  You MUST HAVE either a set of trust roots (any PKI) or a notion of consensus (PGP) or a leap-of-faith (ssh).  

DNSSEC and CA's are "trust root" models.  Face it, because its a trust root model, you must have, well, a trust root.  You might be able to hack a consensus model onto DNSSEC, but that would be difficult, especially since normal DNS already has a trust root model in operation.

But if you are going to have a trust-root, you really only want a single point or single possible path of trust, because of attacks on the CA infrastructure itself.  With a gazillion roots of trust, and roots of trust willing to delegate completely given enough money (eg, the Verizon provided Etisalat * cert [1]), the system is weak.

And thus the big advantage of DNSSEC over other PKIs, other than cost (EG, CA vendors charge $150+ for *.mydomain wildcards, which is just highway robbery) is that the trust path is limited: the trust path for things in mydomain.com ONLY depend on mydomain.com, .com, and .: there's no longer the case that MY ssl infrastructure is trivially vulnerable because Verizon's division decided to sign a * cert for the UAE.

[1] (https://www.eff.org/deeplinks/2010/08/open-letter-verizon)

---

From: Mike Helm <[email-masked]>
Date: Wed, 18 Aug 2010 09:11:39 -0700

> Yet at the same time you argue that the CA vendors provide something?  This seems strange.  You MUST HAVE either a set of trust roots (any PKI) or a notion of consensus (PGP) or a leap-of-faith (ss…

I see 2 (or maybe 3) problems, which themselves are probably
anchored in the interpretation of trust.  From the relying party
point of view, 

1 - DNSSEC can tell me who owns some DNS data, like an assertion about 
a hostname.  I don't think I know any more than that.  That's pretty
important, but

2 - X.509 certificates could tell me a lot more about what I can expect
from the transaction I am starting.  It can deliver a level of assurance
attribute, a policy pointer of some kind that can lead to a complete
disclosure of what this certificate means, and other attributes that
describe what this certificate is supposed to permit or deny.  I don't
think this is available in DNSSEC.  We can argue about the utility of 
some of this but that's not the issue.

Another way of looking at it - this should be up the stack & closer to
the application's viewpoint than DNS is (should be).  So perhaps

3 - SSL/TLS is bit trapped. Current best (or typical) practices for hosts
seem to be to focus on the domain owner to give permission for certificates
to be issued.   Sometimes this is very counterproductive - the domain owner
might be a network engineer largely univolved with the application that
needs TLS.  Skipping a long argument, we can liberate SSL/TLS from trying to take
the place of DNSSEC - DNSSEC can manage the host name accountability, 
& TLS / SSL certs can focus on managing the application accountability.
This is not going to be a perfect separation but it looks useful.

There is going to be a place for 3rd party certificate signers.
There is also going to be a place for self-signed certificates
whose integrity (not necessarily trust) is guaranteed by a relationship
with DNSSEC-secured data.

My perspective comes from the grid - academic research distributed computing
world where we need more of this flexibility.  (Say what you may about that.)

Thanks, ==mwh
Michael Helm
ESnet/LBNL

---

From: Stephen Schultze <[email-masked]>
Date: Wed, 18 Aug 2010 12:22:39 -0400

On Aug 18, 2010, at 11:40 AM, Nicholas Weaver wrote:
> Yet at the same time you argue that the CA vendors provide  
> something?  This seems strange.  You MUST HAVE either a set of trust  
> roots (any PKI) or a notion of consensus (PGP) or a leap-of-faith  
> (ssh).
>
> DNSSEC and CA's are "trust root" models.  Face it, because its a  
> trust root model, you must have, well, a trust root.  You might be  
> able to hack a consensus model onto DNSSEC, but that would be  
> difficult, especially since normal DNS already has a trust root  
> model in operation.
>
> But if you are going to have a trust-root, you really only want a  
> single point or single possible path of trust, because of attacks on  
> the CA infrastructure itself.  With a gazillion roots of trust, and  
> roots of trust willing to delegate completely given enough money  
> (eg, the Verizon provided Etisalat * cert [1]), the system is weak.
>
> And thus the big advantage of DNSSEC over other PKIs, other than  
> cost (EG, CA vendors charge $150+ for *.mydomain wildcards, which is  
> just highway robbery) is that the trust path is limited: the trust  
> path for things in mydomain.com ONLY depend on mydomain.com, .com,  
> and .: there's no longer the case that MY ssl infrastructure is  
> trivially vulnerable because Verizon's division decided to sign a *  
> cert for the UAE.

It seems that you both can be right.  I certainly agree with PHB's  
statement that each system has its benefits and weaknesses, and the  
goal of keys-in-DNS is not to completely supplant the CA model.  The  
benefit of a DNSSEC-based model is that it provides trust in  
authenticating the controller of a domain name, at which point you can  
bootstrap to additional trust provided by CAs or others ad needed.   
One key advantage, as Nicholas observes, is excludability in the first  
step of trust.  PHB would like to also give flexibility to end-users  
to specify additional or alternative TAs within DNS.  Perhaps this  
will be useful for some entities that maintain large public zones, or  
their own internal zones, or for other purposes.  If users choose to  
add other TAs, it seems that should be permitted as a matter of  
technology and policy (we saw this with the DLV).  They do so with the  
conscious understanding that they are trusting an additional/different  
authority (either at the root or an intermediate node), which is far  
better than the current system in which arbitrary unknown SubCAs exist  
in the wild.

  I personally think it most likely that the vast majority of users  
will have just the one signed root TA for DNSSEC trust, but I don't  
see how it's productive to argue over whether this will be the case in  
general.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Aug 2010 12:39:22 -0400

> the application's viewpoint than DNS is (should be).  So perhaps

It seems to me that this distinction is one on which we foundered
during the BOF, too.

There are two completely different use cases for TLS, and we will get
nowhere if we assert that solutions for one are inadequate solutions
for the other.

The goal in the current keys-linkage draft, as I read it, is simply to
gain some assurance that the PKIX cert in question is actually
associated with the domain it claims to be.  That is by no means any
kind of assurance that (say) the domain is actually operated by the
organization one thinks it is (i.e. it doesn't prove that
www.mybank.com is actually operated by My Bank, member FDIC).

The first of those is not too far from your (1) (but I think your
description doesn't quite capture the power of being able to guarantee
you got the right result from the DNS).  The second of these is
plainly related to your (2).

The fact is that many people think (2) is a waste of time for many
purposes: many of the actual CAs simply don't do anything like the job
necessary to believe their assertions about identity and so on
embodied in the cert.  Therefore, the "utility of some of this" is not
the issue directly, but it certainly is a motivating factor in the
discussion.  I don't think we can dismiss it.  If the facilities that
are supposed to be offered by a technology don't work in practice,
then the lack of utility is relevant to rhe duscussion.  (This is not
to say the facilities are never useful.  But as general
infrastructure, they haven't worked out so well in terms of actually
identifying complete strangers to one anhother.)

> with DNSSEC-secured data.

Right.  My impression is that such is the thing this proposed WG would
aim at.  That's congruent with my reading of the Problem Statement
recently circulated.  Complete replacement of the entire X.509
functionality is obviously not needed.  Perhaps, however, a
supplementary way of anchoring CAs (better than "update your browser,
please"!) would be another nice thing for any WG to develop.  I regard
that as a sideshow, however.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 18 Aug 2010 18:06:35 +0100

> I am my own root of trust. And that is what everyone else should demand.

Back when I worked on DNSSEC, I had a proposal to allow bilateral signing of
DNSSEC keys. The general idea was that I would probably trust my own DNSSEC
provider, so I could then retrieve the DNSSEC keys they trusted, and so on,
recursively. Obviously I can choose wherever I like in this graph to start.

The WG carefully defined the problem s.t. this was not a solution :-)

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Aug 2010 13:15:54 -0400

> The WG carefully defined the problem s.t. this was not a solution :-)

Note that some of us who did the review of the proposals, however,
thought that the solution was a good idea worth pursuing, but not one
that would solve the particular problem as it was defined.  I'm still
interested in your proposal, because it seemed like a generally good
idea to me (especially in the current context, which is the sort of
thing I thought it'd be nice for),

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Aug 2010 13:32:08 -0400 (EDT)

On Wed, 18 Aug 2010, Ben Laurie wrote:

> Back when I worked on DNSSEC, I had a proposal to allow bilateral signing of DNSSEC keys. The general idea was that I
> would probably trust my own DNSSEC provider, so I could then retrieve the DNSSEC keys they trusted, and so on,

And related to that, you could keep the trust path from root to yourself. Then when doing
any kind of device syncing with a new device, you pass along each others trust path, and
it should hit a common trust anchor. This way phone.ben.laurie.org. can sync up with
phone.paul.xelerance.com without even *having* any kind of internet uplink.

This would be good to have in bonjour/avahi/whateveritiscalled today

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Aug 2010 15:55:44 -0400

> www.mybank.com is actually operated by My Bank, member FDIC).

With DNSSEC alone we have a domain linkage, but no accountability for it.

With DV we have a measure of accountability in that CAs that really
screw up could in theory be dumped out of the browsers and we have
defined and audited processes.

With EV we have an industry standard assurance level and audited process.

Now we could have a pointless discussion about whether DV is really
more secure than DNSSEC, but I think thats pointless as I don't think
anyone is willing to state that either is a sufficient basis for
handing over your credit card number or doing banking. And so neither
should merit a padlock icon.

> identifying complete strangers to one anhother.)

One big problem here, one that I did insist we deal with in EV was to
actually show who is providing the certificate to the end user. A
green bar from a VeriSign or a Comodo may not mean the same to the end
user as a green bar from Bogocert CA they never heard of before.

The importance of this distinction was just demonstrated in the UAE
case. Perhaps people are not going to want to trust CAs in certain
parts of the world for certain purposes. I would not accept code
signed with a cert from a Nigerian, Sudanese or Russian CA.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Aug 2010 16:18:25 -0400 (EDT)

> With DNSSEC alone we have a domain linkage, but no accountability for it.

There is a path of accountability.

> With EV we have an industry standard assurance level and audited process.

EV only works because I cannot get it for $15. The internet is more then
just a few wealthy corporations that can afford to join an elite club.

> signed with a cert from a Nigerian, Sudanese or Russian CA.

Nor RealTek. or Microsoft. To name two compromised pieces of signed code.

But really, the discussion of whether I can trust a TLD operator more then
a CA operator is outside the scope of this list. I believe what is desired
here is a way to use the TLD operator without a CA operator. We already have
the reverse case for those interested in that.

Provided we use the security features DNSSEC offers us, how can we best
implement new record types to satisfy the needs of a variety of uses by
a variety of applications.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Aug 2010 13:32:53 -0700

>With DNSSEC alone we have a domain linkage, but no accountability for it.

This is completely incorrect. The accountability is to "the same person who gave you the A record that you are about to use to go to the site".

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Aug 2010 16:43:52 -0400

> the reverse case for those interested in that.

Hear, hear.  We don't need to debate whether one approach is better
than the other.  We're not writing signature-style-choices-bcp.  The
point is to write something that works interoperably provided that you
accept the premise that what you want to use is DNSSEC.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 15:39:06 -0600

> accept the premise that what you want to use is DNSSEC.

Which might mean using both DNSSEC and PKIX -- the choice is not either-or.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Aug 2010 18:00:39 -0400 (EDT)

> Which might mean using both DNSSEC and PKIX -- the choice is not either-or.

I think previous attempts explicitely included PKIX, and the efforts
died because of it.

I was not at the IETF in Maastricht, so I did not attend the BOF, but I don't
think commiting to a CA/X.509 will be very useful. the PKIX people will (again)
say "we already have CA's for that".

Perhaps some clarification could be made. Perhaps some container formats of
PKIX might be used, but not the trust model of external CA's? (If you would
do that, this would just become a repeat of RFC 4398)

Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 16:32:29 -0600

> do that, this would just become a repeat of RFC 4398)

Ah, what I meant is that just because you use DNSSEC to get information
out of DNS doesn't mean you can't use PKIX certificates during TLS
negotiation with an application service.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Aug 2010 18:46:28 -0400 (EDT)

> negotiation with an application service.

Oh sure. you could do BTNS channel binding too an upgrade some TLS connection
to a more trusted state based on external authentication. But that is all
outside the scope of what to put in a new type of DNS RR record. And we
should not limit a new RR type to REQUIRE external authentication.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Aug 2010 16:42:28 -0700

>should not limit a new RR type to REQUIRE external authentication.

If you want to do something that requires a protocol change to TLS at the same time (instead of just a processing policy change), sure. Such a requirement is not the only choice, however. Our draft leaves the PKIX cert in TLS as-is, but adds an external binding of the key to the domain name by the same organization that is telling you other information about the domain name, such as the IP address.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Aug 2010 22:21:32 -0400

Ok let's look at what the trust path is for DNSSEC

Take www.example.com

ICANN is accountable to whom?

VeriSign as the registry is maybe accountable to ICANN but not to the example.com domain name owner

Then we have the box which people are naively labeling "the" registrar

First off there are a few hundred ICANN registered registrars. Some of which are outright criminal. And beyond that you have an even greater number of resellers that the key holder thinks is their registrar but is simply a reseller

And we are not finished yet since the actual operations of many of those registrars is in turn outsourced to a dns hosting specialist. Which is good in some ways because there are fewer of those than there are registrars.

All told we have several thousand parties who could potentially touch a DNS record. Names are transferred between these registrars on a continuous basis. 

Forget accountability, I don't think anyone could claim to have a comprehensive enumeration. Certainly the authentication required to get ICANN credentials is not very great, arguably not even as serious as the requirement to get an EV certain. Definitely less than is required to operate a CA where there is a WEbTrust audit requirement.

I won't defend how some CAs issue certs. But what I won't accept is the idea that the ICANN scheme is intrinsically superior. It has more moving parts, more potential points of failure and huge areas of ambiguity. In the SSL cert case we do have an actual single root, the WebTrust auditors. Can anyone give a reason for why the ICANN system won't fail in precisely the same way?

ICANN has enough difficulty ejecting registrars being run by organized crime. They are suddenly going to acquire the expertise to run a global PKI better than the existing scheme and do so for free?

Since when has ICANN done anything for free? They charge $50,000 to merely apply for a tld that they may well reject. They may be called a non profit but they certainly pay some handsome salaries. 

Sent from my iPad

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Aug 2010 22:26:06 -0400

People are constantly asserting something that is not true.

If you want to make statements asserting how the single root of trust is better. Then expect to hear the opposite point of view.

We have a proposed charter making tendentious statements on this topic, so they are certainly in scope. You can't expect to take swipes at people and then cry uncle when they defend themselves.

I want to use dnssec without the ICANN root. 

Sent from my iPad

On Aug 18, 2010, at 4:43 PM, Andrew Sullivan <[email-masked]> wrote:

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

---

From: Steve Schultze <[email-masked]>
Date: Wed, 18 Aug 2010 22:51:46 -0400

On Aug 18, 2010, at 10:21 PM, Phillip Hallam-Baker wrote:
> First off there are a few hundred ICANN registered registrars. [etc...]

The architecture is exclusive, and in the case where there are possible nefarious means for gaining control of someone else's zone such shenanigans are highly detectable (they are inherently public) and dispute processes are well-established and have been relied upon by everyone using the web for a long time.

> Definitely less than is required to operate a CA where there is a WEbTrust audit requirement.

As a nitpick, WebTrust is not a requirement for CA approval (ETSI and ANSI standards are also accepted by the major vendors).  The standards for who can conduct audits are somewhat arbitrary (why CPAs?) and aged (the non-EV standards were designed to be provisional and never updated).

But the more important reasons why the DNS approach provides advantages are the reasons I gave above (exclusivity and publicity).

That is not to say of course that WebTrust-audited CAs don't have a critical role going forward... especially when it comes to EV and the like.  Their role is complimentary.  However, the domain linkage function of DNSSEC-validated assertions is as good as (well, better than) today's DV certs.

> I won't defend how some CAs issue certs. But what I won't accept is the idea that the ICANN scheme is intrinsically superior. It has more moving parts, more potential points of failure and huge areas of ambiguity.

With respect to domain validation, it has fewer points of failure.  The points of failure are each node down the hierarchy (and only one path down is allowed).  The points of failure in CA DV certs are 300+ CAs plus thousands of Subordinate CAs (often undisclosed) plus thousands more RAs (also undisclosed).

> In the SSL cert case we do have an actual single root, the WebTrust auditors.

No, we have a single standard (well, two... one for EV and another for everything else) which leaves huge areas of ambiguity and latitude for browser/OS vendors to interpret compliance and tremendous holes when it comes to god-like delegation after approval.

> ICANN has enough difficulty ejecting registrars being run by organized crime. They are suddenly going to acquire the expertise to run a global PKI better than the existing scheme and do so for free?

Exclusivity allows site operators to choose the most trustworthy registrar... hopefully initiating a race to the top instead of today's CA DV race to the bottom.

> Since when has ICANN done anything for free? They charge $50,000 to merely apply for a tld that they may well reject. They may be called a non profit but they certainly pay some handsome salaries. 

Are they charging anything for signing TLD DS records?  That's the only relevant question in this context.

---

From: "Perry E. Metzger" <[email-masked]>
Date: Wed, 18 Aug 2010 22:59:22 -0400

On Wed, 18 Aug 2010 22:21:32 -0400
> example.com domain name owner

In the current CA model, every single CA disclaims all
liability. There is thus no reduction in function there.

In any case, if you dislike the idea, you are not obligated to use
it. I would leave the people who want to do such things alone to get
their work done.

Perry

---

From: David Conrad <[email-masked]>
Date: Wed, 18 Aug 2010 20:38:07 -0700

[Just joined this list and may not be staying long if this is typical subject matter]

> ICANN is accountable to whom?

Depends on which part of ICANN you're looking at.  In the case of anything having to do with the IANA function (which managing the KSK is deemed), ICANN is accountable to the U.S. Dept. of Commerce, National Telecommunications and Information Administration, via the IANA functions contract (actually, the contract is with NOAA, but it is NTIA that cares.  Deeply).

> VeriSign as the registry is maybe accountable to ICANN but not to the example.com domain name owner

Accountability for what exactly?  VeriSign is contractually obligated to ICANN to be accountable for various things.

> Then we have the box which people are naively labeling "the" registrar

Yes.  Choose your registrar wisely.  Caveat emptor and all that.

> And we are not finished yet since the actual operations of many of those registrars is in turn outsourced to a dns hosting specialist. Which is good in some ways because there are fewer of those th…

If you want to fully trust the contents of your domain, you sign it yourself. Period.

> All told we have several thousand parties who could potentially touch a DNS record. Names are transferred between these registrars on a continuous basis. 

So you, as the admin of example.com, give your DS to your registrar to have it inserted into the COM zone.  You chose your registrar poorly and they mangle your DS in a nefarious attempt to seize control of your zone (or something).  Your evil registrar updates the .COM zone and (eventually, when is a bit indeterminate at least currently), VeriSign publishes the updated zone.

And you don't notice that the DS that was supplied doesn't match what showed up in the .COM zone and stamp your foot petulantly (or something)?  How does that work again?

> I won't defend how some CAs issue certs. But what I won't accept is the idea that the ICANN scheme is intrinsically superior.

It is superior in the sense that you have a _much_ more limited set of players and the selection of players (that is, who can be a registry) is typically a bit more public.

> ICANN has enough difficulty ejecting registrars being run by organized crime.

I'd suggest not choosing a registrar run by organized crime.

> They are suddenly going to acquire the expertise to run a global PKI better than the existing scheme and do so for free?

ICANN maintains the KSK for the root of the DNS.  It has demonstrated the expertise to do this (at least IMNSHO).  The fact that some folks believe an alternate PKI can be established using DNSSEC with a trusted root signed by VeriSign (not ICANN) is somewhat unrelated to the fact that ICANN signs VeriSign's ZSKs with the KSK they maintain.

And yes, ICANN does maintain the KSK for the root of the DNS "for free".  That is, if you consider the fees imposed by ICANN on the registries and registrars to be completely inconsequential.

> Since when has ICANN done anything for free? They charge $50,000 to merely apply for a tld that they may well reject.

Actually, it is $185,000 last I looked.

>  They may be called a non profit but they certainly pay some handsome salaries. 

So... keyassure is an yet another ICANN-bashing list?  O joy, O rapture. What does the salary ICANN pays have to do with anything relevant to what I thought this list was going to be discussing?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 18 Aug 2010 20:42:15 -0700

> I want to use dnssec without the ICANN root. 

Feel free.  There are (currently) only about 300 TLD trust anchors you'll have to keep track of if all the TLDs started signing. ICANN says they'll be adding no more than about 1000/year. You'll have to figure out a way of securely fetching the trust anchors from the TLD admins who sign their zones to install into your validating resolver, but that's a minor detail.

A single root of trust _can be_ better since there are less parties to vet and audit (1 versus many).  However, as I said, if you don't want to trust ICANN, VeriSign, and the US Government, you don't have to.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 18 Aug 2010 20:51:03 -0700

> No, we have a single standard (well, two... one for EV and another for everything else) which leaves huge areas of ambiguity and latitude for browser/OS vendors to interpret compliance and tremendo…

And, of course, WebTrust auditors could never be bribed...

> Are they charging anything for signing TLD DS records?  

Likely a rhetorical question, but just in case:  no, ICANN does not charge for accepting DS records (or anything else) from TLDs.  VeriSign similarly does not charge for accepting authorized root zone change requests from ICANN, generating, signing, and transmitting the root zone to the root server operators.  And, of course, the root server operators do not charge for serving the root zone on their servers.

Regards,
-drc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 00:49:29 -0400

You make a big mistake here when you talk about choosing a registrar wisely

You are looking at the problem from the point of view of someone putting keys in. The correct way to look at the issue if you want to make the comparison to ssl CAs is from the point of view of someone who is relying on the keys. And there they have no way to control who the registrar is. Unlike in ssl you don't even know who did the validation if at all.

I can choose the most diligent registrar in the world. But that won't do anything to improve the quality of the information I have to rely on

---

From: Steve Schultze <[email-masked]>
Date: Thu, 19 Aug 2010 00:53:17 -0400

> I can choose the most diligent registrar in the world. But that won't do anything to improve the quality of the information I have to rely on

I don't believe you are correct, but I would welcome your clarification if I misunderstand.

Once a domain is registered, even if BadGuy goes to EvilRegistrar, he can't obtain control of that zone.  What is your exploit that makes this possible?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 01:10:39 -0400

Perry 

It has taken fifteen years to get to this point. A large part of the reason for that delay was the refusal to consider real world constraints that did not fit the abstract technical model

It took eight years to fix the opt in issue. It took five years to fix the eu privacy directive issue. Both took too long because people didn't want to accept the possibility of a problem.

We have a proposed charter that asserts that the benefit of dnssec lies in having a single root of trust because that means fewer points of failure. I am pointing out that these claims are not actually true. If people don't want to argue the point then delete the unnecessary claims from the charter.

Don't forget that in the originally proposed and deployed ssl model that there was a single root of trust. It didn't stay that way for long. It was an unstable condition.

Sent from my iPad

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 01:33:37 -0400

The point is that I get to choose where to register hallambaker.com
But my security is affected by the place that mybank.com registers myemployer.com registers and so on.

If the ui does not tell the relying party who signed then the security of the system for the relying party is the security of the least diligent signer.

People are asserting that the dnssec design as it stands addresses this problem when it does not. But that does not mean that we can't add in some pieces so that it does. 

As far as the registrar issue is concerned, There is a lot of complexity there. What the customer thinks is a registrar may be a reseller using an outsourced dns publisher. So that is three parties not one. 

First possible line of attack is a Twitter style password reset request.

Second is to claim a zone transfer.

Then there are typo attacks 

All entirely justifiable if all you are trying to do is to provide almost as good security as dv ssl certs. But what I am saying is that there is no reason not to have the option of almost as good and very much better.

There are holes we need to plug in pkix as well. 

Sent from my iPad

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 01:39:32 -0400

The charging issue is what the domain name owner is expected to pay to have dnssec once this monopoly provider infrastructure is deployed. ICANN extracts a rent on every domain name as does VeriSign in .com. Do we have any guarantee that this rent will not increase in either case? 

I would have thought that quite obvious but instead you pose hypotheticals about how much ICANN is going to charge VeriSign, as if that would be a concern for anyone.

Sent from my iPad

---

From: Steve Schultze <[email-masked]>
Date: Thu, 19 Aug 2010 02:05:24 -0400

> But my security is affected by the place that mybank.com registers myemployer.com registers and so on.

mybank.com will gravitate toward more trustworthy registrars (because exclusivity promises actual increased security), rather than the cheapest option (which is what the current DV CA model encourages).

> If the ui does not tell the relying party who signed then the security of the system for the relying party is the security of the least diligent signer.

That is not true.  The security of the system for the relying party is the security of the signer that the domain owner chooses, and in a market in which the cost differential is negligible (the likely market) this will optimize for security of both parties (domain owner and relying party).

> As far as the registrar issue is concerned, There is a lot of complexity there. What the customer thinks is a registrar may be a reseller using an outsourced dns publisher. So that is three parties…

Agreed, but the exclusive and public nature of DNS registration makes this much less significant.

> First possible line of attack is a Twitter style password reset request.

I'm not sure I understand what the attack vector is here in the DNS model.  In any event, it's far better security than thousands of trusted (and often undisclosed) CAs/SubCAs/RAs.

> Second is to claim a zone transfer.

If bankofamerica.com isn't worried about this today on a basic name-to-IP level, I think we have solved it to a significant degree.

> Then there are typo attacks 

Agreed.  Totally unsolvable on the DNSSEC layer and a great example of where CAs are still of critical importance in the domain-to-legal-entity chain.

> All entirely justifiable if all you are trying to do is to provide almost as good security as dv ssl certs.

No, _better_ than DV SSL certs (when it comes to domain-to-key mapping).

> But what I am saying is that there is no reason not to have the option of almost as good and very much better.

]
The "very much better" part is essential, but it relies on the ability of DNSSEC to ensure a superior domainname-to-owner mapping.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 19 Aug 2010 09:00:00 +0200

> I want to use dnssec without the ICANN root.

You are free to do so.  The way how you configure your DNSSEC validating 
resolver is entirely up to you.

And please note that I would like to discuss things like which RR type 
to use and how to secure the last mile.

The "How trustworthy is ICANN" discussion is outside the topic of this 
mailing list.  So please all keep that in mind.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 19 Aug 2010 09:02:08 +0200

[moderator hat on]
This is entirely outside the topic of this mailing list.  Either please 
explain how is this related to the proposed problem statement or take it 
elsewhere.  This is not a list to discuss ICANN policies.
[/moderator hat off]

On 19.8.2010 07:39, Phillip Hallam-Baker wrote:
> The charging issue is what the domain name owner is expected to pay
> to have dnssec once this monopoly provider infrastructure is
> deployed. ICANN extracts a rent on every domain name as does VeriSign
> in .com. Do we have any guarantee that this rent will not increase in
> either case?
>
> I would have thought that quite obvious but instead you pose
> hypotheticals about how much ICANN is going to charge VeriSign, as if
> that would be a concern for anyone.
>
> Sent from my iPad
>
> On Aug 18, 2010, at 11:51 PM, David Conrad<[email-masked]>
> wrote:
>
>>> No, we have a single standard (well, two... one for EV and
>>> another for everything else) which leaves huge areas of ambiguity
>>> and latitude for browser/OS vendors to interpret compliance and
>>> tremendous holes when it comes to god-like delegation after
>>> approval.
>>
>> Likely a rhetorical question, but just in case:  no, ICANN does not
>> charge for accepting DS records (or anything else) from TLDs.
>> VeriSign similarly does not charge for accepting authorized root
>> zone change requests from ICANN, generating, signing, and
>> transmitting the root zone to the root server operators.  And, of
>> course, the root server operators do not charge for serving the
>> root zone on their servers.
>>
>> Regards, -drc
>>
>> _______________________________________________ keyassure mailing
>> list [email-masked]
> _______________________________________________ keyassure mailing
> list [email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 19 Aug 2010 09:05:08 +0200

> [Just joined this list and may not be staying long if this is

David,

I would like you to stay.

> So... keyassure is an yet another ICANN-bashing list?

No, it's not.  And I'll try to make sure it stays on topic as much I as 
will be able to do so.

> O joy, O rapture. What does the salary ICANN pays have to do with
> anything relevant to what I thought this list was going to be
> discussing?

Please all, keep on topic.  Stay out of attacking other people just 
because your opinion isn't heard.

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 19 Aug 2010 09:17:33 +0200

> I disagree with the statement in the proposed charter

Then propose alternative wording.  Or what to add or what to remove.

> other capabilities and limitations.

And there are some capabilities and limitations which are same and there 
are some capabilities which are superior in DNSSEC and some which are 
superior in PKIX.  So what are you trying to say?

DNSSEC will not be able to provide identity check.  But it keeps the 
security trust as close to infrastructure as possible.  You have to 
trust your DNS and keep it secure.

It was already discussed and my feeling is that the general consensus is 
that DV-certs are as at the same or lower level than "DNSSEC-certs".  I 
propose to not discuss this again, since this is not the purpose of the 
mailing list.  The purpose is to create solution to be able to establish 
secure TLS connection out of DNS data.

> supported in existing pki at lower out of pocket expense

And there are many people who are interested also in that.

> the service that CAs really provide.

We had this in mind when we wrote:

"The DNSSEC root trust anchor can also be used for additional validation 
during the current path validations. By validating that the  certificate 
presented is the certificate identified by the DNS, we can provide 
additional confidence that the client is connecting to the intended 
server - this helps alleviate concerns that a valid certificate has been 
obtained by an attacker (for example from a CA not used by the victim)."

> scheme has it's uses but it does not have to be the only scheme people

There is no single root of trust in the dnssec model.  There are as much 
trust roots as you configure to validate.  DNSSEC signed root just makes 
things more easy to implement.

> what already exists for cheap.

This is much in contrary with what you said in previous paragraph.  The 
best system could require as to change not even our thinking, but also 
the ssl libraries, clients and servers.  Let's not close this option.

Ondrej

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 08:31:52 -0400

Take out all the wording in the current charter entirely.

You don't have to say anything about trust models. Not unless you want to debate the merits of ICANN. You certainly don't have to make claims that the ICANN root is better than existing ssl schemes. 

Instead I would simply state that the purpose of the list is to discuss how to use information in the dns to enable applications to obtain keys.

I would then follow up with statements of high level objectives. One of these being enabling ubiquitous encryption which in turn requires that there be no additional out of pocket cost per server.

I would then add in preventing downgrade attack as a possible objective.

Dubious claims of fact have no place in a charter. DKIM demonstrates that it is quite possible to make useful use of keys in the dns without dnssec at all. It is also quite possible to make use of keys when only the local zone is signed without the upper zone signing the KSK. 

You have to be realistic when designing a security protocol. The only reason that a security protocol is necessary in the first place is that people do wrong things and bad things. If you want to propose a security scheme based on trusting one party to never do the wrong thing and then declare that one party off limits for examination, expect security people to be skeptical.

Just take out the unfounded claims about single trust roots and we don't need to discuss the fact that they are unfounded assumptions.

Sent from my iPad

On Aug 19, 2010, at 3:17 AM, Ondřej Surý <[email-masked]> wrote:

> And there are some capabilities and limitations which are same and there are some capabilities which are superior in DNSSEC and some which are superior in PKIX.  So what are you trying to say?
> 
> DNSSEC will not be able to provide identity check.  But it keeps the security trust as close to infrastructure as possible.  You have to trust your DNS and keep it secure.
> 
> It was already discussed and my feeling is that the general consensus is that DV-certs are as at the same or lower level than "DNSSEC-certs".  I propose to not discuss this again, since this is not the purpose of the mailing list.  The purpose is to create solution to be able to establish secure TLS connection out of DNS data.
> 
> "The DNSSEC root trust anchor can also be used for additional validation during the current path validations. By validating that the  certificate presented is the certificate identified by the DNS, we can provide additional confidence that the client is connecting to the intended server - this helps alleviate concerns that a valid certificate has been obtained by an attacker (for example from a CA not used by the victim)."
> 
> There is no single root of trust in the dnssec model.  There are as much trust roots as you configure to validate.  DNSSEC signed root just makes things more easy to implement.
> 
> This is much in contrary with what you said in previous paragraph.  The best system could require as to change not even our thinking, but also the ssl libraries, clients and servers.  Let's not close this option.
> 
> Ondrej
> -- 
> Ondřej Surý

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 09:01:39 -0400

The reason I think we can do better is that we can block downgrade attack. Validating domain names is not the issue because I bank with a company, not a domain name.

At the moment the biggest holes in smime and ssl are

* there is no way to know if the web site uses ssl
* there is no way to know if the recipient can accept smime
* there is no way to find an smime recipient cert that is widely supported

All of these stem from the fact that x.509 certs are not properly integrated into dns. And those are the areas where I see big potential for creating a unique value for dnssec.

There are several million ssl cert owners already using crypto. They are the potential early adopter market. 

The point you are still not getting here is that the security of the system is measured from the point of view of the relying party. The relying party does not choose either the CA or the Registrar, but an attacker can. 

At present I can't even know who the validator in a dnssec chain is. The registrar does the work but the registrar does not even have a key. It's the registry that has the key. Dnssec architecture predates the registrar / registry split in .com.

The simple solution for this is to allow for certs in the dnssec trust path to validate KSKs. This would supplement the TLD signature if available. This allows the liability issues to be managed, moots the limitations of a single root of trust and allows for certain practical efficiency optimizations. We can then use dnssec for anything from opportunistic encryption all the way up to million dollar commercial transactions. 

Sent from my iPad

---

From: "Perry E. Metzger" <[email-masked]>
Date: Thu, 19 Aug 2010 09:07:54 -0400

On Thu, 19 Aug 2010 01:10:39 -0400 Phillip Hallam-Baker
<[email-masked]> wrote:
> We have a proposed charter that asserts that the benefit of dnssec
> lies in having a single root of trust because that means fewer

Leave people alone to get their work done. You're not going to
convince them, you're just going to annoy them, and the mere existence
of a standard doesn't imply that anything will actually be deployed
(or do you use RSVP every day? or how about CLNP?)

> Don't forget that in the originally proposed and deployed ssl model
> that there was a single root of trust.

I don't think that was ever the case. Netscape invented it, and the
first browsers they shipped with SSL had multiple roots.

Anyway, if you don't like the work, stay away. Leave the people who
want to try it alone.

Perry
-- 
Perry E. Metzger		[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Aug 2010 08:14:34 -0700

If you feel that the proposed charter text is using the wrong model, please send specific proposals to the list so that others can consider them. Slowly expanding on your model description over the course of many messages doesn't seem to be working at gaining consensus.

--Paul Hoffman, Director
--VPN Consortium

---

From: David Conrad <[email-masked]>
Date: Thu, 19 Aug 2010 08:31:05 -0700

On Aug 19, 2010, at 6:01 AM, Phillip Hallam-Baker wrote:
> The registrar does the work but the registrar does not even have a key. It's the registry that has the key. 

The registrar does essentially nothing.  I remain a bit confused as to why you keep harping on the registrar here.  The registrar accepts public information from the registrant and asks the registry to place that information into the registry's zone. If the registrar accidentally or intentionally asks for the wrong information to be placed into the zone, the registrant will notice as soon as the registry publishes the zone. 

Exactly what threat do you see the registrar facilitating?

> The simple solution for this is to allow for certs in the dnssec trust path to validate KSKs. This would supplement the TLD signature if available. This allows the liability issues to be managed, moots the limitations of a single root of trust and allows for certain practical efficiency optimizations.

Pointer to your draft?

> We can then use dnssec for anything from opportunistic encryption all the way up to million dollar commercial transactions. 

We can do this today.

Regards,
-drc

---

From: Stephen Schultze <[email-masked]>
Date: Thu, 19 Aug 2010 12:40:18 -0400

David said basically what I was going to say on your other points, but  
I wanted to also note the following:

On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote:
> The point you are still not getting here is that the security of the  
> system is measured from the point of view of the relying party. The  
> relying party does not choose either the CA or the Registrar, but an  
> attacker can.

Let's describe the assurances that the relying party has in each case:

Standard CA DV cert:
One of thousands of entities with cert-issuing authority said that the  
holder of the corresponding private key controls the zone for the  
domain in question.  There may be other people out there who also have  
certificates that assert that they control the domain, but neither you  
nor this issuing CA necessarily know if they exist.  Every root CA has  
equivalent authority as far as you're concerned, and an attacker can  
choose the lowest common denominator CA and serve you those certs at  
will.

DNSSEC domain-key assertion:
The person who controls the zone for the domain in question holds the  
corresponding private key.  The only opportunity for mischief or  
mistake is in the one single path that the zone controller chose:  
their nameserver (especially if they are doing online signing), the  
registrar, the registry, and the root (and if there are DS records for  
sub-domains, whoever controls those).  What's more, any substitution  
of a baddie's DS record for the true domain owner's DS record would be  
highly visible and likely to be immediately corrected.

DNSSEC domain-key assertion plus EV:
Not only is there a high level of assurance that you are talking to  
the person who controls the zone, a third-party has verified who that  
person is.  You can have a substantial degree of trust in that third- 
party because they have been approved according to the more stringent  
EV requirements.

DNSSEC domain-key assertions are backed up by the technical  
architecture.  CA assertions are backed up by standards groups,  
reputation, and perhaps even legal liability.

The caveat for both systems are that technical vulnerabilities can and  
do happen, but I think that's well beyond this group's mandate to  
discuss.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Aug 2010 18:04:10 -0400

On Aug 19, 2010, at 12:40 PM, Stephen Schultze wrote:

> David said basically what I was going to say on your other points,  
> but I wanted to also note the following:
>
>> The point you are still not getting here is that the security of  
>> the system is measured from the point of view of the relying party.  
>> The relying party does not choose either the CA or the Registrar,  
>> but an attacker can.
>
>
> One of thousands of entities with cert-issuing authority said that  
> the holder of the corresponding private key controls the zone for  
> the domain in question.  There may be other people out there who  
> also have certificates that assert that they control the domain, but  
> neither you nor this issuing CA necessarily know if they exist.   
> Every root CA has equivalent authority as far as you're concerned,  
> and an attacker can choose the lowest common denominator CA and  
> serve you those certs at will.
>
> The person who controls the zone for the domain in question holds  
> the corresponding private key.  The only opportunity for mischief or  
> registrar, the registry, and the root (and if there are DS records  
> for sub-domains, whoever controls those).  What's more, any  
> substitution of a baddie's DS record for the true domain owner's DS  
> record would be highly visible and likely to be immediately corrected.

So, when I initially started looking at all this (leveraging the  
DNSSEC TA as a TA for other things) I thought that it was the best  
thing since sliced bread... until it occurred to me that this was  
changing who all could muck with your security.
CA certs were handed out by CAs, and you didn't need to worry about  
being attacked by your (probably outsourced) DNS provider, your  
(probably reseller) registrar, their parent registrar and the registry  
(or, more likely, the chappie who owned your nameserver because you  
thought that 'P@ssword' was a good choice). I ended up rewriting my  
initial draft saying that the only use for this was to allow you to  
attest to what the *correct* CA issued cert was, and apologized to the  
folk to whom I had given the original drafts to for wasting their  
time...
A long set of emails and phonecalls and IMs then occurred, with me  
kvetching about how this was changing the fundamental trust model, and  
opening you up to dinking with by all of the folk in the  
registration / DNS side of things and how the sky was falling... but,  
for every scenario that I came up with (rogue DNS provider, hacked  
nameserver, bad registrar) folk convinced me that the attackers could  
just as easily redirect my MX record and use that to obtain a CA  
signed cert...  It took some time (I guess because I didn't want to  
admit to myself just how screwed we were), but they have fully  
convinced me -- once someone in a position to change your DNS  
responses (by inserting DNSSEC signed keymaterial or something) they  
are in a position to get a cert....

W

> the person who controls the zone, a third-party has verified who  
> that person is.  You can have a substantial degree of trust in that  
> third-party because they have been approved according to the more  
> stringent EV requirements.
>
> The caveat for both systems are that technical vulnerabilities can  
> and do happen, but I think that's well beyond this group's mandate  
> to discuss.

--
If the bad guys have copies of your MD5 passwords, then you have way  
bigger problems than the bad guys having copies of your MD5 passwords.
-- Richard A Steenbergen

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 19:40:25 -0400

+1

There's some analogy to be made here to the RPKI [1], which overlays a  
PKI attesting to Internet resource holdings on the existing hierarchy  
for managing these resources.  Using the same management structure  
means the same set of people have to be trusted [2].  The security  
infrastructure just allows secured things to be tied back to these  
trusted entities.

[1] <http://tools.ietf.org/html/draft-ietf-sidr-arch>
[2] "trusted" in the sense of RFC 4949 :)

On Aug 19, 2010, at 6:04 PM, Warren Kumari wrote:

>>> the system is measured from the point of view of the relying  
>>> party. The relying party does not choose either the CA or the  
>>> Registrar, but an attacker can.
>>
>>
>> also have certificates that assert that they control the domain,  
>> but neither you nor this issuing CA necessarily know if they  
>> exist.  Every root CA has equivalent authority as far as you're  
>> concerned, and an attacker can choose the lowest common denominator  
>> CA and serve you those certs at will.
>>
>> the corresponding private key.  The only opportunity for mischief  
>> or mistake is in the one single path that the zone controller  
>> chose: their nameserver (especially if they are doing online  
>> signing), the registrar, the registry, and the root (and if there  
>> are DS records for sub-domains, whoever controls those).  What's  
>> more, any substitution of a baddie's DS record for the true domain  
>> owner's DS record would be highly visible and likely to be  
>> immediately corrected.
>
> (probably reseller) registrar, their parent registrar and the  
> registry (or, more likely, the chappie who owned your nameserver  
> because you thought that 'P@ssword' was a good choice). I ended up  
> rewriting my initial draft saying that the only use for this was to  
> allow you to attest to what the *correct* CA issued cert was, and  
> apologized to the folk to whom I had given the original drafts to  
> for wasting their time...
> kvetching about how this was changing the fundamental trust model,  
> and opening you up to dinking with by all of the folk in the  
> registration / DNS side of things and how the sky was falling...  
> but, for every scenario that I came up with (rogue DNS provider,  
> hacked nameserver, bad registrar) folk convinced me that the  
> attackers could just as easily redirect my MX record and use that to  
> obtain a CA signed cert...  It took some time (I guess because I  
> didn't want to admit to myself just how screwed we were), but they  
> have fully convinced me -- once someone in a position to change your  
> DNS responses (by inserting DNSSEC signed keymaterial or something)  
> they are in a position to get a cert....
>
> W
>
>
>
>
>>

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 20 Aug 2010 10:13:51 +0200

On 20.8.2010 00:04, Warren Kumari wrote:
>> sub-domains, whoever controls those). What's more, any substitution of
>> a baddie's DS record for the true domain owner's DS record would be
> So, when I initially started looking at all this (leveraging the DNSSEC
> TA as a TA for other things) I thought that it was the best thing since
> sliced bread... until it occurred to me that this was changing who all
> could muck with your security.
> folk to whom I had given the original drafts to for wasting their time...
> opening you up to dinking with by all of the folk in the registration /
> DNS side of things and how the sky was falling... but, for every
> scenario that I came up with (rogue DNS provider, hacked nameserver, bad
> registrar) folk convinced me that the attackers could just as easily
> redirect my MX record and use that to obtain a CA signed cert... It took
> some time (I guess because I didn't want to admit to myself just how
> screwed we were), but they have fully convinced me -- once someone in a
> position to change your DNS responses (by inserting DNSSEC signed
> keymaterial or something) they are in a position to get a cert....

Exactly.  The change of the trust model will be always scary.  But it is 
important to realize that we don't change overall level of security (in 
fact, we are improving it), just the trust model.

Ondrej

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Aug 2010 07:47:19 -0400

There will be no change in the trust model. You are adding in one
additional root. You are not going to remove the others.

The IETF is very likely to charter a group that is going to look at
the problem of how to enable applications to use DNSSEC. But I think
it highly unlikely that they would charter a group to engineer a
change in the trust model from a market based solution to a monopoly.
That just is not going to happen.