*** Disclosure: The following is the output resulting from
transcribing an audio file into a word/text document. Although the
transcription is largely accurate, in some cases may be incomplete or
inaccurate due to inaudible passages and grammatical corrections. It
is posted as an aid to the original audio file, but should not be
treated as an authoritative record.***

DNSSEC for everybody.
A beginner's guide.
24 October 2011.
ICANN Meeting - Dakar


(No audio at beginning).

>> -- in the DNS.  It works something like this.  A resolver is the
ISP or the companies.  A resolver.

Okay.

Then -- sorry, your ISP or your company's resolver knows where the
root servers are.  It goes there, and it traverses (inaudible)  How
it, basically, works it will hand you the addresses of the com server
or the U.K. server.  And each level refers you down until you are
where you need to be.  And the resolver catches all that information
for future use.

Remember this slide from Simon's deck?  This is where Ugwina talks to
Og.  And Ugwina, in this case, is the resolver that checks with Og.
And Og is, basically, an authoritative server, may be responsible for
bank.com or for BBC.UK or NIC.SN.  In fact, Ugwina talks to many Ogs.

So now we're going to take a snapshot of the name space.  I just want
you to focus today on root com and bigbank.com.  And we're going to
show you how it works with a little bit of role play.

Thanks, Julie.  I was scared a bit.  So I'm going to quickly introduce
you to the players.  I'm going to quickly introduce to the players.

So on the far left is Joe User.  Then we have the root server.  Then
we have the com server.  And then we have the bigbank.com server.

And Joe right over here wants to go to www.bigbank.com.

>> Thank you.  I'm going to do my banking, so I'm sitting at my home
computer.  I'll type in www.bigbank.com.

 >>ROY ARENDS:  I am the ISP's resolver.  I don't have that
 information cached.  I do have the information for the root server,
 so I will go there first.

Root server, I want the address for www.bigbank.com.

>> Hi, Mr. ISP.  I haven't seen you for a while.  I'm afraid I can't
help you with www.bigbank.com, but I can tell you where dot come is.
It's at 1.1.1.1.

 >>ROY ARENDS:  Next up dot come at 1.1.1.1.  Hello, I want the
 address for www.bigbank.com.

>> Hello, ISP.  Good to see you again.  So I don't know the address
for www.bigbank.com.  But I do know that you can find it at 2.2.2.2.

>>ROY ARENDS:  Thank you.  So, allegedly, the address for
www.bigbank.com is available from bigbank.com.

Hello, bigbank.com.  I want the address for www.bigbank.com.

>> Hello, Mr. ISP.  I can happily give you www.bigbank.com since I am
bigbank.com.  Www.bigbank.com is at 2.2.2.3.

>>ROY ARENDS:  Thank you.  So I now know, as a resolver, where
www.bigbank.com is.  It's at 2.2.2.3.  I'm going to hand that over to
Joe User.  But not only that, but I'm going to cache that information
for future use.

>>Thank you, Mr. ISP.  Now I can go off do my banking in my browser
and pay all my bills.

>>ROY ARENDS:  Thanks, guys.  So what is the issue here?  This is
actually not a secure transaction what we do.  You saw that little
piece of paper that we handed back and forth?  In a DNS transaction
between Ugwina and Og, between the resolver and the server, there's
only a small bit more information.  But all that information can be
spoofed.

So in DNS there is no security, no real security.  Names are easily
spoofed.  And, when that happens, those spoofed names, those poisoned
names are easily cached.

So, when that happens, Ugwina is, basically, confused.  Remember that
slide again?  This is a slide from Simon's deck.  She doesn't know who
the real Og is.  It could be Kaminsky or the real Og.  So how does
that spoofing work in real life?  Guys, I need your help again.

So we do the same play here.  Joe User.

>> Okay.  Paying more bills, going to my bank again.  So sit down,
browser, and type in www.bigbank.com.

 >>ROY ARENDS:  Thank you.  I'm going to cut this a little bit short.
 So I'm first going to talk to the root server.  Root server, bigbank
 -- www.bigbank.com, please.

>> Okay.  I don't know where bigbank.com is, but I can give you dot
com.  It's at 1.1.1.1.

 >>ROY ARENDS:  Thank you.  1.1.1.1, I want the address for
 www.bigbank.com.

>> Thank you, ISP.  I don't know the exact address of www.bigbank.com,
but I do know you can find it at 2.2.2.2.

 >>ROY ARENDS:  Thank you.  2.2.2.2, I want the address for
 www.bigbank.com.  Thank you, bigbank.com.  The address for
 www.bigbank.com is 6.6.6.6.  And I know no better than that is the
 real address I want to go to.

Hello, Joe.  I have the address for www.bigbank.com.  And it's at
6.6.6.6.

>> Oh, thank you, Mr. ISP.  Now I can go on my computer and do all my
online banking.

 >>ROY ARENDS:  So how do we secure this properly?  We are going to
 introduce something called digital signatures.  And DNSSEC uses
 digital signatures to make sure that the answer is received from the
 right place and has not been tampered with in transit.  It uses
 digital signatures and digital keys.  And the good thing about DNS
 it's a lookup system.  You can store anything in the DNS.  You can
 store text records.  If you want to send e-mail, that mail transfer
 agent actually looks up in the DNS.  It's a simple lookup system.

And so you can store signatures as well in the DNS.  And the beauty of
this system is that you just use DNS to get the right information.

DNS keys are also stored in the DNS.  And there's actually a lot more
things; but it goes into really, really deep technical detail.  If
you're interested in that, come see me afterwards and I'll completely
bore you with all the details.

So remember the blue smoke.  That's the important lesson from the
first slide deck.  Remember the blue smoke.

