ICANN Brussels
Global DNS Vulnerabilities
Monday, 21 June 2010


>> Ladies and gentlemen, if you would be kind enough to take your
seats, we'll begin our program momentarily.

Once again, please turn off your telephone ring, and we'll be ready
to start.  Thank you.

>>ROD BECKSTROM:   Okay.  Welcome to the panel on DNS
vulnerabilities and risk management.  Thank you for joining us.

We are clearly honored to be here today with some of the leading
experts and thinkers in the domain name system and security, and this
is perhaps one of the most powerful panels of intellect assembled on
the topic, at least in some time.

I'd like to quickly introduce the panelists, and then we will hand
it over for their opening remarks, which will go for up to eight
minutes each.

So after four of them, it will be approximately 30 minutes.  After
that, we will go to questions from the floor and also to questions
from remote participation, as Rob Hoggarth is in the back of the room
and we're taking questions from around the world live.

I will start with here to my right, Dr. Whit Diffie, who received
his B.A. from MIT and his Ph.D. here from Europe from Eidgenössische
Technische Hochschule in Zurich.  

Whit is one of the fathers of public key encryption and one of the
greatest living thinkers in cryptography.  And I have the incredible
honor to work together with Whit in Palo Alto and to learn from him. 
He's made many significant contributions in the field, and we look
forward to his remarks.

He will be followed by Dr. Paul Mockapetris, here to my left.  Dr.
Mockapetris received his bachelor's from MIT and Ph.D. from the
University of Irvine in California.  He is generally considered to be
the father of the domain name system.  He wrote the foundational RFCs
in the IETF process that design the distributed hierarchical
decentralized solution which the DNS is.  He's also the chair of
Nominum, which is one of the world's leading resolvers, which is very
critical in the DNS system globally.  And he's also a UPMC at the
Pierre and Marie Curie Institute in Paris, where he spends
considerable time.  So he moves between Silicon Valley and Paris. 
And we're just extremely, extremely honored to have Dr. Mockapetris
with us.  To his left, we have in many ways not only one of the
fathers of the Internet, but in many ways one of the fathers of
DNSSEC and certainly one of the greatest catalysts for DNSSEC, who
scarcely requires introduction.  That's Dr. Steve Crocker.  Who
received his bachelor's from MIT and his Ph.D. in computer science
from UCLA.

And he's also the chairman of the Security and Stability Advisory
Committee of ICANN.  And he is also on the board of directors of
ICANN and is, of course, author of is it RFC 0 or 1?

1.  RFC 1, start of the entire request for comments process that is
still used for developing Internet standards today in the IETF.  So
we're so honored to have Dr. Crocker with us.

To the left of Dr. Crocker, at the end of the table, we have Dan
Kaminsky.  Dan received his bachelor's from Santa Clara in operations
management of information systems.  Dan became very famous almost
exactly two years ago when he unveiled at Black Hat the greatest
exploit of the domain name system in the history of the DNS.  And
when I had a conversation with Dr. Mockapetris two weeks ago, he was
referring to the history of the DNS in two epochs or time periods,
pre-Kaminsky and post-Kaminsky.  I can't think of a higher accolade.  

And Dan is now also a very important catalyst for progress in DNS
and the discovery of this fundamental exploit that he first worked
with industry to help them patch key technology components before it
was then released.  But he has been contributing very significantly
to other enhancements of security in the global Internet and is
extremely dedicated to that.  And also has a very great understanding
of the hacking world and what takes on in that dark world and how
that dark world touches and connects with the DNS and other
activities.  So that is our panel today.  We're extremely honored to
have them.  We will work through the panel with Dr. Whit Diffie
first, followed by Dr. Paul Mockapetris, followed by Dan Kaminsky,
and with the closing remarks from the panel by Steve Crocker.  And
then we'll go for questions.

Whit.

>>WHIT DIFFIE:   Well, the last resort of a scoundrel is to change
the subject.  So I am going to invoke the scoundrel's prerogative and
just try to make a statement of what I see are the broadest roots of
security problems in the Internet.  And in some sense, I think one of
the fundamental roots has nothing to do with networking.  It is
automation.  We are enter the era where we have processes, work going
on with far less human intervention than we have ever had in the
past.  And so automated updates, network management systems, networks
running largely autonomously, not dominated as they were in the past
by things like human radio operators.  And it shouldn't surprise us
so much that in these same networks, we are finding some truly
wonderful things.  We don't happen to like them, right, but in a
sense, viruses, worms, and botnets are the first living creatures
actually functioning and doing something created by people.  They
don't yet exhibit evolution.  If you're asking what's going to hit us
by surprise, at some point, that will.

Now, there -- if you look particularly -- and the lawyers are trying
to do this -- at analogs to the Internet environment in the past, you
don't come up with any, of course, that's exact, but you come up with
some things with some of the same properties.  And maybe the greatest
one is cities.  7,000 years or so ago, we moved into cities, which
multiplied the ratio of contacts among people and therefore did more
than maybe anything else in human history to speed up progress of
human thinking.

In another sense, the Internet has a lot in common with the oceans
and the law of the sea.  It doesn't belong to anybody.  Maybe near in
shore, you can exercise some ownership.  But it is a common resource
that we all need to use.  And yet it's beyond anybody's individual
policing.

And then, finally, and maybe more limited, there's merely a century-
old phenomenon, which is the discovery of the ether, of radio,
something that transcended national boundaries, allowed communication
across the entire world.

You take some of the properties of those things and put them
together with automation, the fact that in some sense we're now in a
science fiction sort of world with the additional creatures living in
it, and I think you begin to see the roots of this problem.

Now, at a slightly more mundane level, the security problem of the
Internet is that the essence of the Internet is diversity.  The
Internet is a network meant for friends to talk to enemies.  All
secure networks in the past were networks of friends, a command and
control network, a NATO network, a U.S. network, a Russian network
are all networks in which all of the people who are supposed to be
talking -- and security means keeping other people out -- are
cooperating.  The essence of the Internet, the virtue of the
Internet, is that it's the means of communication among people of
diverse interests.

So where does that bring us?

One last point.  We've been, incidentally, very, very poor about --
as far as I can see, about predicting security problems in the
Internet.  And ask yourself, where will new ones come from?  The
thing to think about -- and it will make you more money than security
-- is what new things can be done with the Internet.  Because
whatever new enterprises are flourishing, those are the enterprises
that will be attacked and exploited.

Thank you.

>>ROD BECKSTROM:   Thank you very much, Whit, for a powerful
overarching view of some of the issues.

Paul.

>>PAUL MOCKAPETRIS:   Thank you very much.

Technical issue.

I'm both a researcher at UPMC as well as chairman at Nominum.  And
in some ways, that reflects the two biggest things I think we have to
think about in considering security here, and that's sort of the
present and the future.

Rod talked about how today there's sort of the pre-Kaminsky and the
post-Kaminsky era.  But we're actually in sort of a transition period
between the Kaminsky event and the DNSSEC getting critical mass. 
Perhaps that's 50% of the Internet, or whatever criteria you want. 
We're in that gap right now.  And so one of the questions is, what
can we do to keep users same.  And then the other question that
immediately follows on to that is, what users are we talking about?

