Subject: Fwd: Historic Moment - Root zone of the Internet was just signed minutes ago!!!

From: Russ Housley <[email-masked]>
Date: Fri, 16 Jul 2010 08:23:17 -0400

I am passing on this announcement, and I want to add my thanks to
everyone in the Internet community that played a role in deploying DNSSEC.

Russ Housley
IETF Chair

------ Forwarded Message
From: Rod Beckstrom <[email-masked]>
Date: Thu, 15 Jul 2010 14:24:38 -0700
To: Rod Beckstrom <[email-masked]>
Cc: ICANN Board of Directors <[email-masked]>, Staff
<[email-masked]>
Subject: Historic Moment - Root zone of the Internet was just signed
minutes ago!!!

Dear Board and Staff,

Now  is a historic moment for the Internet, ICANN, IETF, Verisign and
the Dept of Commerce.

The root zone of Internet is now more secure - signed cryptographically
w/ DNSSEC.

Special thanks to Rick Lamb, DNSSEC lead in ICANN; Steve Crocker, SSAC;
Suzanne Woolf, RSSAC; all of you on board and staff and the many people
in the multi-stakeholder community who have made this happen.

Congratulations. A true milestone in the history of the Internet.

We’ve had a remarkable year of accomplishments.

Warmly,

Rod

Rod Beckstrom
President and CEO
ICANN

One World. One Internet. Everyone Connected.

------ End of Forwarded Message

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 16 Jul 2010 08:27:23 -0400

Congratulations ! A lot of hard work by a lot of people went into  
this, and we owe those
people a vote of thanks.

Regards
Marshall

On Jul 16, 2010, at 8:23 AM, Russ Housley wrote:

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

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Fri, 16 Jul 2010 14:29:21 +0200

+1!!!

-----Original Message-----
From: [email-masked] on behalf of Marshall Eubanks
Sent: Fri 7/16/2010 5:27 AM
To: Russ Housley
Cc: [email-masked]
Subject: Re: Historic Moment - Root zone of the Internet was just signedminutes ago!!!

Regards
Marshall

On Jul 16, 2010, at 8:23 AM, Russ Housley wrote:

> We've had a remarkable year of accomplishments.
>
> Warmly,
>
> Rod
>
> Rod Beckstrom
> President and CEO
> ICANN
>

---

From: todd glassey <[email-masked]>
Date: Fri, 16 Jul 2010 08:13:57 -0700

> everyone in the Internet community that played a role in deploying DNSSEC.

Hey Russ - how do you think the California Appellate Court's ruling on
Court Admissible evidence in California v Khaled affects this... I can
tell you -

- the DNSSEC design sucks as an evidentiary source of anything and now
evidence from it is inadmissible per Khaled in California Courts as
'untrustworthy'...  it looks like Dean will win this one eh?

Todd Glassey

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Jul 2010 18:35:15 +0200

> everyone in the Internet community that played a role in deploying DNSSEC.

Too bad it doesn't work for me.

Here IANA publishes info that needs conversion steps that I don't have tools for to perform:

http://data.iana.org/root-anchors/

And pulling down the key from the root servers doesn't give me something that works.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 16 Jul 2010 12:40:41 -0400

> http://data.iana.org/root-anchors/

The key data can be read directly from
http://data.iana.org/root-anchors/root-anchors.xml.  It seems to me
that if you have vi (or any other favourite text editor), you have the
tools to use that.  What am I missing?

> And pulling down the key from the root servers doesn't give me something that works.

Define "works"?

A

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Jul 2010 18:50:42 +0200

> Define "works"?

Less of this:

validating @0x82e9000: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf.

If anyone can point me to a key I can paste in my BIND config that will allow me to actually validate domains that would be great.

And/or perhaps the right information hasn't propagated through the DNS system?

---

From: Tony Finch <[email-masked]>
Date: Fri, 16 Jul 2010 18:01:20 +0100

> Too bad it doesn't work for me.

BIND's trust anchors are in DNSKEY format, but IANA publishes the root key
in DS format. You can fetch the root DNSKEY using dig, convert it into
a DS using BIND's dnssec-dsfromkey program and compare the result to the
published trust anchor to verify that you have the right DNSKEY before
adding it to BIND's configuration. There is a longer explanation of the
process at http://fanf.livejournal.com/107310.html