So Ugwina, the resolver, is now trying to verify -- sorry -- is now
trying to talk to the real Og.  The real Og was actually able to
introduce something in his message, blue smoke.  Or, in this case, he
can show that he used the right key.  And everyone can check that key
because DNS is open and available.  Everyone can use that key to check
if the information is correct.  So that's not completely it.  There's
one thing more.  A resolver -- remember that a resolver knows where
the root servers are.  Now, in this case, it actually knows what the
root key is.  And, just like delegations -- right? -- that builds the
hierarchy, you can now have a chain of trust.  And that's through that
same hierarchy.  So, instead of delegations, you now have the chain of
trust.  In this case we're going to secure -- we're going to make that
chain of trust right now.

So the root over here at one point in time has learned the key from
the com zone.  And they shake hands over it.  And that, basically,
means that he now has a hint for what the proper key is in dot com.
Same thing over here.  Dot com is able to trust bigbank.com after some
initial handshake.  And now com has the information to get the key for
bigbank.com and to trust the bigbank.com DNSkey.

So, again, we now do the high-level concept of the DNSSEC.  We do that
with the same role play.  We start all over again.  Go ahead.

>> More banking.  Type in www.bigbank.com.

 >>ROY ARENDS:  Haven't you learned by now that the Internet is not
 secure?  And broke, okay.

So I know what the root server's addresses are.  0.0.0.0.  Please
don't use it at home.  That's not the real address.  This is just
play.

And I also have the key, the public key to trust the information that
he has signed.  So, root server, I want the address for
www.bigbank.com.

>> I'm afraid I don't have the address for bigbank.com, but I do know
where dot com is.  It's at 1.1.1.1, and I'm going to seal that with a
handshake.

 >>ROY ARENDS:  Thank you.  Because we did the handshake, I can now
 trust -- sorry -- I trust the root server.  I trust everything they
 sign right now.  And the information that I just got from the root
 server, I can now validate.  That's why we did the handshake.

Hello, com, I want the address for www.bigbank.com.

>> Hello, ISP.

Well, I don't have the address for bigbank.com, but I know that you
can find it -- for www.bigbank.com, but I know you can find it at
bigbank.com.  And I'm going to shake your hand to certify that.

>>ROY ARENDS:  Thank you.  I now have the proper address for
bigbank.com.  I can check it.  I can validate it.  Okay.  That means I
now go to bigbank.com.

Hello, bigbank.com.  I want the address for www.bigbank.com.  Thank
you.  And I'm now going to validate that information.

The handshake doesn't work, right?  I can't validate the information.
I'm going to try again.  Hello, bigbank.com.  I want the address for
www.bigbank.com.

>> Hello, www.bigbank.com is at 2.2.2.3, and it is signed and has blue
smoke.

 >>ROY ARENDS:  Perfect.  This is the chain of trust that I now
 validated throughout the delegated space, right?  And Joe User has no
 chance -- I'm sorry.

[Applause]

>> Joe User has a chance to go to the right space, and Dr. Evil has no
chance to interfere with that data.  Thank you.

Okay, guys, that's it.  Thanks.

So Russ is going to introduce you to some implementation stuff.
Deployment guide, basically.  Norm, go ahead.

>>RUSS MUNDY:  Well, I hope everybody enjoyed our little skit.  We
certainly enjoyed doing it for folks.

[Applause]

We truly want this to be interactive, and so far nobody has asked any
questions.  But this part of the session we do intend and hope that we
get questions, inputs, and people stop us, raise their hand, whatever.
We have another mic.  We'll get you out to the audience.  But we're
going to start off talking about -- let me get the clicker here.  Make
sure I get it the right way.  So I guess I'm -- I'll just go, since
that didn't seem to be a question for what we're doing here.  Okay.

So the focus that we are trying to get to here is a few more details,
not huge technical details, but some to show a little bit more of real
world examples of how you can go about doing DNSSEC for wherever you
might be in the realm of DNS.

And so there's generally a set of activities that are owners of DNS
zones and names.  And then there is users.  And these are the people
that can be literally anywhere in the world.  And so we'll have a
little bit of information about each of these, the idea being to give
a very broad coverage.

So those that are owners of DNS today, owners of names, have a set of
responsibilities that they have.  They have a set of organizations
that they -- (dropped audio)

Most people have registrars that they deal with.  There are a lot of
registrars here in the audience -- or at least here at the meeting.
And I hope we have them in the audience.  And registrars have a
important role in this as well in many spaces.

So there's also large enterprises, corporations that have worldwide
interests.  Some have local interests.  Some are just very small
activities that have names and Web sites and operate something on the
Internet.  And they're going to do very different things to actually
do DNSSEC, depending on what their role is in the world.

And there's a set of other classifications on there that I won't go
into specifically. If I can get the advance here.

Did I get it?  All right.  Here's a larger picture similar to what you
saw before, but it does give a little bit broader idea.  There's --
well, not quite 300 names in the top level root zone.  And a small
number of them are shown there.  And there are literally millions of
other names that come down in this tree.

We'll be talking today specifically about CNN.com and HP.com, just as
a couple known examples.  Most people are aware of those two entities.
And they're very common on the Internet.

So for each activity, wherever you may fit in this structure -- if
you're an activity that has an extremely heavy reliance on DNS for the
well-being and operation of your business or your function, then
chances are you will have a staff and a set of activities, whether
it's outsourced or in-house, that's quite knowledgeable in DNS.

And, in that case, there's a good chance that you will want to have
that set of activities do the things that need to be done to do
DNSSEC, whether you're running recursive name servers, authoritative
name servers or both.  If you're an activity whose DNS is important,
but it's not really key to your business and you have everything
outsourced and is operated by somebody else, then there's a very good
chance that you will have a choice of how you can do DNSSEC.  But your
most logical choice will be to go to your current DNS provider and
say, "I want you to do DNSSEC for me."