Given the statistical nature of Dan's attack, users that are on a
slower network are actually safer, because the server can be attacked
more slowly.  The other thing is, is they're more visible.  Nominum
supports about 200 million broadband users worldwide, people like
Deutsche Telekom use our software, and so forth.  So when the
vulnerability came out, we immediately had people coming in, testing
the software to see if they could get in.  We also had people testing
to see whether or not we were using their particular version of a
defensive mechanism.  We had both false positives there as well as
successful defense in that people said, "Well, you're not randomizing
ports, which we know is the only defense."  And it's not.

So I think one of the things we need to do today is to think about
defending both in the present and in the DNSSEC future, because
there's a lot of legacy people out there right now.

Enterprises, I think, are a place where there's an unusual security
threat.  I run into people all the time -- I was talking to somebody
who runs a hedge funds.  And he said, "We don't have to worry about
security.  We've a 10gigabit network."

I said, actually, what that means is, you know, if you think about
monkeys trying to pass- -- you know, passwords to break in, you know,
you've got some monkeys on steroids.  You know, it doesn't make you
safer.  Speed kills in this arena.  And I think that's something
that's not well understood.  

I think lastly, there's this question about how do you guarantee to
the new user, say, my ten-year-old, how do you guarantee to them that
the Internet does what he thinks it does?  I mean, for example, if he
types a name with a dot in it, is he getting a domain name that ICANN
created?  Or is he getting a search term that somebody else has in an
Omni bar?  I'm not sure we know anymore.

I think the real thing we need to do in the present is figure out
what are the simple safe harbors that we want to give out to users. 
And we ought to understand that DNS is only a small part of the
Internet.

How do we get to the promised land of DNSSEC?  Well, I -- one way to
do it would be to have a billion dollar event, I think.  That would
probably accelerate things.  I think we need to think a lot about how
do we have a kinder way to get to that level of security.

Moving on to the future.  There's a lot of people who spends time
these days talking about clean-slate approaches and redoing the
Internet in toto and so forth.

I think the first principle there is that we can't -- in the real
world, we can say, "Gee, we want to go back to the days when we had
clear-running streams and lots of trees and so forth and so on."  We
can't do that return to nature in the Internet.  We have to invent it.

So I think that what we need to think about from a standpoint of
DNSSEC and also bridging that gap is, it's a fulcrum, you know.  What
is it that we can invent as the lever to use the new security to
create new opportunities and justify the expenditure?  You know.  And
I think that we have to take a look at some of the things of the
past, like RFID and ENUM, which were supposed to take care of RFID
tags and phone numbers on the Internet and through the DNS and didn't
quite work out as we expected.

I think we need to think about not how to have everybody pay for a
domain name, but to have everybody have one.  And perhaps in the
capitalist world, they have a different solution from in a socialist
world and on and on and on.  But, I mean, I think that each political
system needs to figure out how to give everybody the identity they
need and stop fussing around with sort of, well, we've got 5% or 10%.
'Cause I think the ultimate goal is that:  Digital identity for
everyone, and to some extent, everything.  I think we still have a
lot of problems to solve with regard to -- if I want to have my
computer and my cell phone coordinate with each other, how can I be
sure that they can do that safely?  And how do I name things that I
want to coordinate worldwide?

So I think that's -- the other thing we need to think about with
DNSSEC and the security is, if we had it, what is it that enables? 
Because I think that's really the thing that's the choice we have. 
It's either that or the billion dollar attack.

Thanks very much.

>>ROD BECKSTROM:   Thank you, Paul.

Dan.

>>DAN KAMINSKY:   Hello, everyone.  I am apparently the hacker in
the room.

You know, you would consider that my biases would be entirely
towards security and, you know, strange tricks that you can do on
networks.  But in terms of my actual background, I have spent most of
the last decade in corporate work.  So a lot of time at Cisco and
Avaya and consulting at Microsoft.  And I say this to basically
betray my bias, which is, there are very strong corporate reasons why
I see DNSSEC as a critical move for us to be making.

Put simply, with a lot of the systems that I advise people to build,
we can tell people how to connect across organizational boundaries,
but we're just not very good at telling people how to secure that
connectivity across the same organizational boundaries.

What's interesting is, that's about to change.  A few days ago, I
actually spent some time signing the root.  This is not an expected
series of words for me.  But as one of the trusted community
representatives, it was my duty to supervise six hours of careful and
transparent work, put together by ICANN.  There's something you guys
have to understand.  There are a lot of people who have been pushing
for DNSSEC for ten years and who you would have expected to have been
one of those people.  You know, I'm not one of those guys who's been
backing DNSSEC for a while.  In fact, as an engineer, I thought all
of this work was too much work for too little benefit.

I was wrong.  Nobody realizes how special the DNS infrastructure
actually is.  It's not entirely centralized.  It's not entirely
decentralized.  It is a radically competitive and strongly delegated
name space with no peer in the world.  As a foundational technology,
it was there 25 years ago, thanks to Paul, and it will be there 25
years from now.

I can't name anything else with a 50-year life span.  All of you
have built something genuinely incredible.

The purpose of DNSSEC is to defend the data that you provide to your
customers.  Like it or not, there's an increasing series of parties
in between you and the people you have been serving for years who are
willing and able to change the data that you send.

Now, DNSSEC is going to require some work.  It is going to require
better servers.  It is going to require reductions of costs for
deployment.  Let's be honest:  It's a little difficult to put this
out there.  That's getting a lot better.  I call this out as an
engineer because it is a problem now.  I call it out again as an
engineer because when I finally sat down, I gave my word that I would
look at this technology with open eyes and give my honest opinion.

I realize the implementations are a little bit rough, but the
protocol itself actually has the means to be very affordable, very
elegant, very simple to deploy both on the server side and on the
client side.  And as we see with the root getting signed, that this
is really going to be something that can lead to return on investment.

I promise you, we are going to see far more efficient, effective,
and usable server infrastructure.

But there is an aspect that does need to be called out.  DNSSEC is
about securing the read-side of the equation.  In other words, once
there is data in the DNS, DNSSEC will get that data to users safely. 
And if you're wondering what the value is, I would like to be able to
receive an e-mail from my bank and know it actually came from my
bank.  If you wonder how we're ever going to get to that secure e-
mail future, DNSSEC is the way.  Getting that sort of key-reading
ability is going to come from DNSSEC.

But the one thing that we have to keep in mind is, the right side
matters, too.  There are people who will attack your servers.  I am
sorry, there is nothing I can do about that.  There are people who
are going to try to corrupt your databases.  This is not hyperbole,
it is simply fact.  DNS secures the read side.  You secure the write
side.  My hope is, in the long run, however much energy we put into
getting the read side secured, we as a community can act as a
resource to help your write side stay safe.

>>ROD BECKSTROM:   Thank you very much, Dan.

Thank you very much, panel.

We'd like to now open up to questions from the floor.