unbound requires trust anchors in DS format which is somewhat more
convenient, though you still have to edit IANA's XML to convert it into
master file format.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
MALIN HEBRIDES BAILEY: WESTERLY OR NORTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8
BAILEY, BUT CYCLONIC 4 OR 5 FOR A TIME IN NORTH HEBRIDES. ROUGH OR VERY ROUGH.
RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Ronald van der Pol <[email-masked]>
Date: Fri, 16 Jul 2010 19:56:50 +0200

> process at http://fanf.livejournal.com/107310.html

Thanks! That was very useful. I finally got it working.

I would also like to check the output for a zone that is verifyable not
correct. Any examples of signed RRs with an incorrect signature?

	rvdp

---

From: Tony Finch <[email-masked]>
Date: Fri, 16 Jul 2010 19:12:32 +0100

> correct. Any examples of signed RRs with an incorrect signature?

Have a look at http://www.dnssec-tools.org/testzone/

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH BISCAY SOUTH FITZROY: WESTERLY BECOMING VARIABLE OR NORTHERLY 3 OR 4,
OCCASIONALLY 5, BUT 6 LATER IN SOUTHEAST FITZROY. MODERATE OR ROUGH. SHOWERS.
MODERATE OR GOOD.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Jul 2010 20:13:46 +0200

On 16 jul 2010, at 19:56, Ronald van der Pol wrote:

>> http://fanf.livejournal.com/107310.html

> Thanks! That was very useful. I finally got it working.

Yes, me too.

> correct. Any examples of signed RRs with an incorrect signature?

I skipped this step:

In the options section of named.conf you should have the directive 
    dnssec-lookaside auto; 
This enables DNSSEC lookaside validation, which is necessary to bridge gaps (such as ac.uk) in the chain of trust between the root and lower-level signed zones

with the result that www.ietf.org, www.iab.org, www.isc.org, all fail to validate. Not sure what the deal is there. Only www.nic.cat works. BTW, this is great:

https://addons.mozilla.org/en-US/firefox/addon/64247/

---

From: Tony Finch <[email-masked]>
Date: Fri, 16 Jul 2010 19:16:02 +0100

On Fri, 16 Jul 2010, Iljitsch van Beijnum wrote:
>
> www.ietf.org, www.iab.org, www.isc.org, all fail to validate.
> Not sure what the deal is there.

The DS record for .org has not yet been added to the root zone so the
chain of trust is broken.

> https://addons.mozilla.org/en-US/firefox/addon/64247/

Groovy :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FAIR ISLE FAEROES: CYCLONIC BECOMING SOUTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8
AT FIRST, DECREASING 4 AT TIMES. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH AT
FIRST. RAIN OR SQUALLY SHOWERS. MODERATE, OCCASIONALLY POOR.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 16 Jul 2010 14:16:39 -0400

> with the result that www.ietf.org, www.iab.org, www.isc.org, all fail to validate. Not sure what the deal is there. Only www.nic.cat works. BTW, this is great:

The deal is that .org doesn't have a DS record in the root zone, but
it is signed.  They determined that they did not want to put their DS
into the root prior to the production signing of the root.

A

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

---

From: Russ White <[email-masked]>
Date: Fri, 16 Jul 2010 10:51:46 -0400

+2! I'm happy to see this happen...

Thanks for all the work.

:-)

Russ

---

From: Paul Wouters <[email-masked]>
Date: Sat, 17 Jul 2010 10:45:26 -0400 (EDT)

> convenient, though you still have to edit IANA's XML to convert it into

You can also use DNSKEY statements in unbound:

~> grep trusted-keys /etc/unbound/unbound.conf
trusted-keys-file: "/etc/pki/dnssec-keys/production/root.conf"
~> cat /etc/pki/dnssec-keys/production/root.conf
trusted-keys {
"." 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0="; // key id = 19036

};

Paul

---

From: Tony Finch <[email-masked]>
Date: Sun, 18 Jul 2010 11:06:13 +0100

> You can also use DNSKEY statements in unbound:

Thanks for the correction - I should have said "supports" rather than
"requires".

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTHWESTERLY BACKING SOUTHERLY 4
OR 5, INCREASING 6 OR 7 FOR A TIME. MODERATE OR ROUGH. OCCASIONAL RAIN.
MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Jul 2010 17:46:34 -0400

Being able to verify signatures is of no value.

The system only has value when you can act differently according to
whether the signature verifies or not.

I keep asking, but nobody will tell me how I get the keys for my
domains into the TLD.