Now, this little picture is an illustration of the whole content
picture for DNS or the zone data picture.  The zone data or the DNS
content starts clear on the left side of this picture with the
registrants, someone getting a name assigned to them.  Therefore, they
become the owner of that particular name.

They deal with a registrar, in most instances, to get that name and to
maintain the ownership.  And a registrar deals with a registry.  That
is actually, normally, where the name servers are operated, although
they can be separate.  And that's clear at the point of the triangle.

But the actual content, DNS zone content is used clear over on the
right-hand side.  So you can see there's authoritative name servers
where you were seeing some of us up here playing authoritative name
servers earlier.  And Roy, as the recursive name server, was in
between.  And Norm, as the Joe User, was clear over on the other side.
You can see the content starts one place and goes way through lots and
lots of things to get to somewhere else.

Now, another way of looking at this is someone wants to put a www
record into DNS. And that starts in this picture clear over to the
left in the zone data.  It's added into the zone data.  It goes into
the authoritative name server.  And, when it's in the authoritative
name server, then recursive name servers and users can get it.  This
is another way of illustrating what we were showing earlier where
Norm, as the client rear on the right, goes through Roy as recursive
name server, goes through several authoritative name servers, and gets
the answer returned.

Another larger picture of what you'd have to do to get www.CNN.com,
the root name server constellation is shown at the top.  There are 13
different ones.  You can go to any one of those.  The dot com name
servers -- there's 13 at least IP addresses at both the root and com.
There are many more actual machines.  And then the CNN.com has four
separate IP addresses.  And then the recursive resolver actually gets
that to the person that wants the information.

So you look at a web page and say, "Gee, there's not a lot of DNSs
there.  The URL bar at the top, there's one or two lookups."

This is a picture of how many lookups there are about five years ago
on CNN.com.  And it keeps getting more and more.  This is how many
there are about three months ago on CNN.com.

Well, over 100 queries and responses to get CNN.com web page filled on
your browser when you go there.

What is all of this?

Well, there's advertisements; there's pictures; there's multiple
places that the CNN.com web page uses.  It's a little hard to see
here.  The green -- there are a few green lines on the right-hand
side.  Those are actually DNSSEC validated sites.  There's a very
small number that you actually do go through when you're filling your
web browser with CNN.com.  But not that many.  So it's the DNS zone
data that really matters.  DNSSEC gives you the ability as a user to
make sure you get the right zone data.  But you also have to make sure
that the proper DNS zone data gets put in and managed properly in the
first place.  So it's the DNS zone content that really matters.

Now, when you start to look at how you're going to go about doing
DNSSEC, some people and some organizations get very carried away
because there's crypto involved in DNSSEC. And they have to do extreme
things with the security of the crypto.  And they don't think enough
about whether or not their content has as good of security as their --
the slide numbers?  Ah, okay.

Thank you.  I didn't realize it wasn't up there.  So I guess for the
remote presentation we don't have the slides.  So I'll cover a little
bit more of the content.

So, when you're assigning your zone as the owner of zone and applying
DNSSEC information, you want to also make sure that you put as much
effort into the security to make sure that your content that you're
putting into the zone has as much security as the cryptographic
mechanisms that you're using to sign it.  Because, if someone wants to
attack your zone and attack applications that are using your zone, if
you spend way more resources on the DNSSEC crypto mechanisms and not
much resources on the DNS zone content protection, they're going to
just attack your content.  And then you, as the owner of the zone,
will be signing incorrect and invalid data, which some people would
argue is worse than not signing a zone and having bad data published.

So, if you remember the picture that I had up a little bit ago, the
left-hand side is sometimes called the provisioning side.  That's the
side where you go to as an acquirer of a name, go to a registrar, get
approval.  And, whether it's exchanging money or your authorization,
whatever has to happen to get the authority to use a name, then on the
left-hand side of the triangle, the registrar then passes that to the
registry.  And in the registry area, and from the registry, which is
the point of the triangle, until the user application on the far
right, that is the area where DNSSEC is actually applied.  So, as you
can see, if you think of it as a mountain or a triangle, DNSSEC
protects you and protects your information on the right-hand side.
The left-hand side is no more or less secure than it was before after
you have signed it.  And, if someone is going to attack your content
provisioning part, DNSSEC does not prevent that.  It doesn't help it.
Doesn't hurt it.  It makes it no different.

Where DNSSEC really gives you the protection is as the data is going
back and forth and passing all around the Internet.  And, if you'll
recall, there are many hundreds of places that it goes through.  And a
pretty typical flow of a query and a response will go from anywhere to
10 to maybe as much as 30 or 40 different nodes.  And all along the
way on the Internet flow of things is where attacks can occur.

With DNSSEC in place, those attacks are thwarted.

Again, back to the earlier picture, the picture where you're putting
your World Wide Web additional content, the record to tell people in
the world where your World Wide Web server is into your authoritative
name server, now with DNSSEC, when that information goes into your
authoritative name server, it will be signed information.  And we'll
have the blue smoke attached that can be used by the validating
recursive resolver or at some point even an end user, if validation
occurs there.

And so the part of the Internet where literally hundreds of packets
flow around for a given single query to fill CNN.com, you're
protected.

Now, some more specifics about where and how people should look at
applying DNSSEC.  And, as I said earlier, the general principle is,
whatever you're doing for your DNS operation today, you should
probably do in the similar or a same manner for DNSSEC.

So, if you're running your own DNS operation -- you have your own
operation staff; you have your own computing systems; you have your
own internal operation and, essentially, you're running your own ISP,
then you're probably going to have that same staff apply DNSSEC
capabilities into your existing infrastructure.