Oh, Steve.  Gosh, I'm so sorry.

[ Laughter ]

>>ROD BECKSTROM:   I thought I was going down a row.  How could I
forget.  Dr. Crocker, please.

>>STEVE CROCKER:   What did Brendon Sullivan say, "I'm not a potted
plant"?

Thank you very much.  And, Rod, I appreciate the promotion of my
degree to MIT.  But, actually, although I spent some quality time
there, both my degrees are from UCLA.

>>WHIT DIFFIE:   As an MIT man, I would never speak ill of UCLA.

>> Nobody's perfect, Steve.

>>STEVE CROCKER:   We're here to discuss the vulnerabilities and so
forth.  And I think we've reached the point of maximum danger.  This
is the time in a complex system when the politicians decide that it's
so important that they've come to help.  And now we really are in
trouble.

The --  One of the things that happens as one raises the attention,
there's both positive and negatives.  The positive is that with the
increased attention, we have opportunities in terms of resources and
getting on the agenda that has been difficult in the past.  And
that's actually all to the good.

The negative that comes is confusion and lack of clarity and
conflation of different issues.  So falling into the trap of taking a
teachable moment here, let me just make two distinctions here.

In broad terms, Dan's notion of the write side and the -- yeah, the
write side and the read side, the terms I want to use are
registration of data putting information into the DNS, and then the
name resolution, or the lookup side.

And the other distinction I want to make is that in these systems,
there's two very broad classes of threats.  One is that the
information is going to be modified or corrupted.  And the other is
that the systems are going to be made unavailable by denial of
service attacks.  So if you take those two pairs and, you know, all
the combinations, DNSSEC closes big holes in one-quarter of that
space, that is, it protects the information during the lookup side. 
It does not do anything to protect the information about being put
in.  If incorrect information is put into the system or is modified
at registration, then you're in trouble.  And in either case, if the
registration side or the lookup side is attacked from a denial of
service attack or taken down in some other way, DNSSEC doesn't help
at all.

So in the broad spectrum, just focusing on DNS, although we have --
we're actually at a momentous time -- and I had the privilege of
going down to observe the key ceremony last week.  And it truly is --
was an amazing moment.  And you will hear much more about this as the
process proceeds over the next several weeks and the root is signed
next month.  The importance, I think, will be felt worldwide.  Even
so, that is -- leaves open -- or leaves untouched the vulnerabilities
in the other three-quarters of that chart, if you will.

The -- DNSSEC brings new applications, makes possible new
applications.  Dan talks about the possibility of securing e-mail. 
It's not a single direct step that you have DNSSEC and therefore you
have secure mail, but you have a platform that makes it possible to
build those kinds of applications.  This will unleash, open the doors
in a very, very important way that many of us have been looking
forward to for a long time.

At the very same time, of course, it brings a new class of stresses
to the system, opens up more difficulties in communication.  And so
the -- you know, returning to the point that I was making about the
politicians are here to help us, we have to take extra effort to
clarify the dialogue, to remove the confusion and conflation and
bring clarity to the whole process.  I'll stop here.  And now we can
get to some questions.

>>ROD BECKSTROM:   There we go.  Exactly.  Now is the appropriate
time.

Do we have any questions from the floor?

Okay, Rob, where is Rob?  Rob Hoggarth, back of the room.  Do you
have a question, Rob?

>>ROB HOGGARTH:   Not at this point, Rod.

>>ROD BECKSTROM:   We'll start off here.  One of the questions I
have for the panelists is, what actions can the members of the ICANN
community take now, individually and collectively, to address some of
the risks that you identified?  You spoke of some common risks, like
DNSSEC, and you spoke of other risks that are related, and other
risks that are independent.

What are some of the things that this community, the ICANN
community, should be thinking about?

>>STEVE CROCKER:   I'll jump in.

I also like the division about pre-Kaminsky and post-Kaminsky.  I
think the right term is how to survive Kaminsky; right?

One of the things that we're seeing a lot of is corruption of
information at the registration side, everything from stealing,
hijacking of domain registrations, to modifications in the databases
and so forth.

There are a tremendous number of organizations that are responsible
for the correctness of the information.  You have registries, you
have registrars.  Every one of the top-level domains is run by a
different organization.  And then you have a hierarchy of registrars
and their subordinate organizations, resellers and so forth.

As is common in any kind of system that involves that many different
organizations, there's quite a variation in the quality of those
operations, and there's also pecuniary motives that lead some of
these organizations to look for ways to enhance their revenue,
perhaps not always to the advantage of the people that they're
supposedly trying to serve, that is, their registrants.

So it's important to raise the standards, shine quite a strong light
on the -- on those class of operations, and try gradually to improve
the standards not so much in a formal technical sense, but the
standards of conduct, if you will, and the quality in the marketplace
so that it becomes a trusted marketplace rather than one that is
inherently distrusted.

Lots more things to say along that line, but I think that's a very
general and broad thread.  And ICANN, although it has a very, very
limited actual control of the -- some aspects of the top-level
domain, is clearly in a position of having leadership with respect to
the dialogue, the bully pulpit, if you will.  And forums like this
and other aspects of this are areas where we can try to shine a light
on those issues, raise the dialogue, and improve the expected
standards of conduct, I would say.

>>WHIT DIFFIE:   So in what you're saying, Steve, I'm reminded of a
security problem I faced over a long period of time as security
officer at Sun, which is, we did things like signed outgoing code
patches, whatever.  And that's the easy part of the problem.  The
difficult part of the problem is having a procedure that guarantees
that the things you're producing are worth signing.

And in this registration procedure, at some point, you get to where
the information is signed.  It's getting things into that format and
being sure those are reliable that's the tricky part of it.

>>PAUL MOCKAPETRIS:   I guess I have a much simpler view of this,
perhaps because I deal with the consumer market every day.  I would
like to be able to know, if I have a link in front of me and I'm
clicking on that domain name, whether or not I've just sort of taken
a lethal injection or not, okay?  I just want to be able to tell my
kids, "Yeah, you can click on this or, no, you can't click on that,"
or there's some way you can tell.  But today's Internet, I get the --
my morning mail.  God knows where all the toxic stuff would have
taken me that's thrown away automatically.  But then there's the
stuff that came through the filters.  And Lord help me if there's
somebody out there that has a particular animus for me and is going
to specially craft a message so that it involves Lithuanian
CASSOULET, and good red wine.  I may click on that link and it's
lethal.

If we're in the process of providing identifiers, can we do anything
to make them safer.  I think that's one of the future issues that
we're talking about that we need to address.  Do we want to have a
reputation system that when I click on the link, says, "Okay, you --
do you want to reconsider that, Paul?"  I mean, when I go out for a
restaurant in Paris, oftentimes, I'll look it up on the Web before I
go there.  And if they say, "Oh, you know, there's rats in the
kitchen," I probably won't go there.