This is not a trivial issue. There is a question of liability to be
addressed. So far ICANN and VeriSign Registry Services have addressed
the issue by booting it down the chain. But the system as a whole
cannot work until there is someone willing to accept the liability and
for that to happen they are going to require tools to manage their
litigation risk.

Does anyone know of a dotcom registrar offering key signing?

Or is the big plan here that everyone who is not going to accept
liability keep complaining about how far behind the registrars are
until they are forced to act?

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 Jul 2010 14:12:55 +1000

In message <[email-masked]>, Phil
> I keep asking, but nobody will tell me how I get the keys for my

Firstly you get DS records into the TLD not DNSKEY records.  Secondly
it is/will be by a mechanism similar to how you get NS records into
the TLD.  In other words go ask your registrar when they are going
to support adding DS records and stop complaining here.

This is not a technological problem.  It is a business problem
between you, your registrar and the registry.
 
> for that to happen they are going to require tools to manage their

How is the liability different from that of accepting NS records?
DS records don't magically change the liability.  Stuffing up either
NS or DS records will break the delegation.

> until they are forced to act?
 
Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Jul 2010 13:27:41 +1000

In message <[email-masked]>, Phil
lip Hallam-Baker writes:
> On Tue, Jul 20, 2010 at 12:12 AM, Mark Andrews <[email-masked]> wrote:
> >
> > In message <[email-masked]>=
> , Phil
> > lip Hallam-Baker writes:
> I am not asking about the TLD keys, I am asking about my keys.

I will repeat myself.  The parent zone has DS records added to it
not DNSKEY records.  Your keys are added to your zone so I presume
you know how to update your zones.

> And I really hope that the mechanism for handling the name holder keys
> recognizes that registering a million keys is different to
> distributing a hundred where all the parties know each other
> personally.

Well you know your parent or its agent (registrar).  You hand the
DS to them to publish.  The rest of the world gets the DS from them.
The only keys that have to be widely distributed are those for the
root zone and that's a similar problem to distributing the list of
root nameservers and their addresses.  Millions of recursives server
operators have managed that.

> You would not be saying "go ask your registrar when they are going to
> support adding DS records" if you didn't know that the answer was that
> the registrars have made no commitment to deploy.

Well pick one that does.  GoDaddy does accord to reports I've seen.
There are others that also support DS records.

> Holding a key signing ceremony is not a new technological achievement.
> It is being held now with great fanfare in the hope that if everyone
> makes enough noise about how much momentum DNSSEC has that the
> opposition of the registrars will somehow disappear.

No one said it would magically fix things.  It does however remove
one of the more common excuses people have been using to not do the
could of minutes work that is required to turn on DNSSEC.

> I don't see why that strategy would work. I have certainly never seen
> it work in the past.

We go complain to your registrar.  Say you will take you business
away unless they add support and do it when they don't.

> You are an engineer. If the technology does not meet the business
> needs then you have failed.

The technology is not the problem.  It's getting the registrars to
change their web forms to support adding DS records.  That is the
last step.  EPP supports DS.  The nameservers support DS.  The
clients support DS.

Adding DS records is really no harder than adding NS, A and AAAA
records that are required to make a delegation work.

> If DNSSEC is not going to fail we need to re-engineer it to propose a
> business model that actually works. Sitting on the sidelines and
> shouting 'the technology is perfect damit, go make the business model
> work', is not going to solve the problem. Nor is 'go away, my
> technology is perfect, perfect I tell you'.
>
> What has me very worried here are the comments to the effect 'the
> registrars are behind'. What if the registrars are not 'behind', what
> if they have no interest in deployment or are actively opposed but
> unable to say so openly while Cerf and co are saying that DNSSEC is
> the historic solution to solve the problem of Internet security?

Except they arn't all against it.  Some have already started accepting
DS records.
 
> Yes they do.
> An NS record specifies the address of the DNS server

No. It specifies the NAME of a nameserver.  A/AAAA records specify
the addresses.
 
> A DS record specifies an intermediate certificate in the chain of
> trust for authenticating any entity that is attached to the domain.

And a registrar should be treating changes to NS, A, AAAA and DS
records with a equal level of respect.  They shouldn't be accepting
changes from anybody.  They should already be doing the level of
checking needed for DS records for NS, A and AAAA changes.  Afterall
stuffing up any of these will break the delegation / allow it to
be hijacked.
 