If you're going to do that, if you're using a given defined product
suite, then you will likely want to use the product suite's DNSSEC
implementation.  And now, when you go to the product suite vendor and
they say, "Oh, I'm sorry.  We don't do DNSSEC," that's when it becomes
your part to say, "You need to do DNSSEC, because I want it and I want
it as soon as I can get it."  And you might even think about changing
vendors to get it.  And be sure to tell your vendor that.  That gets
them motivated pretty well.

Now, if you're using open source tools in your internal operation,
there's a number of choices you have.  There are some appliance type
operations -- available that are open source.  There are appliances
that are products that can be easily added, integrated with an open
source operation. There are also signing services that you can use in
conjunction with your open source operation.  They are very easily
integrated into your operation.  Certainly, I'm not going to go into a
lot more detail there.  It's available.  If anybody has any questions,
say so.  We'll talk about it now. Or we can cover it afterwards, if
you like.

If you're using an outsource kind of operation, then you'll want to go
to that outsource provider and say, again, "I am using you today for
DNS.  I want to use you for DNSSEC."

And, hopefully, their answer will come back, "Oh, certainly.  You just
look at this particular box on the Web site where you interface to me
and click it off, and you will have DNSSEC."

If that's not the answer, if the answer is something like, "Oh, I
don't offer that.  That's nothing that anybody would really want to
do" or something of that nature, you say, "Well, I'm sorry.  That's
when I need to start looking for somebody else to provide my DNS
service that can provide DNSSEC for me."

And truly, this is a very, very important aspect.  Because this is the
kind of motivation that, whether it's outsource providers, whether
it's product providers, any other entity that is providing a service
related to DNS, if they hear from their customers that they have
customers wanting DNS security, DNSSEC, they will be more likely to do
it.  And, when they start losing customers if they don't, then they'll
definitely get motivated to do it.

Now, there are a range of specific products that I've not tried to
cover any here.  And we do conduct an informal survey that's available
on the DNSSEC-deployment.org Web site that will give a breakout of a
large number of these.  And we can provide more specifics there.  But
it seemed that I didn't want to really cover any individual ones here.

And I wanted to just go through these alternatives and give people the
opportunity to see whether -- where they fit into things.

Now, personally, I have a soft spot in my heart for all the open
source things because, frankly, that's what we do a lot of.  And we
have many things available that are free and openly available in the
space.  And there are a number of other products that are also open
source.

But many people do use commercial products, and the availability from
commercial product vendors is not as much as we would like to see.
And, truly, what we really need is to have people who are customers of
products asking their product vendors to provide DNSSEC.

So now I want to see if there are particular questions that folks
might have relative to anything that they have seen today.  We have
got another mic, so we can pass it around.  And back in the back,
Julie, there is somebody back this.

And it can be anybody that you have heard from.  We'll take any
questions that you have.

>> I have a simple question.  In the drama that you showed, the bogus
data was trying to mimic the valid IP.  What would happen if the bogus
IP latched onto it.  Is that possible?

Latched on to trusted, signed data.

>>RUSS MUNDY:   Okay.  I'm not sure that I got the question.  Could
the wrong ISP?  Was that the question?

>> Basically, Russ, I think the question is can somebody inject bogus
data at an earlier phase so that it's returned with a trusted
signature?

>> Yes, exactly.

>>RUSS MUNDY:   Okay; good.

We must have more questions than that.

We do.

Now, I thought Jay gave -- I'm sorry.

>> (Off microphone).

>>RUSS MUNDY:   I am having a hard time hearing in this room.

>> It is possible, yes, for the data, through a breach of the
registrant or through the registrar, which has happened in a number of
occasions so that somebody has taken control of somebody else's Web
site through breaking into the registrar they use and then sending the
bad data that way.  And theoretically it is also possible to break
into a registry and insert the data in the registries systems so that
by the time it makes it into the DNS system, it has the associated
signature with it.

So it's a known vulnerability.

>> (Off microphone).

>> It has happened, and it has happened a number of times in the last
two years with registrars being compromised and Web sites being
redirected for high-profile targets as a result of that.

So the threat to DNS that DNSSEC is protecting is far more widespread
and far more exploited than the threat of people breaking into
registries.

>>RUSS MUNDY:   Thank you, Jay.  Because I lost it in the overhead
sound.  Sorry.

Go back to the triangle picture in the slides.  I think that's the
easiest place to point to.  Right there.

The registrant/registrar area that over here on the left-hand side of
this picture is the area that I think you were asking about, that
information really just affects the -- if it's a registrar attack, it
affects only the zones handled by that particular registrar and
doesn't go all over the Internet.

The side that DNSSEC is protecting, once it gets on the Internet, this
is extremely broad.  It goes anywhere and everywhere and could be any
zones on the Internet.

So the protection is required on both sides but the damage that can
occur is broader and wider on the side that DNSSEC is protecting.

More questions.

Back here.

>> Thank you.

The way I understood it is that DNSSEC is basically an authentication
function that's being integrated into DNS.  What is the advantage of
doing it this way rather than implementing this function at the level
of the Web service?

>>RUSS MUNDY:   Okay.  The difference is that DNS is used by literally
hundreds probably thousands of applications throughout the Internet.
If you were attempting to solve the same problem universally and as
broadly as DNS can solve it, you would have to solve it for those
hundreds to thousands, maybe even hundreds of thousands of different
applications.  And each solution would probably be different, where
solving this and ensuring that people go to the right name is usable
by any and every application that runs on the Internet.

Now, they can do additional security mechanisms on top of it that are
useful for their particular application functionality, but they can
focus on that application functionality for their security and not
have to worry about whether or not the name that they get is correct.
Is that --