I recently joined the board of an organization called
StopBadware.org, and I know there's many of you in the governments
out there who restrict particular domains.  One of the things I think
we ought to look at as our next grand challenge is how do I do
reputation data on that so I can take advantage of the knowledge of
others, knowing that that's not perfect, but it's a whole lot better
than my ten-year-old's opinion of what's safe when he's sitting there
on his computer.

>>ROD BECKSTROM:   Go ahead, Dan.

>>DAN KAMINSKY:   Just to address the question, in the last couple
of years, we've seen Microsoft's New Zealand operations hijacked;
we've seen Comcast, one of the large ISPs in the United States, we've
seen his domain name get hijacked.  And we did not see them hijacked
using my flaw, which keeps getting named.  We actually saw them get
hijacked from the registrar side.  So the right side of the
registration side, people broke into the particular registrars and
changed records around.  That's a problem.  That's a real-world
problem we are seeing today.

It also exposes what I consider the absolute best part of the DNS
system, which is the fact that those registrars can either improve
their systems or their customers can leave those systems.  That's
what I call a race to the top.  It is in fact possible to have
registrars that have much more attention paid for security and treat
that as a competitive advantage.

This is a good thing.  This means that over time, the systems can
get better.  And there's --  Let me give you the honest truth. 
There's a lot of things that can't get better.  Because of the
registrar/registry split, things can.  However, what can happen and
what will happen are two totally different things.  

If we are to support the race to the top, if we are to support
increased security on the registration side or the right side, as I
referred to it, I do see some benefit to there being organizational
support.  There is a DNS CERT proposal that happened some time ago. 
I'm not going to specify specifically how it should happen, but as an
engineer, I can see some definite value for professional support for
a critical resource.  And at the end of the day, everyone here is
running an increasingly critical resource.  And I am a supporter of
better tools and people for you.

>>ROD BECKSTROM:   Thank you, Dan.

And we'll now take our first question from the floor.

Sir, if you could please introduce yourself first, and then mention
your question.

>>PAUL FOODY:   Sure.  Paul Foody.

You guys are talking about a topic that is way above me, but the
gentleman in the middle, you mentioned that we needed a billion
dollar event to really get this in the public mind.  I don't know if
you -- well, I'm pretty sure you will have heard about the Google
Maps situation, where they were driving around and accidentally
recorded all sorts of Wi-Fi communications.

Certainly if Google was not such a reputable company, if that had
happened with some other company, surely that would be the sort of
billion dollar event that would key into people's minds just how
fragile our Wi-Fi -- increasingly, Wi-Fi enabled worlds are, and the
need to make a much stronger commitment to security so people can't
just accidentally hack into or record e-mail transactions, bank
details and whatever else it was that was accidentally recorded.

>>PAUL MOCKAPETRIS:   Well, again, I was sort of trying to say the
billion dollar event is one of our two choices and the other is to
try to get better at protecting people and offering them alternatives
for security that they can understand.

You know, I think that without taking anything away from Dan,
somebody could have done the same sort of massive cash poisoning
attack by hacking BGP and being able to watch DNS data as it goes by.
Just because if you can see the data as it goes by, you can know what
the right answer is, and so guessing isn't even required.

And I can imagine several other scenarios.

I think one of the challenges for the future is not flaws in the
DNS, but -- or flaws in BGP or flaws in SMTP but people who exploit
combinations of protocols to have their attacks.

You know, with regard to the Google accident, I'm not sure if
there's a billion dollars worth of damage there.

>> Or any at all, yeah.

>>PAUL MOCKAPETRIS:   I am going to leave other people to kind of
figure that one out.

>>PAUL FOODY:   What I am saying is if that information had been
gathered by a disreputable company.

>>WHIT DIFFIE:   Which is surely is being.  A million war drivers
are going around recording data off of Wi-Fi.  And there's no
question Wi-Fi security needs improving.  If you are worried about
that kind of threats, we are in some sense -- the general direction
of this organization is to mitigate those things by facilitating end-
to-end security through the organizations you are talking to so that
local plain-text snooping doesn't do any good.

>>PAUL MOCKAPETRIS:   It's on both sides, though.  Because I was in
London with my wife, and she is surfing on a free Wi-Fi and she says,
"Oh, it says that we need a new certificate here, honey.  Should I
just click on that?"  I said wait a second!

So I was running into a Wi-Fi hot spot that was providing me a
harmful DNS service, which is another possibility.  Particularly for
some of you that might be connecting to open, free Wi-Fi from ICANN. 
I can potentially have a rogue access point up here under the podium
and trying to infect the important people up front, and I don't know
that they would know.

There are a lot of security angles to worry about here, and that's
one of the problems.  You have got to try and figure out how to have
a perimeter that's easy to understand and defend rather than one that
involves thousands of moving parts.

>>DAN KAMINSKY:   So I would actually like to address, one of the
things I have been pushing towards the security community is the need
to reduce the cost of deploying secure systems.

Google is driving around and they are picking up random wireless
access points like, let's be honest, millions of other people have
been doing.  Wiggle.net has over a billion observations.  It's okay. 
It's not the end of the world.  It's not a billion dollar event.

But the question is, why were there still large numbers of
unencrypted communications happening over those wireless links?  Why
were lots of Web sites being accessed unencrypted?  Why was e-mail
being received unencrypted?  Because at the end of the day the cost
of deploying secure systems remains very, very high.

One of the things to be hopeful with DNSSEC over the longer term is
that we will see all Web sites encrypted.  We will see all e-mail
encrypted.

And then it doesn't matter what's going on over Wi-Fi.  The Wi-Fi
layer isn't the part that needs to be the encrypted part.  The
encrypted part comes from DNS.

>>ROD BECKSTROM:   Thank you.  And now I would like to see if we had
a question from the remote participation group.  Rob?

>>ROB HOGGARTH:   Yes.  Bogits asks, do the panel think that the
work done in preparation by the community to deal with the side
effects of DNSSEC -- example, higher packet sizes -- has been
sufficient?  And if not, what would they suggest?

>>DAN KAMINSKY:   I think people have been incredibly, if not over
incredibly, protective of the stability of the DNS through the
transition.  People have been doing this very, very slowly, very
carefully.

I have no concerns on that front.

The only area where I think things are going to need to get better
is in terms of making it easier to actually do the deployments on the
server side and on the client side.

>>STEVE CROCKER:   Let me add a word.  I agree with everything you
just said.

More broadly, the deployment process is a lengthy process.  We're
well begun, and so that's quite heart warming that the process is
well under way.

There is a sort of broad difference between the speed with which
we're going to get signatures added to the zones and the speed with
which those signatures are being checked on the user side.  The
latter is running further behind, as is normal.

So the signature process on the signing side is moving forward.  We
now have a dozen-ish top-level domains signed and we'll double that
very shortly.

Things are at an earlier stage on the checking side, and, as Paul
said, and how is the user going to know whether or not the checking
has been done and is that going to be simple enough and reliable
enough for ordinary users like his wife and my wife, among others, to
know whether or not it's made a difference.

There are plug-ins that the check registry has a very nice little
plug-in for Firefox that tells you whether or not a domain has been
signed, and there will be other tools that will come along.  But
generally, less burden on the users, even for the very sophisticated
people who tend to make more mistakes than the ordinary people, I
think.