> In the case of an NS record it is established that the design does not
> provide security in the DNS layer and this has to be provided
> independently via an end to end mechanism such as SSL with DV or EV
> certs.

You are confusing the trust level needed to add/change records to
the database to that of the transport used to retieve data from the
database.

> In the case of a DS record the design is expressly designed to provide
> for authentication of assertions relating to a domain name distributed
> through the DNS.
> 
> 
> --=20

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 21 Jul 2010 10:08:36 +0200

> operators have managed that.

Would be great if the list of root servers and list of trusted root certificates could be distributed in one easy to install file...

---

From: Tony Finch <[email-masked]>
Date: Wed, 21 Jul 2010 16:47:46 +0100

On Wed, 21 Jul 2010, Iljitsch van Beijnum wrote:
>
> Would be great if the list of root servers and list of trusted root
> certificates could be distributed in one easy to install file...

At the moment BIND comes with a lot of bootstrapping data compiled in,
including the root hints and the DLV trust anchor. I expect that it will
soon include the root trust anchor too.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FITZROY SOLE: NORTHWEST 4 OR 5, INCREASING 6 AT TIMES. MODERATE OR ROUGH.
SHOWERS. GOOD.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Jul 2010 09:27:10 +1000

In message <[email-masked]>, Phil
lip Hallam-Baker writes:
> Mark,
> 
> If you didn't know I was right you would have addressed my actual
> argument rather than look for idiotic technical details that have no
> bearing on the issue itself.
> 
> Yes, I know what a DS record is technically, and you know that I know.
> And you know that as far as liability is concerned putting a DS record
> in there is going to provide the location of a server, albeit by
> reference.
> 
> Now I worked in the practices section of a major CA at the time that
> it was being established. I saw the development of the risk and
> liability mitigation strategy being developed first hand. I had
> frequent discussions on the matter with Michael Baum who was leading
> the effort.
> 
> The expertise you are quibbling over can be found in a O'Rielly
> nutshell handbook. You are not quibbling to elucidate the issue, you
> are quibbling in the hope that by demonstrating I got something
> 'wrong' that you can ignore the issues that I am raising. Looking
> through your post I cannot see how you could be confused in the manner
> you purport to be confused.
> 
> If there is going to be an unbroken chain of trust then at some point
> there has to be a point where the registry signs the domain owner key
> and it is damned obvious that that is the potential weak link in the
> chain. I don't want to be more specific that that because I know from
> previous interactions that if I try to be precise the response will be
> to try to distract with irrelevant nitpicking.

Yes adding data to the parent zone requires secure authenticated
communication.  DS however are no diffent to NS.  Both require the
same level of authentication.  Yes it is subject to potential social
engineering attacks.

> What is worrying me is that if the liability issues had actually been
> considered, the answer to how my keys get into the domain would be 'go
> read document X.' because it really isn't possible to do the liability
> analysis on 'that will work the same way as it happens today'.

What's the liabilty for adding wrong NS records today?  What I'm
trying to say is that DS records really don't change the problem.
You already need a system that is secure today regardless of what
data is being added.

> It is very easy for the large registrars to sign the DNS zones for the
> servers they operate in house. It is not easy for the zones operated
> locally - which are the ones that people are most likely to want to
> DNSSEC.

It really isn't that hard and it continues to get easier.

Tell named to use dnssec.

zone "example.com" {
	type master;
	file "master";
	key-directory "/var/named/keys";	// where to find keys
	auto-dnssec allow;
	....
};

Create the keys where named can find them.

% cd /var/named/keys
% dnssec-keygen -f KSK example.com
% dnssec-keygen example.com

If you want you can use a HSM to generate and store the keys but I won't
detail that here.

Tell named to sign the zone with the keys.

% rndc sign example.com

Get the DS records to pass to the parent.

% dig @::1 +noall +answer dnskey example.com > junk
% dnssec-dsfromkey -f junk example.com
(this will extract the KSK and generate DS records for it)

If you don't want to use dig, you can get the records direct from the
master file or from the .key file generate by dnssec-keygen above.

If future we may add something like

% rndc getdsset example.com

to retrieve the ds set you send to the parent.

In the future "auto-dnssec create" will work and you won't need to call
dnssec-kegen and rndc but that requires a working /dev/random.

All the vendors are improving their products to make this easier.