>> Yeah, the thing I was thinking about was that this will probably
take a while before DNSSEC is being rolled out on a very large scale.

So maybe there is some sort of intermediate phase where you still have
to rely on the security from the Web sites.

>>RUSS MUNDY:   Well, a Web site is one example.  And that's probably
the largest, most broad spread set of examples.  But there has also
been a growth in DNS security that has been very effective the last
few years.

There are now over half of the domain names that are registered can
operate with DNSSEC; okay?  With the signing of the large TLDs as we
have.

And so I don't know the exact numbers.  I know it's well over half,
though, with com and net, DE, UK, and the other large top-level
domains.

So it's going -- it's being rolled out quicker than a lot of people
thought.

Is there one over this?  Yes, Roy.

>>ROY ARENDS:   Not a question but an addition to what Russ has said.
Before you can actually do the Web stuff, you need to get there first,
and you use DNS for that.  So DNS is the only place you can really
secure that.

So to make sure the information is correct, you go to the proper
place, you need to have DNSSEC.

>> (Off microphone).

>>ROY ARENDS:   Hold on, hold on.

I thought it was simple.

>> So if I am doing online banking today, then I am -- and even the
banking site is secure, then I'm still not sure if it can be a bogus
site.

>>ROY ARENDS:   If you do banking today without DNSSEC, you might have
a certificate, DigiNotar, you might have a certificate that could be
secure, could not be secure.  Users are mostly presented with the
certificates that they then have to trust.  People are building now
whole applications -- for instance, things like as DANE, or DNSSEC
stable certificates, so you can put certificates in the DNS so you
have the proper certificates before you actually do the banking,
before you go to that Web site.

>>RUSS MUNDY:   One other -- I think that gentleman is next, but one
other thing.  There have also been a couple of high visibility CA
compromises.  There's also a number of other questionable CAs that get
distributed -- the root certificates get distributed in Web browsers
that a user wouldn't even get a warning for even if they are, in fact,
compromised.

So it is a different situation, but it's also recently one that's been
showed to be attacked with great rigor and some success.

>> Are there any additional fees to have DNSSEC work with my
registered domain name?  If I go to a registrar and I register a new
domain name and I want to use DNSSEC, is there an additional fee to do
that or is it included as part of the service, typically?

>>RUSS MUNDY:   The costing of DNSSEC is completely up to those that
are issuing the names.  Okay?  So it varies by where you are in the
world and what the organization is that you are dealing with.

>>JULIE HEDLUND:   We have some over here, too.

>> Can you comment on what the expected market adoption is likely to
be from a time perspective?  And then within that, are there any
segments such as e-commerce companies that might be earlier adopters
than others?  I'm curious as to what you see in the marketplace.

>>RUSS MUNDY:   A very important question, the adoption rate.

It's also been very hard to answer.

We have looked at this several times over time.  We have had some
market segments that, especially the financial, we thought would be
early adopters.  They have not been.  There is some movement in
various countries in particular to start to use DNSSEC within the
financial industry.

The area that we have really seen the broadest pick up and adoption
has been on the authoritative and top-level domain side to make sure
that the service gets out there, gets available, so that it is broadly
available.  And right now, the most visible example that I'm aware of
of a large company that is into the financial world that is publicly
committed to doing DNSSEC is PayPal, and they have also said in some
public statements that they intend to require PayPal partners to also
do all DNSSEC.

>>JULIE HEDLUND:   And, Russ, we are really getting some good
questions here and so we are going to need to start managing a queue.

So I have seen we have got one, two, we have got three.  We have this
gentleman over here, we have this gentleman here.

So I am going to start to this side and move to this side, and we will
--

>>RUSS MUNDY:   You are in charge of the queue, Julie.

>> Thank you.

I came in late so I don't know if this question was already talked
about.

I'm more worried about the security.  So you can have a good name, a
religious name or anything like that.  Sometimes you type that,
somebody can have it as a dot com, somebody else as a dot FR or dot
org or something like that.

Now you type that name and you get redirected to an adult site.  You
following me so far?

>>RUSS MUNDY:   No.

>> Okay.  So I'm asking you about the effectiveness of the DNSSEC here
when it comes to security.

>>ROY ARENDS:   So I think I understand the question.  Let me repeat
that for you, if that's okay with you.

So the question is really how does it protect against, for instance,
things like typos or redirection.

>> Exactly.

>>ROY ARENDS:   And the answer, it doesn't.  If you type in the wrong
name, you go to that wrong name.  Actually, DNSSEC makes sure you go
to that wrong name.  In DNSSEC terms, us geeks, we sometimes say, you
know, bank robbers, they wear seat belts as well, where bank robbers
are basically those who try to steal traffic away from the right
person and try to rob you from your money; right?  And the seat belts
is basically the DNSSEC.

So it doesn't help on the provisioning side at all.  It doesn't help,
it doesn't do anything for you in terms of redirection.

Part of the question could also be how does DNSSEC help against, for
instance, influence of governments or things like COICA or mandated
DNS redirection.

DNSSEC only helps so little.  It can only detect that data has been
tampered with.

From a DNSSEC perspective, if an ISP decides to reroute data or just
send you to an alternative address, to DNSSEC that means the data has
been tampered with and it will tell you that.  It doesn't mean you
will get, then, to the correct data.  It probably means you don't get
this at all.

Thank you.

>> Sometimes even with the seat belt, you can die.

>>ROY ARENDS:   Yes.

>> Okay.

>> I am a student and I want to use the ICANN as a reference.  So my
question is to ask you if you deliver certificate at the end of the
seminar.  Thanks.