So all of this is going to take a while.  We are talking about
multiple years here as opposed to overnight.

And then the technical issues about packet sizes and so forth are
being attended to very carefully.

Thanks.

>>PAUL MOCKAPETRIS:   I'm sorry, I am going to have to be a little
less optimistic about all of this.

When we first started up the DNS many years ago, replacing the host
table, all of a sudden we introduced a new concept which was your
network connection might be defunct or a server might be down and you
can't get the answer right now.  So the mail servers all of a sudden
had to deal with this, you can't look this up right now which is
something they had never seen before.  It was the third answer
between here is the data, no it doesn't exist.  Sorry, can't tell
right now.

I think the ambiguity of the security process from a standpoint of
particularly during the transition is going to mean that there's
going to be a certain amount of pain and suffering and that we just
have to deal with that.

One of my hopes is that, you know, these mobile devices that come
out and get replaced every two or three years, pretty much by
definition, you have to get rid of them because their inside
batteries fail and you can't get them replaced or you have to move on
to the next 3D camera in the iPhone 5 or something like that.  I
think we have to start thinking about trying to have these
replaceable devices follow a higher standard for things like maximum
packet size, MTU, because all of the work-arounds we have for DNSSEC -
- you know, today's ten gigabit max size Ethernet packet is smaller
than an ATM cell was way back when we believed in ATM and said the
cell size is too small.  We need to be able to think about breaking
out and fixing some of those things.  And I realize it's a little bit
like fixing your kitchen.  I had a burner go out on the stove and I
said okay, I will replace the burner.  Sorry, sir, it would be better
to just replace the stove.  Well, sorry, sir, the stove is -- we
don't make it in quite that size so you will have to redo the
counter.  And these things tend to expand.

I'm hoping that in the mobile world and in new deployments we can
start thinking about how to fix some of the basic ossifications
because I think hardening of the arteries, not the hardening of the
concepts. Packet size.  Let's get over some of these problems and
let's try and do it in a mobile world with v6 and larger packet sizes
and all that other kind of stuff because there is going to be some
pain.  I have a DSL box that's ten years old.  I bet it's not going
to upgrade real pleasantly here.  I bet I have to get a new box.  I
already accepted that.  I have already accepted that in the mobile
world and I am told that's the Internet of the future.

>>ROD BECKSTROM:   Great.  Thank you very much.  Glad to see we have
some questions coming here.  We will be alternating from the floor to
the remote and back.

The question is over here now on the left mic.  Please, ma'am.

>>WENDY SELTZER:   Thank you.  Wendy Seltzer here, and my question
is how can we, as the technical community, and as the public,
distinguish between real security challenges and hype and scare
mongering, and how can we help to tone down the level of scare
mongering so that people continue to feel comfortable using the
Internet and all of the values that it provides and so that we can
focus where there are true challenges and places that we can really
make a difference.

>>DAN KAMINSKY:   I can say that from my own experience in this
space, security risks need to be paired with actions.  I can't tell
you how unproductive it is to throw your hands up and say, oh, my
God, look at all these things that are broken.  And then, okay, what
are you suggesting?

So at least my strategy through -- because I end up finding bad
stuff.  It's just what I do.  My model is if I'm going to find bad
stuff, it's my responsibility and it's our responsibility to match
that with an actual path towards remediation.

>>PAUL MOCKAPETRIS:   I think the IETF and the Internet world is
currently competing with a variety of more and more closed systems
that offer a higher level of security.  And so I think that what we
really need to do in the open technical -- open standards technical
community is try and develop new capabilities that allow people to
build on that, because I don't think it's a sure thing that the open
Internet style of the past is going to be successful competing with,
you know, closed ecosystems, which I think several of us all love,
from Apple and a variety of others, and I think that's one of the
real challenges.

>>ROD BECKSTROM:   Thank you.  We will take a question from remote
now, Rob, if you have one.

>>ROB HOGGARTH:   Yes, thanks, Rob.  This is a question from K.K.
referring to the previous answer by Paul.

But what of the issues Paul is discussing are in the scope of ICANN?

>>ROD BECKSTROM:   If no one else will take this I will take a stab
at it, and the answer is we will let the community decide that.

And now I will take a question here from the mic on this side.

>>STEVE DELBIANCO:  Steve Delbianco with NetChoice.  The man who
gave us the Kaminsky vulnerability probably this morning gave us the
Kaminsky conundrum, because when speaking about ways of improving the
integrity of identifiers, Dan said that the historical split between
registrars and registry, that wholesale retail legacy split would
prevent good things from happening as much as you might want to
improve the integrity of identifiers.  So I ask is it time to
reexamine whether that legacy separation, that requirement that I
have to use the registrar, is a time to reexamine that or should I be
able to go direct to a registry and cut out one of the steps that
makes it harder to ensure integrity.

>>DAN KAMINSKY:   So I can say this, and I am speak as an engineer
in this context here.

One of the fundamental risk areas in terms of the right side of any
system is the Web front end.  At the end of the day, there's
something that has to receive communications from the user and throw
it into a database.

There are ways of doing this right, there are certainly many more
ways of doing this wrong.

As an unexpected but interesting side effect, the registrar/registry
split has actually allowed you to choose which system you, as the
user, communicate with, which Web front end, which database, which
system that's maybe doing it right or doing it wrong.  So the split
has actually been useful in terms of allowing users to escape
potentially broken systems without having to my great their entire
system base to a new domain name.

Now, are there models in which a combined registry/registrar have
their own advantages?  Absolutely.

But as an interesting and I'm sure unexpected benefit.  The
registrar/registry split has had its impressive uses.

>>ROD BECKSTROM:   Thank you.  Rob from remote participation, please.

>>ROB HOGGARTH:   Yes, Rob.  (saying name) asks does the deployment
of DNSSEC combined with dynamic update might accelerate IPv6
deployment?  And if so, what are the two main reasons for it.

>>PAUL MOCKAPETRIS:   I would guess that they're mostly independent
issues.  I think there's a bunch of things that, if you will, are
hardening the arteries of the Internet, things like packet size,
limitations, things like running out of addresses.

And I see these as, you know, commonly building up plaque in the
Internet's arteries, but not have exactly the same mechanism.

>>ROD BECKSTROM:   Any other comments on that issue?  Or --

>>DAN KAMINSKY:   I'd say v6 and DNSSEC are somewhat orthogonal.  By
somewhat, there is a link in terms of not everything we're doing now
is entirely working.  The analogy about hardening plaque in the
arteries is actually a very good one.  It's a slow process of us
realizing things aren't working, and it's a slow process of, man,
we're going to be in trouble when IPv4 addresses run out.

Moving towards a model where we have a large number of -- a large
amount of address space and actual assurances on the addresses and
content at those addresses, that's going to be a better foundation
for us to build Internet applications on.

>>ROD BECKSTROM:   Thank you.  I'll take a question from here, please.