> And before I place any reliance on this contraption, I want to know
> the full process by which the keys get into the domain and how each
> link in that process is secured. Because it would be rather sad if I
> spend time signing my zone and the link between the registrar and the
> registry is secured by the type of password an idiot would have on his
> luggage.

Well ask the registry.  They have procedures today that should be
secure enough if they are doing their role correctly regardless of
whether the zone is signed or not.

> If any registrar can validate keys in any zone in any way they please
> then that means that there really isn't any security here at all. I
> might think I am going to microsoft.com but mcolo registrar may have
> just  hijacked the domain. Yes I know about domain locking, but I want
> to know what controls are in place to put it into effect.

Well ask the registry.  They have procedures today that should be
secure enough if they are doing their role correctly regardless of
whether the zone is signed or not.

> This avoidance of difficult questions is precisely the reason it has
> taken fifteen years to get to this point and the reason I do not have
> any confidence in DNSSEC being usable in the next ten. The same people
> responded in the same way when I brought up the NXT record issue and
> then we went through the same thing again with the EU privacy laws.
> 
> Every time the response is to try to beat down any question.
> 
> If my questions seem vague it is because they are about the real world
> and that is rather vague.

I'm not avoiding the question.  I'm pointing out that the level of
security required to add data to a TLD should already be sufficient.
If it isn't you should have been complaining a long time ago.  DS
is just more data that needs to be treated securely.

What DNSSEC does is secure the path back to the client.
 
Mark

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Jul 2010 10:04:25 +0900

>> to try to distract with irrelevant nitpicking.

Any chain is breakable by MitM attacks on its intermediate links.

> same level of authentication.  Yes it is subject to potential social

That's how DNSSEC is not secure end to end and only as secure as
plain old DNS (assuming both are properly implemented, though
proper implementation of DNSSEC should be a lot more complex
and, thus, difficult, if not impossible, than plain old DNS).

The end to end security can be established only by sharing a security
information directly and securely by ends without any intermediate
entities such as CAs.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Jul 2010 10:10:16 +0900

> soon include the root trust anchor too.

which means cryptographic chain of security is expected to be
broken at the root.

Congratulations for the historic moment.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Jul 2010 10:47:47 +0900

Phillip Hallam-Baker wrote:

> What Mark is saying here is that DNSSEC is not designed to provide
> very much security and so does not need to be very secure.

What I'm saying is that plain old DNS is no less secure than
DNSSEC.

> What I am saying is that people are already assuming that DNSSEC
> provides a very much higher standard of security and that this is
> going to lead to new security failures.

Right, people who say "Historic Moment - Root zone of the Internet
was just signed minutes ago!!!" are easy victims.

 > 1) Cancel DNSSEC
 > Not happening, move on.

The cancellation is not happening primarily because DNSSEC is
not really happening.

 > 3) Design a DNSSEC 2.0 that meets the expectations.
 >
 > Which is I think a lot easier than it may appear.

All we need is real deployment of DNS with longer message IDs.

See my recent (7/13) dnsext mail titled:

	[dnsext] Extended ID or ask again

for details.

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Jul 2010 08:06:04 -0400

Yes they do.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Jul 2010 08:07:45 -0400

Quite, and completely eliminate the risk of a DDoS attack on the root servers.

Very easy today when the root file is 200 nodes. But what is it going
to be like after ICANN has managed to sell TLDs to everyone in the
F500 and so on?

Might be some interesting fireworks there as 'non-profit' ICANN
charges $50,000 per application but the root zone operators are
unpaid. Nice little earner that. Trebles and pay rises all round.

Beckstrom is at least a serious contender for whom the ICANN money
might be considered a competitive salary. The same could not be said
of his predecessor with a straight face.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Jul 2010 08:40:06 -0400

Mark,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Jul 2010 21:23:10 -0400

What I am saying is that people are already assuming that DNSSEC
provides a very much higher standard of security and that this is
going to lead to new security failures. Remember that an initial
response to the Kaminsky attack from at least one vendor was that DNS
was designed to be vulnerable to cache poisoning.

I see three options

1) Cancel DNSSEC

Not happening, move on.

2) Educate people so that they understand exactly what security DNSSEC
is going to provide.

Good luck with that one. People will do silly things, ignore all the
warning labels and then blame the protocol. There is a real risk that
some will sue. And telling people that DNSSEC is not going to secure
the Internet is not going to be very easy while Vint Cerf is out there
telling people that it is.