>>RUSS MUNDY:   Okay.  I'm going to, I think, turn this over to Roy.
I am just having too hard of a time hearing.

>>ROY ARENDS:   Okay.  What we can do, we have some -- I think you are
asking for reference information where we can find information about
how to deploy DNSSEC; is that correct?

>> She is actually asking if you guys deliver certificates for her.
She is a student.  She wants to use it as a reference, and if you guys
could actually put her with a mentor or something like that.

>>ROY ARENDS:   Okay.  Sure.  We can do that.  Come see me afterwards.
Thank you.

>>JULIE HEDLUND:   Excuse me, but we do have a queue, and I have noted
this gentleman here but we have this gentleman and the one over this.
And then that gentleman.

>> Excuse me.  I speak French but I don't understand English very
much.

(Speaking in French)

(Scribes have no translation)

>>ROY ARENDS:   I am going to answer you in English.  I'm sorry.

The first question, for those who haven't heard the translation, I am
going to shorten your question into two or three key sentences.

Your first question, Joe User does a bank transaction.  Joe User sees
a certificate being presented to him from a bank.  DNSSEC gives him
additional assurance.  How does the experience for Joe User work?
What information does Joe User have to assert that DNSSEC has been
done, basically?

I am waiting till the translation is done.  Is that correct?

>> (Speaking in French)

(Scribes have no English translation)

>>ROY ARENDS:   Okay.  What's the difference between SSL, on one hand,
and DNSSEC on the other hand.

I read that question as, for instance, a bank can currently issue --
authenticate the data stream.  Joe User can see the lock.  Everything
is secured by SSL.

What does DNSSEC do?  DNSSEC makes sure that -- let me turn that
around.

Before you actually get the certificate from that bank, you have to
know where that bank is.  So that's one.

Now, you might have gone to the -- You have might have gone to the
right bank.  You might have gone to the wrong place.  And what you see
a lot is that people are presented with a certificate, and something
is wrong there, and you can click on yes, no, maybe.

What these people -- and it includes everyone, including my mom,
including myself.

What you want to do, because you want to did your banking, you just
want to get past that obstacle.  So you are just going to click on the
certificate and accept it and take a leap of faith.

Now, of course, that's not smart, but we know from studies that
certificates alone is not secure enough.  We also know, for instance,
events like DigiNotar or COMODO, they have been hacked.  Now, of
course that can happen in DNSSEC as well, but it is the assurance you
go to the right place.

So before I actually do the banking, I can have some assurance that I
went to the right place.

Currently DNS validation happens mostly at the validator -- sorry at
the ISP level.

What we would really like to have eventually is that validation
happens in the application or on the operating system, so that the end
user can see both that the transaction is SSL secured and they ended
up in the right place.

Now, for your second question, your second question, in order to,
let's say, play with DNSSEC and in order to test it, is it possible to
have a separate independent environment, basically a lab system or
compartmentalized system.  I can answer that in two ways.  You can do
that, but you need to remember that just like -- you basically need to
mimic everything.  You need to compartmentalize everything.  Just like
you can have root servers, the proper root servers that are currently
run by ICANN, IANA, and VeriSign, you can have your own root servers,
basically a small set of servers.  So that way you mimic the entire
namespace and you can play there on your own test with DNSSEC.  That's
one answer.

If you want to use the regular namespace, the namespace we are all
using -- for instance, in Senegal, dot SM -- what you can do is
instead of configuring in your resolver the root DNSkey, you can
configure the, let's say, playground.academic.something.SM, if you
will.

So it depends on how you configure it but it is definitely possible,
and if you would like to have some examples, we can chat afterwards.
We need a translator.  I don't understand French.  But I will help you
with some examples.

Thank you.

>>RUSS MUNDY:   While we are going to the next person, let me just
comment that this was a study done at the Massachusetts Institute of
Technology about three or four years ago where there were 100 students
from MIT that were told that their transaction with their bank, their
interaction with their bank was going to be mucked with in some
manner, and they weren't told how.  And of those 100 students, 93 of
them accepted something and said okay to something they should have
never said okay to, and, therefore, would have compromised their
banking activity.

So it's not to say that having security in an application is not
necessary or is bad in any way.  It's just that people have become so
used to just accepting these things that don't look right to them that
the strength, the protection is not as much as it used to be or was
originally.

>>SIMON McCALLA:   We have a question from the chat room, if that's
okay.  Jay has posted a question.  He says:  My question would be to
know if the kind of warranty that DNSSEC offers to me is in any way
more secure or equivalent to a pin generator and a VPN connection that
my bank provides me with?

>>RUSS MUNDY:   I would say it's very much orthogonal to what a bank
would offer, because there is no standard universal strength or rigor
associated with that.  It could be extraordinarily strong.  It could
be very weak.  And you just don't have a way, nor do I, of assessing
the strength or weakness.

The DNSSEC mechanisms are all defined by public specifications.
Therefore, you can at least judge how strong you believe the result of
that is.

>>SIMON McCALLA:   I think the key to this one is to remember, and I
think something that Roy mentioned is that DNS is the pathway to get
to your bank in the first place.  And the key thing about DNS is this
a security standard built into the very fabric of the Internet rather
than additional tools and technologies that are applied on top.

That is why we believe DNSSEC is so important and can sit alongside
additional mechanisms provided by your bank.  So it's an additional
layer of security, too.

>>RUSS MUNDY:   Yes.

>>AKSHAT:  Hi, this is Akshat.

I just wanted to ask, before your schedule mentioned a term called
cache poisoning.  Does DNSSEC cater to that in any way?

>>RUSS MUNDY:   Cache poisoning was actually the original biggest
threat that DNSSEC was created to counter.