>>MICHAEL PALAGE:   Thank you.  Mike Palage.  Having attended ten
years of ICANN meetings and attended public consultations as well as
hallway discussions, I've never heard any attendants say, "How can we
make the Internet less safe?"  That's a positive.  I think everyone
here in this room has a vested interest in making it safe.

Now, I think, Dan, you talked about pairing security risk with
actions.  And I think that's a point worth expanding upon, because
one of the concerns I have had, and I think many other people in the
ICANN community have had, regarding ICANN's announcement for a DNS
CERT initiative is, are we potentially reaching for fruit higher up
on the tree?  You were talking about -- and Steve's SSAC has talked
about some of the lower risks in the registrar write side of the
equation.  So perhaps, Dan, maybe you could attend the RAA session
later this afternoon when we're going to be looking at how to put
safeguards, enhanced safeguards into the registrar side of the
equation.

So the question I have for you is, you said you saw value in
professional services in the DNS CERT.  Do you believe that ICANN's
role until that CERT program should be focusing on the lower-hanging
fruit, where it has some role, or potentially need to expand its
mission?

And, Steve, when you perhaps answer this question, when you were
talking earlier, you defined ICANN's actions not as limited or very
limited, but very, very limited.

So, again, I think the community's worried about mission creep and
focusing on what its core competency is as a technical coordinating
body.

>>DAN KAMINSKY:   What ICANN I think brings to the equation at the
end of the day is a centralization factor.  At the end of the day,
there is a canonical source for resources.

And I think when there's a problem, if there's a reaction, you want
to actually have a coordinated, centralized body where there's
actually some agreement.

We've seen other systems where there isn't that sort of
centralization, and things don't necessarily work as well.

And I'm being, you know -- you know, understating.

The exact governance matter of it is not something that I really -- 
I'm an engineer.  So I don't want to talk about the governance aspect
of it.  But what I do want to say is I absolutely see that there are
small registrars out there that don't necessarily have the resources
that the global DNS would like them to have.  At the end of the day,
we're all making resolutions.  We all want those resolutions to be
accurate.  Everyone wants things to be safe.

Do I personally think that there are -- that there could be more
resources available to make those resolutions safe?  Yeah.  Yeah, I
think there could be more.

>>PAUL MOCKAPETRIS:   I have a little bit of a disagreement.

I think that a lot of the initiatives to enlarge and enrich the
Internet do, indeed, have a negative security effect.  So, yeah,
people do, in fact, in this organization indulge in activities that
decrease the security of the Internet.

You know, adding international character sets so that my browser is
going to say -- is -- this appears to be a little bit different from
that, are they the same?  And a character set that I can't read,
exposes me to a little bit more danger.  Having more domains, having
more features, there's always a calculated thing we have to do here
that we are increasing the richness, and that always has a certain
amount of risk.

DNSSEC is going to provide new opportunities for denial of service
attacks, because you have to have a bunch of moving parts that are
checking signatures all the time.

So we need to think about the fact that everything has a security
implication, and in some cases, we want to pay; and in some cases
that means we're going to have to pay with additional facilities to
deal with that.  But, I mean, that's part of the calculus here.

>>WHIT DIFFIE:   What occurs to me is that probably different people
see and experience security on the Internet differently.  And, in
particular, maybe expanding the character set isn't so good to some
of the people who knew the original character set and work in the
original character set.  But it might do a great deal to clarify
domain names for people who speak and read Arabic or speak Russian
and read Cyrillic.  So things can cut both ways.

>>ROD BECKSTROM:   Well, I don't want to get into a discussion -- 
If I may, only because there are so many other people wanting to ask
questions.  So if we can come back.

Unless we have another panelist comment.

So, Rob, do we have another question from remote?

>>ROB HOGGARTH:   Yes, Rod, Zahid Jamil asks what effect, if any,
does DNSSEC have on filtering and blocking of domain names and Web
content.

>>STEVE CROCKER:   Oh, I like that question.

There are some cross-current and competing forces here.

The intent and purpose of DNSSEC is to provide some assurance to the
end system that the information that it's receiving is the same
information that was put into the system on the registration side, or
as Dan said, the write side.

And the -- some of the strategies for content filtering involve
substituting an alternative response, sometimes for the benefit of
the user, sometimes for the benefit of some other party who is trying
to impose a certain set of values or controls.

And in the past, the fact that the information has not been
cryptographically signed has provided an opportunity to do so in a
way that isn't visible or isn't detectable by the end system.  And
with the introduction of DNSSEC, that particular avenue is closed
off, or at least is detectable by the end system.

That is not going to be the end of filtering.  That's not going to
be the end of different technical approaches to trying to redirect
users or thwart users from getting to some sites or to protect users
if you like that particular point of view.  But it will change the
game a bit.  And I think it's not a clear-cut end of all of those
strategies, but it does certainly close off some of the pathways
there.

>>PAUL MOCKAPETRIS:   Well, on the opportunity side, the last thing
I want to do is to have reputation or rating data coming to me that
isn't secure; right?  Because if I want to shut off -- whatever I
want to shut off, whether it's child pornography, gambling, or
whatever, I need a secure way to distribute that information, which I
don't have without DNSSEC if I'm using DNS to distribute that
information.  So DNSSEC is a way to distribute that.  And that might
be a way to enable better filtering or those kinds of facilities.

Certainly some of the -- the techniques that people use to insert
ads are more difficult with DNSSEC, although I think it's -- it
changes the world actually surprisingly little.

You know, one of the questions I have is, who exactly gets to filter
what I see?  You know, 'cause right now, my service provider, my
browser, my operating system, God knows how many other people, are in
that loop.  And that's a philosophical question that I think
transcends DNS and, you know, refers to, you know, what do we want
the Internet to be in the future.  And maybe that varies from
jurisdiction to jurisdiction, to make it even harder.

>>DAN KAMINSKY:   So we've got a little bit of a messy situation,
which I'm just going to lay out, just so you can see it.

Someone looks up a name that doesn't exist.  And a false record is
returned.  This actually happens in the field.  Ah.  But it's okay. 
The user is not going to use -- might not be using the normal ISP's
DNS server.  He's using his own chosen name resolver, which actually
returns its own records that have its ads.  But the user is actually
running a browser plug-in that got installed by his laptop provider --
trying very hard not to name names here -- and that laptop provider
put in a plug-in that says, no, no, no, I'm not going to put in the
custom user DNS resolver -- ad injector.  I'm going to put in my own
ad injector.

So then the user's custom name resolver goes ahead and says, I'm
going to take over your entire domain, and I'm going to hijack it so
when it tries to go to your custom ad injector, it's going to go to
my custom ad injector.  We've got four layers of injectors here. 
This is not a way to build a reliable network.

So, you know, when we're talking about, oh, my God, DNSSEC is going
to make it so only one -- the one true thing can come back, I tell
you, I'm not even having my security senses going off.  I'm seeing my
reliability senses say, "Yes, finally, there's one answer, it's the
right one, and we can move on with our life."

There is -- the larger point to be made is, there are layers to be
doing filtering.  There are layers to be doing monitoring.  I am not
at all convinced based on actual engineering empirical data that DNS
is necessarily the right layer to do this stuff at.

[ Applause ]

>>ROD BECKSTROM:   Thank you, Dan.

And now we'll take a question from this side, please.

>> Bill Smith with PayPal.

I think Whit said at the opening that the Internet -- the essence of
the Internet is friends talking to enemies.

And I actually -- I think that's quite true.  However, I think it
started with friends talking to friends.  And over time, it has
evolved to the friends talking to enemies.  And I'm not sure that the
protocols, the governance models, the procedures we use have kept
pace with the change.

>>WHIT DIFFIE:   Okay.  Let me be a little more clear, then, about
what I meant.  I suspect most of the communication on the Internet
may be friends talking to friends.  But the key thing that
traditional secure networks don't do is talk to people who -- with
whom your relationship is unknown and eventually resolve that,
presumably either into a friendly relationship or it breaks off.

So I see the fundamental conversation as being between a salesman
and a prospect.  And salespeople, regardless of what the formalities
are, are only really interested in two things.  And their whole
livelihood depends on it.  Figuring out whether you actually need or
want what they have to sell, and whether you can afford it.  And they
will go out of band in any direction to try to find that out.  That
is a complex social function that is not, certainly, typical of
previous machine-mediated networks.  Very fundamental in the phone
network.  But the -- the problem here is a mixture of that potential
adversity with the extensive automation.

>>BILL SMITH:  I have a question, though.  And the question is
around the -- no matter how secure technically we make DNS or the
Internet, we are always going to have problems.  There will always be
bad actors.  And so as a consequence, we have to be prepared to deal
with the bad actors.

And so that is the world we currently live in.  It is the world we
live in in the future.

And what can ICANN do, what can this community do, to help us deal
with the bad actors today and in the future?

>>WHIT DIFFIE:   Are not these measures in one respect improving
forensics?  The more things you have whose origins you can trace
reliably, the fewer are floating around that are more difficult to
trace.

>>PAUL MOCKAPETRIS:   Not being a real security guy, I think I feel
a little bit of maybe the same angst that you do when I hear these
stories about how we have millions and millions of people that are
registering domain names, and, yeah, that's a great thing.  And I'm
willing to bet that at least a tenth of 1% of those guys are bad
guys.  Okay?  I don't think that, you know, the efforts to say, well,
we'll never let bad guys have domain names, I mean, take them away
from them, but it's not going to stop the problem.  I think we have
to figure out how to deal with different gradations of people who
have a legitimate domain name, perhaps from a totally different
jurisdiction, they legitimately own it, but their interests are
opposed to mine, and I want to be able to do whatever I can to
understand the two roles we have, whether it's a friend and a friend,
whether it's somebody I have talked to before and I know that we're
reengaging, rather than somebody masquerading, or what.

And, you know, I only see the reputation way as being a first step
along that axis.

>>ROD BECKSTROM:   Steve or Dan, anything you wish to add?

>>STEVE CROCKER:   I'll say something.

Yeah, we're a community that embraces a good fraction of the world,
and we're not going to have uniform behavior across everybody.  I was
in a meeting several years ago with a major credit card company, and
there was a meeting of cryptographers trying to design an ultrasecure
system.  A senior vice president stepped into the room and said, "You
guys are working a little too hard at this.  We have 100 million
people, 15 million of them you wouldn't want to meet under any
circumstances at all."  

The Internet is part of the all-inclusive nature of it is that we've
got people that you really do not want to meet if you can avoid.  And
there's nothing ICANN by itself or even in concert with everybody is
going to do to provide a uniformly clean and safe environment.  So we
just have to live with that.

We can do something with the very specific systems in terms of how
well they're run and some of the standards that are set.  But we're
not going to do anything dramatic about the broad set of users who
are out there and the broad set of people who are trying to achieve
each of their aims and pursue their agendas.  And there is no nice
place to draw that line, else we'd bring on all sorts of other
problems.

>>ROD BECKSTROM:   Dan, any remarks?  Or I'll move to the next
question.

>>DAN KAMINSKY:   Actually, let me say a few things.

You guys actually cooperate pretty well.  I've been, you know --
I've been watching the DNS community, first off, from dealing with my
own bug, with somewhere between happiness and shock, because there
was just a lot of really positive handling of, okay, we have a
problem.  We have to work together.  We have to work together without
leaking that we're working together, thank you.  There was a lot of
very good cooperation that I saw just with my own event.

Sometime later, I don't know how many of you were involved with the
Conficker Working Group's work, my good friend Paul Vixie actually
ended up having to deal with, you know, 100 different registries in
order to deal with a threat to the Internet at large, and at the end
of the day?  The cooperation happened.  And what this shows me is
that we know there are threats.  We're not in denial about them. 
We're willing to work together to fix them.  And this, at the end of
the day, is the fundamental cultural aspect that can pull us through
pretty much any threat that I think is going to come down the line.

>>ROD BECKSTROM:   Thank you, Dan.  And Conficker Working Group
certainly was a great example of spontaneous community collaboration
in the face of a great new hazard which appeared.

The process we're using is one question on each side of the floor,
remote, and then to the other side.  So if you wait one moment, Rob,
do we have another question from the remote?

>>ROB HOGGARTH:   Actually, Rod, we've had a quite dynamic
discussion in the chat room.  Captain Zoom asked to post this
comment.  He asked rhetorically, would the people in that room be
able to pass a basic Internet 101 test?

>>ROD BECKSTROM:   Yes is the answer from the floor.

Thank you very much.  Next question over here.

>>MILTON MUELLER:   Excuse me.  This is Milton Mueller, Syracuse
University.

There's no question that DNSSEC resolves the question between
resolvers and registries.  But the question is whether all of the
moving parts, which one of you raised, increases the fragility of the
overall system and whether the tradeoff is worth it.

In that regard, I'd like to ask you a specific question about an
incident that happened recently.  Apparently the ARPA domain, which
was signed, some kind of a record expired because of the key-signing
key incident, and the whole zone came down.  So what I'd like to ask
you is, what caused this event?  What was the response that was
taken?  And what are the implications of the overall analysis of this
event that would lead to perhaps a better tradeoff or what are the
implications for how we assess the tradeoff between greater security
versus greater fragility?

>>STEVE CROCKER:   That was a carefully planned event.  I was around
during the planning process and part of the consideration was whether
Milton would notice.

[ Laughter ]

>>DAN KAMINSKY:   You know, we've had a couple of outages that have
shown up.  There was an event with a dot DE domain where a transfer
occurred and unfortunately got truncated and only part of the German
name space actually was live.  So there was actually an outage.  And
nothing to do with DNSSEC.  There was a bug.  It had an effect.  Bugs
happen.  Like, it's not necessarily, "Oh, my God, you're using
DNSSEC.  Now there's going to be bugs."  It's, time passes.  Every
second that passes, there is some risk that a change will be made and
the change will actually be problematic.

The way you deal with that are through procedures, through being
very careful, and ultimately, by having the ability to respond to
events as they come.