At the time that DNSSEC engineering first got under way, it was
extraordinarily easy to do cache poisoning, much easier even than it
is today, and that was the original biggest threat that it was put out
there to prevent.  And it's one of the reasons why, in the engineering
of DNSSEC, the security is part as an integral part of the data of the
DNS zone itself, as opposed to having something along the paths or
trying to secure every individual name server.  That was the biggest
reason for that choice to be made, to put it with the DNS data itself.
So no matter where it went, if there was something that went wrong in
a cache, the eventual user of it could detect that.

>> Okay.  Thank you.

>> Domain name security seems like a wonderful idea, and it seems to
be very old, at least 5,000 B.C.  So why have we only been looking at
it for the last three years?  What suddenly was the kick up the rear
end?

>>RUSS MUNDY:   You want to take that, Roy?  Okay.

>>ROY ARENDS:   As Russ said before, cache poisoning is almost as old
as the Internet, is almost as old as the DNSSEC.  What happened in the
last three years is cache poisoning got incredibly easy.  Really
incredibly.

I remember an IETF -- For those of you who do not know what IETF
meetings are, that's basically environment where standards are created
that everyone can use on the Internet, and we had a meeting in Ireland
in 2007 -- sorry, in 2008 or early 2009, where we were discussing if
DNSSEC would be the answer to the Kaminsky attack, to the cache
poisoning attack.  And people did not grasp that cache poisoning was
so simple.  And a former colleague of mine, he went on stage and he
gave a small demo that in less than a second, he was able to spoof
information to poison the cache.  It was a very simple trick that he
did.  It was very, very fast.  And still people didn't believe him,
and he did it again and again and again.

So this was 2008.  And folks are still not convinced that cache
poisoning is that simple.  But at that time, during the IETF, it was
basically the equivalent of shooting a gun in a room where people were
talking about gun control.  It was very, very impressive.

So.

So the 2008 Kaminsky attack really made this thing go forward.  But
DNSSEC has been around since I think 1995.

The first -- When people first understood that there was something
wrong, it was, I think, Steven Bellovin came up with a method to
poison the cache, and folks started thinking about how to make that
more secure.

So that's basically the history of DNSSEC, the real history of DNSSEC.
Does that answer your question?  Okay.  Thanks for asking.

>> Thank you.  Hello?  Yeah.

My question is this.  Based on the demonstration, you have four
actors.  In the initial scenario -- is it five?  The ISP inclusive
with the root, and the second-level domain and the third-level domain;
right?  The actual owners.  That's the registrant.

Are they all supposed to be signed?  If the root is signed, we are
talking about -- I am from a ccTLD.  The ccTLD is signed.  Do all the
registrants, the end users, need to sign their domains as well?  Or is
the signing of the registry solve -- takes care of that?  That's the
first question.

The second question is this:  How does an ISP uses DNSSEC?  Because we
are talking about the ISP DNS server; right?  That you use to browse
the Internet.

The third question is how as an end user, how do I validate whether
the ISP is using DNSSEC or not?

>>RUSS MUNDY:   Okay.  So the first question, do you need to have all
the domains in the hierarchy signed for DNSSEC to be effective.  For
the owner and operator of each zone in question, they need to have
their zone signed.  And so if, in the case of our little skit here, if
bigbank.com was not signed, and the user really wanted to get to the
host in bigbank.com, he could not get DNSSEC validation only by having
the root and com signed.  All of the levels have to be signed.

Now, realistically in the DNS world today, there's a small amount of
interactions with, if you will, the general public and TLDs, but most
of the interactions are in the level below the TLDs.

So, yes, you do need to get to that third level of having DNSSEC
signed zones for users to be able to conduct -- use DNSSEC
effectively.

Now, you will know getting so far but you won't know clear to the end
host.

So that's the first question.

The second question in terms of how does an ISP use it or provide it,
the ISP in our skit was Roy; okay.  Roy was acting as the recursive
name server for an ISP.

Now, there's -- really, you can think of DNSSEC and DNS as having two
basic parts.  One basic part is the building of the DNS zone content
information itself, the zone data.  That's the creation process or, on
that slide, it's the left side, the provisioning side.

As part of that, and right at the peak of that triangle, is where
DNSSEC is normally applied.

So that has to be put into the system.  Once that's put into the
system, anyone operating a recursive name server that has the root key
can validate down the chain.

So that's how an ISP would actually use it.  They would operate a
DNSSEC validating recursive resolver.

So was that --

>> That question was the end user.  How do I know whether my ISP is
using that or not?

>>RUSS MUNDY:   How would an end user know?  Today, you would have to
ask.  There are a small number of applications available that do do
DNSSEC on the end system.  I have got some of them on my machine that
we build and distribute.  But the vast majority of the Internet for a
long time will probably be using recursive resolvers provided by their
ISPs.

Now, one of the things that we have been working with through some of
our projects is with Mozilla and other Web browsers, open-source Web
browsers, to contribute code that does DNSSEC validation and get it
distributed through these large major open source browsers.

So when that occurs and it becomes readily available and widely
available, it will be a much easier process for an end user to
actually do DNSSEC on their end machine.

>> Thank you very much for the explanation.

The last question, please.  I am a paranoid end user.  I really want
to secure my domain, but my ccTLD is not signed.  Is it possible to
sign my domain?

>>RUSS MUNDY:   You certainly can sign your domain.  Now, if you are
Roy's example a little earlier to the gentleman that was asking can
you set up a separate secure subdomain, you can if you have some
reasonably small number of people that you are dealing with that you
want to make sure that they know that it's coming from your domain.
You can provide out-of-band secured handing of your public DNSSEC key
to those activities.  But it will only work for those activities that
you have handed your key to, and whenever you change it, you also have
to make sure that those activities have the changed material.  So you
can do it.