The point to make, though, is, yeah, ARPA had a DNSSEC-related
event.  Dot DE had a non-DNSSEC-related event.  Things happen.  The
best we can do is try to manage things.

>>WHIT DIFFIE:   My response is to this general discussion of moving
parts, which I think is -- I think the term has profitably been used
to mean more moving parts than you need.  But one of the key points,
both about the modern world and about security, is we have now built
things with more moving parts than were possible rather short times
ago.

And with very, very good results.  Pentium processors work very well
with whatever number of hundred million transistors they have in.

But simplicity and security, indeed, have a general alignment, but
not a sort of a one-to-one fixed alignment.  And an example I like is
if you have a rule against sharing passwords and don't have a
mechanism for "A" logging in as "B," you are going to get people
violating your first rule because they need to do it to work together.

So you have to build security features that support the policies
that you want to have own though that makes the system more complex.

>>ROD BECKSTROM:   Okay.  Rob, do you have another question from the
remote participation group?

>>ROB HOGGARTH:   Yes, Rod.  Duncan Hart asks, does the panel
believe it's possible to build systems with the three properties of
scale, functionality and security?

>>STEVE CROCKER:   So --

>> Yes.

>>STEVE CROCKER:   Yeah.  I should -- This is Steve Crocker.  I
should comment that Duncan Hart and a member of the Security and
Stability Advisory Committee, and a valued member.  And so I
appreciate the question.

I'll echo Whit's short response.  Yes.  It's not for free, it's
challenging, but it is the proper goal.  And to give up on one of
those in favor of selecting the other two I think is the mistake that
has bedeviled us over time, and is the goal structure that we have to
have is to achieve all three.

>>PAUL MOCKAPETRIS:   I think in addition to scale, functionality
and security are a specific level of those three.  You have to add
time, and I think you get to pick any three out of that.  There's an
argument in security.

In order to implement large-scale DNSSEC servers, you know you have
to sort of plan ahead.  And there's this key rollover and a bunch of
other things going on, and it's almost like running a factory where
you have to say, oh, my God, how many zones do I have, and if I have
to resign them, how soon do I have to start before it's all done and
so forth and so on.

We went through this exercise at Nominum where we say it should have
a simple interface, and does that mean you can just tell it when to
reschedule all of these activities or did it mean you schedule it. 
And obviously if you are telling the program to schedule it, there's
complexity that's going on in there.  And if you are telling the
person there, you are telling the person.

Now, given that they have the responsibility, I think that, you
know, automation is eventually going to make this problem much better
for us.  But there probably will be some accidents along the way, so
that perhaps we ought to think a little bit about how to partition
the problem so that we have sort of smaller events rather than larger
ones.

>>ROD BECKSTROM:   Thank you very much.

It looks like we probably have three more questions.  We have five
minutes.  So panelists, let's try to do the quickest responses we can
that hits the essence of what is being asked.

Sir, we'll start with your question.

>>STEVE KIRKHAM:  Thank you.  My name is Steve Kirkham.  Dan, you
mentioned before hijacking attempts, or successful hijackings. 
Microsoft in New Zealand is one example.  And you mentioned the
registry/registrar model is helping where I can choose registrar A
instead of registrar B if registrar A is more secure.

What happens at the registry level, though?  We have seen a lot of
successful hijackings in a lot of ccTLD registries where it's the
actual registry that gets routed or holed rather than the registrar.

What can ICANN do to help the actual registries become more secure
and avoid these hijacking occurrences?

>>DAN KAMINSKY:   I have to be honest.  This is what I like about
the DNS CERT proposals.  I really like the idea of small ccTLDs
having resources available to them.  It's in all of our interests.

>>ROD BECKSTROM:   If no one else, we will go to remote.  Thank you,
sir.

Remote, Rob.

>>ROB HOGGARTH:   Thanks, Rod.

Carmelo Zaccone asks, DNSSEC RFC is there for more than five years
now.  Why has it taken so long to start official initiative of
deployment?

>>STEVE CROCKER:   It took a few years before Dan came along and
demonstrated to the political forces that it really was a serious
problem.

>>PAUL MOCKAPETRIS:   Yeah, I mean, DNSSEC has been going on now for
more than a decade.  I recommend a more evolutionary approach to the
IETF, but now we are getting into real philosophy.  And the other
thing I would speculate at is everybody talks about RFCs 1034 and
1035 as being the original DNS specs, but actually there was an 880
series and we fixed some things.  And seeing as we are in Belgium and
they like waffles here, this is the first waffle lot, and I think
that we're probably going to have to think about improving it and
adapting it as time goes on because I don't think this is the
universal security solution in DNS.

>>ROD BECKSTROM:   Thank you.  Sir.

>>FRANCISCO OBISPO:  I'm Francisco Obispo from ISC.

Since Dan mentioned it, he mentioned about a DNS CERT effort, we're
just wondering since it's not in the printed agenda, is there going
to be a meeting, a BOF meeting this week?  And if so, when and where?

>>ROD BECKSTROM:   Thank you.  I am going to ask Greg Rattray, who I
know has requested that a room be available to that independent birds
of a feather group.

Greg, do you have a time and a room?  Or does someone else have --
okay.

>>GREG RATTRAY:   That meeting, which was called for, birds-of-a-
feather session, will be 1800 Tuesday evening, tomorrow evening, in
rooms 313 and 315 on level 3 of this conference center.

>>ROD BECKSTROM:   All right.

Let's take one more question from remote.

>>ROB HOGGARTH:   Thanks, Rod.  I have a comment from Duncan Hart
who says, I am increasingly finding it hard to accept that the three
properties, those are the ones we discussed earlier, are deliverable
in one system.  Case in point, increased functionality does, in my
humble opinion, decrease levels of security.  Feature functionality
rich code has become increasingly difficult to gain trusted assurance
in.

>>DAN KAMINSKY:   There is a belief that functionality and security
have to be a zero sum game, and the reality is that they don't.  Whit
had this amazingly perfect example of if you are missing a feature to
allow user A to operate as user B, you will actually see security
decrease, because people have to share passwords to get their stuff
done.

It is very easy to say, oh, if there's more code, then there must be
less security.  But sometimes having a better way to do things means
you can do things the secure way and still get your job done.

>>ROD BECKSTROM:   Great!  Well, with that, I want to say an
enormous thank you to our panelists.

I also want to observe, you know, the power of getting such
tremendous different independent minds.

There's some pretty big out of the box solutions and suggestions
that came forward.

I think that's terrific, because it challenges us to question our
assumptions as we talked about this morning, and really think big and
outside the box about different directions we might go in.

I will also add we very much appreciate your feedback on this
session.  It's somewhat of a new model or new group.  We're bringing
so many truly deep experts together in some sense.

And whether this is of interest in the future on whether it's RPKI
or BGP, or if the DNS CERT concept stays alive, please just let us
know.

So if you can please join me in giving a hand to the panelists who
have come from around the world and blessed us with their presence.

[ Applause ]

>>ROD BECKSTROM:   Thank you very much.