>>ROY ARENDS:   My answer is a little bit shorter.  You can use a
thing called DLV.  If your top-level domain is not signed, there is a
trick you can use in DNSSEC currently, is use the concept of DLV.  It
basically means that you side step your top-level domain.

So let's talk about it afterwards.  I can help you with the content.

>>JULIE HEDLUND:   I think it was over here.  Was there someone over
on this side, hand up?

I've got it.

>> Hi.  Thank you for your presentation.

I would like to know for the DLV, are they able to play the same role
of root signed zone?

>>RUSS MUNDY:   Another quick DLV question; right?  Is it able to play
the same role?  Is that your --

>> Because as I understand DLV, we use it when the root zone or the
top-level domain zone is not signed.

So I would like to know, is it able to replace the root zone signed?

>>RUSS MUNDY:   Well, the root zone is signed, many of the TLDs are
signed.  But if you happen to be in a TLD that's not signed, then you
can use the DLV, DNSSEC lookup site validation to, as Roy said, step
around the lack of signing in the zone right above your zone.

So the DLV has been running for about five years.  Is that right,
Norm?  I think.  Yeah, about five years.  So it's an established
activity out there and will continue length of time until there is a
lower-down hierarchy number of zones that get signed.

So it's not exactly the same as having a fully signed path, but as
long as the users of your zone data are willing to do validation with
the DLV, you functionally get the equivalent of a signed tree.

>> I have another question.  It's about the keys.

How -- With the trust anchor, the keys for signing the zone are
managed by DNSSEC.  The keys allowing to sign the zone are managed by
DNSSEC.

>>RUSS MUNDY:   Well, the actual policies and mechanisms for handling
of the keys are determined by each zone owner operator, just as any of
the DNS information for a particular zone is managed by the zone owner
operator.

Some zones, especially -- well, the root has certainly done this.  Dot
com has done it, dot SE, I believe dot UK has published policies.  So
there are sometimes publicly published information about how the keys
are managed for a particular zone.  But that really is up to each
owner of the zone whether or not they choose to create the documents
and, even if they create them, they may or may not make them public.
It's really a zone owner choice.

>> Thank you.

>>JULIE HEDLUND:   So we have a little less than ten minutes left and
we have got a couple more questions.  So we are needing to wrap it up.

Did you have one in the chat?  No?

Okay.  I saw two other questions.  This gentleman and that one.  So we
will take those two and I think we will probably have to start
wrapping up.

Hang on.

>> Okay.

(Speaking in French)

(Scribes receiving no English translation)

 >>ROY ARENDS:  I had the first part of the question.  The second part
 of the question, if you can please repeat that for the translator.
 Thank you.

(Speaking in French)

(Scribes receiving no English translation)

 >>ROY ARENDS:  Okay.  I think I understand the question.  Let me just
 repeat that and see if it's correct.  DNSSEC is based on
 authentication of DNS data.  Since -- (Speaking in French)

 >>ROY ARENDS:  Sorry.  Please let me finish.  Thank you.  And,
 because you introduced that, you inherently make DNS slower.  Now my
 response to that is, sure, you do more work at the validated part.
 And, yes, it's a little bit slower.  But that amount of slower is
 negligible.  Because, remember, after it validates, you can cache the
 data.  And, if you measure the DNS, what you normally measure as well
 is the amount of the speediness, basically, how fast you can look up
 something in the cache.  That doesn't need to be validated because it
 has been validated before.  So that's one.  The second part is
 validators at an ISP level, if it's a large constellation of systems
 and they have to do a lot of work, you have something similar as, for
 instance, as the self-terminators.  That's, basically, a piece of
 hardware that can accelerate the validation of the DNSSEC.

But, in any case, it is not that slower.  The amount -- I think
people, in general, talk more about the increase in traffic and the
size of the packets than that they talk about slower resolving.
Because I think, really, the amount of -- the amount of delay that it
introduces is negligible.

I hope I answered the question correctly.  I hope I understood the
question correctly.

 >>JULIE HEDLUND:  Last question, and then we do have to wrap up.

(Speaking in French).

(Scribes not receiving English translation)

 >>ROY ARENDS:  Okay.  I will try to answer this short.  There are
 multiple things in your question.  Question one, related to your
 first question is:  In terms of statistics, how much is the overhead?
 How much is the overhead DNSSEC introduces?  It's negligible.  There
 is overhead, but I think it is negligible.  What I can recommend is
 on Wednesday morning we have the DNSSEC section, a DNS working group.
 Everyone here is invited and tell your friends as well.  We're going
 to have a TLD update.  It's a panel session somewhere in the middle
 of the whole day.  During the panel session I have a few slides which
 will show you some statistics about the overhead and about the
 increase in traffic and about the uptake of DNSSEC in the U.K.  And I
 don't have that right in my head.  I did prepare for that
 presentation.  But I recommend you come on Wednesday, and I can show
 you the data.  Yeah, thank you.

I think that wraps it up.

 >>JULIE HEDLUND:  Yep.  Thank you, everyone.  And thank you very
 much, Roy, for mentioning the DNSSEC workshop.  That is -- it starts
 at 8:30 on Wednesday in this room.  So you just have to come back
 here on Wednesday morning and get a lot more information on DNSSEC.

 >>SIMON McCALLA:  First, can I thank our fantastic translation staff
 over here who have done a brilliant job translating a really
 difficult subject.

[Applause]

For those who have been following.

And please can I thank again the panel here for all the hard work and
all the preparation.

Can I say also the questions that you have asked today have been the
best questions we have ever had in this session in all the times we've
done it.  So please come on Wednesday.  We're in this room running all
day, so please do come and take part again.  So thank you very much,
everybody.

[Applause]