ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>STEVE CROCKER: I apologize for the delay.
There's supposed to be brochures that haven't arrived yet.
Maybe they'll arrive during the session and we'll hand them out.
For the scribes, the agenda is on the screen.
Let me know if that's big enough.
There we go.
So this is a fairly straightforward agenda.
Are we all set?
Are you guys okay back there, the scribes?
Good.
Thank you very much.
Okay.
Thank you for coming at this early hour.
We set for ourselves a fairly grueling schedule for these ICANN meetings.
And then we go off and have very intensive discussions about how to fix it.
And then we -- the fix seems to be to make it more grueling the next time.
So I think we need to stop talking about it maybe is the only thing to do about it.
I'm Steve Crocker.
I chair ICANN's Security and Stability Advisory Committee.
And as a project that grew out of the work of the committee and much other work around the world, there is now a DNSsec deployment initiative.
And I'm heavily involved in that, cochairing some of the U.S. activity.
Let's see.
What I want to do here is fire up the correct -- we're having a little technical difficulty.
And -- I apologize for this.
This is -- we had a little crash just a few minutes before we started up here.
>>VINT CERF: Steve, are you sure that you weren't hijacked or attacked somehow?
Is that the reason for the crash?
>>STEVE CROCKER: You know, anything is possible.
But I think we're okay.
I'm going to go on the offensive here in a minute instead of the defensive.
Okay.
I think I've found my first slide.
So as I said, I co-chair some of the U.S. activities in DNSsec deployment.
We have been running DNSsec workshops at ICANN meetings for approximately the past year or so.
And we try to cover a mixture of basic information about what DNS security is all about and also give a different focus for each of the meetings related to what's happening during the deployment process or what's happening regionally.
Today, we have -- I'm going to give a short talk, including a demonstration, which I hope will be attention-getting and help you understand why we're doing this.
Ram Mohan, CTO of Afilias, will give a basic description of DNS and DNS security and provide a good basis for understanding the protocol and the -- what it's -- what the protection is that we're providing and how things fit in.
Maria Zitkova, from SITA, who's head of .AERO, will give a view from her registry as to how DNSsec fits in.
And then we will have a panel discussion with Alain Aina from Togo, Mouhamet Diop from Senegal, and Ram and Maria and I sitting in, partially filling in a little bit around the edges from what's been said.
And then, most importantly, and I hope you're stimulated, to respond to questions from you on any of the dimensions, any aspects of what we've been talking about.
So with that, let me move directly ahead.
Here's the list of people, as I had said.
Here's the good stuff.
We have a little demonstration for you.
And, in fairness, so that we're not disturbing people who are actually trying to get useful work done or don't want to be hijacked, you have to opt in.
You have to select to this.
And what you do, if you want to see how this works, is you reconnect, instead of to the ICANN Marrakech Wi-Fi net, connect to "badnet."
Let me see if I can show what you that looks like.
Well, let's see.
There's a -- it's being hidden from me.
Where's my -- I wanted to show you the -- well, are people able to find badnet?
Yeah?
So if you're able to find badnet, then you have presumably seen a page that looks approximately like this.
We have a little sizing problem here.
And what's going on is that you're making DNS queries as a normal part of accessing almost anything on the net.
And so if you have a browser fired up and you're trying to go to some page -- and it doesn't really matter what it is, because I'm intercepting everything going to badnet -- whatever query you make is being intercepted and replaced with -- well, that's actually not quite right.
I'm competing in realtime.
I'm intercepting the query;
It's going out to a real DNS server, but this little machine here, innocent as it looks, is also computing a DNS reply to the action here, and I am able to get the answer back to you before the real one comes, and I give you the address of an alternate machine.
And, in fact, my laptop is serving that purpose.
And then computing a Web page special just for you, which is the one that you're seeing.
How many people are experiencing this demo now?
Let me see.
One, two, three -- not so many.
>>VINT CERF: I'm definitely hijacked.
I see that DNS hijack is the task force leader.
>>STEVE CROCKER: We've got you where we want you.
>>VINT CERF: This is very cleverly written.
Because whatever domain name you go to is instantiated in the text of the message that comes up, making you think that the place you went to is endorsing this particular Web page.
And the part I like especially, it says that it needs your help in ensuring practicable access to your account by criminals.
>>STEVE CROCKER: We could have, without any trouble, provided a page that looks closer to what you actually were looking for and interposed ourselves in a subsequent set of interactions.
And so if you were making a purchase, we could take your credit card and stash it away, completing your regular purchase, and then going off on our own and making others, or any other kind of information.
Equally, although this demonstration is set up to intercept -- or to provide you an alternate Web page, we could have intercepted E-mail, read it all, read the returns, and so forth, and quite thoroughly interrupted your privacy.
The amount of software involved here is very, very small.
This is not very difficult to put together.
And we're careful when we do these demos to set it up on a separate network and to advertise what we're doing and to do it in a very limited way.
But somebody who is seriously interested in interrupting your flow or in stealing your information could do this surreptitiously and would not be easily visible.
Let me ask, any questions?
Yes.
>>VINT CERF: Just one other question.
I assume you could easily have -- cause some Java code to be downloaded, or JavaScript, or PERL, or whatever else, in the course of bringing up the Web page, leaving something -- potentially leaving something behind as well?
>>STEVE CROCKER: Yes.
Almost anything, from cookies to JavaScript to Java code to ActiveX, as you've suggested.
That's right, we could leave behind a present and have it keep on giving.
Sorry.
I didn't plug in here, and now it's going to sleep on me.
Any other questions?
All right.
So with that, I'm going to shut off the demo.
Oh, here, this isn't very pretty, but I can see what people are trying to go for.
I'll tell you.
Somebody's going to weather.
Koi.pir.com.
Ping -- plaxo.com.
Printicannm.ma.
Aftonbladit.research-int.se, talk.google.
Yahoo!, wired, phobos.apple.com.edgesuite.net.
Nowar.info.
You get the idea.
Ripe.net.
Interesting assortment.
Okay.
Is anybody scared yet?
>>VINT CERF: Do you have a change of underwear with you, by any chance?
>>STEVE CROCKER: Do I need one?
Yes, I do, fortunately.
Okay.
I have now shut off the demo.
So you should be safe.
And, no, I will not hand out the code.
And Steve Conte's taking down the network so that it no longer will be accessible to do this.
Although, I can hijack the regular network.
But I will not.
I will not.
All right.
So that is -- let's see.
Let me come back to where we are here.
So why DNS security?
Well, as we've just shown, DNS is not secure.
There are various known vulnerabilities.
There's no question that people depend very heavily, everybody depends very heavily, on the domain name system.
The DNS security protocol protects against -- excuse me -- against the kind of things that you've just seen, against data spoofing and corruption in the domain name system, not at other levels of the system.
This is a building block as part of an overall more secure network.
A quick review, and I'm sure that ram will take you through other aspects of this, that the data flow in preparing and providing DNS information starts with a zone administrator putting together a zone file, shown over here on the left.
And perhaps, in some cases, there are dynamic updates where new entries are created by users.
All of this leads to a master file, which is then copied onto various slaves, and provided to various forward -- caching forwarders, and then, finally, resolvers access these forwarders, and sometimes the masters and slaves directly, and pick up the DNS entries that they're looking for.
The vulnerabilities in this system are at every single point.
The ones on the left are related to -- that is, protecting against the ones on the left are really a matter of controlling the process for creating and updating the master zone, the master file and fall under the general direction of what we call here server protection.
And on the right-hand side, which is -- corresponds to the lookup process, it corresponds to what I would call here data protection, the DNSsec protocol protects primarily the right-hand side of this picture.
And there are other, more classic and straightforward, techniques that have been in service for a long time, using TSIG and others that protect on the left side of this.
So DNSsec protects against data spoofing and construct.
TSIG protects the mechanisms to authenticate the communication between servers.
That's the -- principally, the left-hand side of that diagram.
And the technical pieces of the DNS security protocol that involves cryptographic keys and signature records, provides the mechanisms to establish the authenticity and the integrity of the data that's being transmitted from the servers to the resolvers, and, ultimately, on to the end users.
A quick comment that this, in effect, provides a infrastructure of cryptographic keys.
It's similar in many respects to a public key infrastructure.
It's built with a different purpose in mind and a different set of ground rules.
Its focus is directly on protecting the DNS system and not on providing legal protection, for example, that -- for signed contracts or other aspects like that.
And so in that respect, it's somewhat different from a traditional public key infrastructure, although there are some similarities, and it will be interesting over a period of time to see what happens as DNSsec is deployed and used, and then see what applications come out on top of that.
The current status of the protocol is that the formal specifications were approved in the spring last year, and they're now the formal standards documents from the IETF.
It's taken about a dozen years, I have to say, with some embarrassment, for all of this to go forward.
That embarrassment is shared on stage here, triggered, actually, originally by a still vivid phone call when Vint called me up one day and said, "We have a serious problem and we need to get this fixed right away."
I should have written down the date.
But it was in the last century sometime.
The major deployment issues now that the protocol is defined revolve around a series of chicken-and-egg problems of getting all the zones signed and getting resolvers that can handle DNSsec. And within the spectrum of getting the zones signed, there are top-down and bottom-up questions.
From the top, getting the root signed is a special subject all on its own.
And then each of the Top-Level Domains needs to be signed. At this present moment we are fortunate that that process has started. Sweden has fully signed and deployed its zone. Other TLDs are working on it.
And then the enterprises, each one eventually, will have to have signed entries, and I have a comment about that, which is why I have flagged that over here.
And then the resolvers and the applications.
Let me focus for a moment on the process of getting the root signed.
There are six -- sometimes I have a chart like this that shows seven steps, but this is a nice, clean, sensible picture, that there has to be a process for generating the key. This is technically a straightforward process that can be done in a few minutes by easily available software. But because there is so much political attention to this process, it's called out here as a very special step on its own.
Once the -- and this involves a pair of keys, of course, the private and the public key pairs which match each other.
Once those are generated, the public part has to be distributed, which is step "B" here.
And then the private part is used to sign the root. In the case of the root zone, somewhat different from most other zones, there is a substantial separation from the preparation process for the zone and the serving process. There are 13 separate root server operations, and the zone file is prepared separately through a combination of IANA and VeriSign activity. And then made available on an internal distribution server, and then copied out to each of the 13 root servers.
So for those root servers to be ready, each one of them, all of them have to be ready to serve DNSsec queries. And so that causes us to separate the signing process, which can be done in a single place, from the implementation and operational readiness of the 13 root servers, which is shown here in step "D."
With all of those in place, we then are in a position to accept the keys from the TLDs, these are so-called children keys, and put entries into the root zone that correspond to those and show there is a signed entry down at the TLD.
This can be done in parallel, but it can't be served up until the root server operators are ready. All of this comes together in step "F," where the root server operators are ready to serve the signed zone and keys are flowing in from the TLDs.
Getting enterprises signed is -- has a mildly surprising aspect to it. I found it useful over the past few months to distinguish between enterprises which run their own DNS name service and enterprises which outsource their DNS name service.
The outsourcing is very, very common, and often unnoticed in a way, particularly for very small individual or small businesses which are -- get a Web site or get a domain name and then have a hosting service of some sort. And then if you ask, so who is running your name service, they may have trouble actually understanding the question. And then when you probe down a little bit, it will turn out to be an adjunct or a part of the registrar's function or the hosting service's function or sometimes the ISP's.
There is at the high end of the spectrum very substantial commercial operations that run name service professionally for large companies or small companies. Ultra DNS is one that specializes particularly in this and run names service for thousands of enterprises as well as others.
So the reason why it's interesting from our perspective to distinguish between internal versus outsourced operation is that there's a number of steps to -- that are needed to run DNS security, procurement of the software, some internal procedures, and possibly some training and management practices and so forth.
An outsourced operation can do all of that, and once they have done it for one of their customers, they can do it for all of their customers at essentially the same cost. And the impact on their customers is zero. There's no management, there's no training, there's no extra facilities that are required.
It's possible, depending upon the business practices, that they may be asked to agree to have their zone signed or they may even be asked to pay a little bit, but they don't have to allocate new personnel. They don't have to go to any training. And the differences on the impact on the operation is very, very substantial.
So I'm looking forward to a deployment cycle in which there's a handful of early adopters, such as us, who are running DNSsec, and there will be a growing number of technically competent operations that are doing it themselves.
And then as these various forms of outsourced DNS providers start to add DNS security to their repertoire, then I'm expecting that the number of DNSsec-compliant zones will jump upward quite rapidly.
So this is the list of the kinds of things that one has to be concerned with for an inside operation. Procuring the software, possibly extra hardware, setting up internal operations policies that include key lifetimes and a chain of management authority, internal procedures and training. And for people who want to do that, we are trying to build a list of founding DNSsec operators and provide a cooperative secondary and, in some cases, primary service for each other.
But on the other hand, in terms of watching the larger picture, I think the DNS service providers will be the source of a very large number of signed zones in the not-so-distant future.
Getting back to the founding operator concept, if you want to participate in this, we have a little list of small directory of primary and secondary signers and operators, and here is the Web site. www.dnssec-deployment.org/zones. Or come to me or send e-mail.
And here are some contacts and resources. If these brochures ever arrive, all of this information is printed on there as well, and this is also available on the ICANN Web site, I hope, and on the www.dnssec-deployment.org Web site.
So with that, let me turn the floor over to RAM who will take you through all of this in a careful and far more lucid --
>>VINT CERF: Steve?
>>STEVE CROCKER: Sabine? Yes, go ahead, please.
>>SABINE DOLDERER: (inaudible).
>>STEVE CROCKER: Yes, if --
>>SABINE DOLDERER: (inaudible).
>>STEVE CROCKER: Yes, I understand your question. And if you don't mind, let me summarize what you have said because without the benefit of the microphone.
So Sabine has asked in the signing process for the root zone, there are three stages that involve IANA, the Department of Commerce, and VeriSign, and changes start from inputs to IANA and then messages that are sent to the Department of commerce, and then onward to VeriSign, and then VeriSign prepares, edits it.
And your question is who holds and who uses the signing key, the private key there.
And let me add a little bit more to it.
There actually are two levels of keys in the protocol. There is an upper key or a so-called key-signing key, and that's the one that's the public part and distributed worldwide to everybody and that's used to sign the zone signing key. And the zone signing key is used to sign each of the entries within the root.
So for a change to a particular root zone entry, the zone-signing key would be the one that's brought into play.
So that's just a consequence of the way the protocol is arranged.
And now you're asking the question which a large number of people are watching and holding their breath waiting to see what the answer is, and I have to disappoint you and tell you that that, quote, "Remains under discussion."
And I do not have a crisp answer, but we -- nor, sadly, can I say that it's under my control. If it were, I would give you an answer and we would get a sensible arrangement.
The elements of a sensible arrangement are that the process needs to be operationally secure, it needs to be well run, and in words that you have heard over and over in this environment and many others, it needs to be pretty visible and transparent and accountable so that people everywhere can trust and understand what that process is.
I am expecting that over the next several months there will be very substantial visibility into the discussions around all of this, and that it will begin to emerge. And that's, I'm afraid, the best that I can tell you at the moment.
That said, I am actually encouraged that there is quite a lot of progress going on.
Any other questions?
>>SABINE DOLDERER: If there is mainly an auto political problem. The question is in which circles, actually, these discussions will take place because it will be, let's say, it will be the question of who will have the ultimate actually key to the root. Which means who will be the one who will have the final one.
And I think if it's IANA, then it will raise concern by a lot of people. If it will be the D.O.C., it will raise concern by even more people. And if it's VeriSign, it will raise concern by still even more and more people.
So in which circles or in which platforms these discussions will be done? Because we are discussing in the community, the IANA functions, a very, very sensible problem, and how it changes, the IANA functions and (inaudible) will be approved. And surely it's another level of complexity to this system.
>>STEVE CROCKER: I appreciate what you're saying, and you present a difficult picture in which you named the IANA, the Department of commerce, and VeriSign, and if one picks any of those three there will be questions and difficulties.
What would happen if we picked you? Quite a few of us trust you. Would you be willing to do this? And what kind of questions would be raised by that?
>>SABINE DOLDERER: I don't think -- of course I would do it, and I'm sure in a trustworthy way, but I don't think that's the right answer.
I think when, as you say, there has to be a process and it has to be a process which has to be defined and has to be discussed on the community.
>>STEVE CROCKER: Yeah.
>>SABINE DOLDERER: And my question is, where will it be decided? Where will it be discussed? And how can we feed input to it?
>>STEVE CROCKER: I can't give you the answer that you want because I don't know at the moment. Vint is waving his hand. Before we get there, just a second, I do want to insert something that I think is very, very important as part of the general understanding here.
The process for updating the root zone is, as you said, without respect to any signing process, that changes go into IANA. There is a very careful process within the IANA function to validate the kinds of requests, to make sure that they are technically coherent and consistent, to prevent errors. And then an editing process that goes through, as you said, Department of commerce for approval and then on to VeriSign.
And there is quite a large amount of attention in that process to getting the data right.
That process is not envisioned to change, and here's the very, very important aspect.
That is where the data, that is where the content of the root zone is determined.
The signing process does not control the content of the root zone. The signing process adds the equivalent of a check sum with the additional strength that in addition to normal check sums prevent against errors of nature, a cryptographic signature prevents against malicious tampering. But the only thing, and this is the point I want to emphasize over and over again, the only thing that the signing process actually does is guarantee the integrity or the ability to detect a tampering or loss of integrity of the information as it passes through various stages.
But the control of the content itself is already well understood, well described, and is not envisioned to change.
So there is -- I have encountered in many, many forums the suggestion that whoever controls the root key controls the content of the root zone. That's just not true at all. The content of the root zone is currently under control, and that process is not envisioned to change in any great substantial way. Or if it does change, it will change in the ways you have alluded to in terms of describing possible changes to IANA.
Let me take Vint's thing and I will come back to you, because I know you want to continue this.
>>VINT CERF: Let's see, just a -- I don't have any more accurate answer than you do for Sabine, but I was going to suggest that as she was going through, Sabine, the various issues and their side effects, it would be useful if you would care to contribute exactly that kind of analysis into this process.
So if you would like to write down what the various alternatives are from your point of view, and what the side effects are, good and bad, that ought to be part of the process. So I would like to invite you specifically to do that.
The second observation I would make is that if -- if the elements of the root zone file arrive in signed form -- I don't know that they do, but if they arrived in signed form, it's not possible for anyone in the root zone formation process to alter the integrity of what you send up, because you will have signed it, presumably.
That doesn't -- that still leaves open the question of whether what you sent gets into the root zone file. And I think part of what Sabine is starting to analyze is the concern that if someone said, "I'm responsible for signing the object, and I refuse to sign it in this form," we have a problem.
But we have that problem now in some sense, independent of signing.
If someone sent a change to IANA and IANA either refused to put it into the root zone file or the D.O.C. refused to let it go into the root zone file, we would have the same problem that you might be imagining we would have with regard to signing.
So it's not a new problem.
The problem has to be -- or the solution has to be that the contents of the root zone file come from the operators who provide that information.
>>STEVE CROCKER: Yes. And let me add to your invitation for input and strengthen it considerably.
I know sometimes an invitation of the form "please write down and send it in" leaves open the question will anybody pay attention or what's that process.
I can assure you that the question you have raised is well understood and taken very seriously. And I personally am looking forward to the time that we can have that open discussion. And for what its worth, I can tell you that you are -- we haven't had this discussion, but you are definitely one of the people that I would put on the top of any page of interested and important people that have to be involved in this.
You run one of the very largest zones in the world, and do a spectacular job of independent management.
So it's a source of expertise and authority that would -- I think is absolutely essential.
>>SABINE DOLDERER: I would love to get a lot of input and I would love to write it down, but a lot of the problems we are facing now is that some of the processes are still a little bit unclear.
So there is -- we know the process. We know that things -- how things are going into IANA. We know that the D.O.C. usually make approval. We know there will be done some additional checking within VeriSign. And some of them -- the things are not really transparent.
And regarding to what the different players are doing, I think you will see that the signing has to happen on one or the other place.
But I think it's extremely important that all -- that it's getting much more transparent, what possibilities each of these three operators has, and how they can actually affect things.
>>STEVE CROCKER: I agree with you quite strongly.
We're shifting -- this part of the dialogue is shifting away from DNS in particular and more toward root zone update and IANA operations, but I can tell you from the perspective I have of interacting with the ICANN staff very closely that there is quite a lot of attention to improving the clarity and reliability of the IANA operations and the reporting and the documentation of procedures and so forth. And I think that, by itself, independent of anything related to DNSsec, is healthy on its own.
>>SABINE DOLDERER: I think that that's perfectly valid, but I think on the one side people are looking and clarifying and making the IANA function more transparent. On the other side I saw you are announcing there will be soon something additionally coming, and it was not very clear in which circles the process will be defined. And I would urge you to make these -- to come with these two efforts together. That in these circles where the IANA function is discussed, also these changes will be discussed that we all know very clear what happened and that one change came up from another part.
Thank you.
>>STEVE CROCKER: Thank you.
Anybody else want to add a question? All right. With that, let me move on to ask RAM to step up and take over here.
>>RAM MOHAN: Good morning.
My name is Ram Mohan.
I am the chief technical officer for Afilias, registry service provider.
And I'm here to talk to you in a reasonably non-technical manner about DNSsec.
Many of you, as you go to various conferences probably hear about -- some of you, at least -- probably hear about DNSsec.
And in my own personal experience when I've gone and attended, almost all of them assume that you already know about the DNS, you already understand what the different components are, and you have someone technical, often, sitting or standing on the stage talking about resource records and, you know, TC keys, and using a lot of words and jargon that have tremendous meaning to those who already know about the DNS, but can often be quite cryptic to those who are outside of the -- of that scheme.
So the focus today is a brief set of slides that attempt to describe DNSsec in a relatively nontechnical manner.
So this is what I have on the agenda at a pretty high level, to find out what DNS does for you, what can go wrong, why really tickies created DNSsec, what can happen without it, why should anyone care, what kind of consequences might be there, and talk a little bit about responsibilities of various players in the network.
So what does the DNS do for you?
At the -- on a pretty nontechnical level, what it does is it tells machines where to go when you type in a Web address or send an E-mail.
And under the wraps, what happens is, you know, from your laptop or your computer, when you type in a domain name or a Web address, there is a little program that's sitting on your computer that is called a resolver.
And it says, first, am I online?
If I'm online, where should I go to get my answer?
You know, the person typed in a domain name or a Web address or is trying to send an E-mail.
Where should I go to find out where to send it to?
What's the address of this name?
And typically, the very first place in resolver goes to is the local Internet Service Provider.
Now, in the -- because of optimization and trying to give a very fast answer, what the ISP typically tends to do is say, well, we know that a lot of people are going to go here at this meeting to ICANN.org or Google.com or a number of different sites.
So when I have the addresses, the I.P. addresses, associated with those domain names, let me store it, keep it in memory.
Let me just remember where they are so that I don't have to go all the way out to the Internet, find out where these addresses are, and bring them back.
Let me store it in what's called a cache.
So if I already have -- if the cache already has the answer for, you know, the domain name or the URL that's being looked up, finds it out, sends the answer right back.
If it doesn't have it, these -- the ISP basically says, "Well, I need to go contact the domain name server and find out, where is it."
If the request is to go to ICANN.org, well, if I don't know where ICANN.org is in my own memory, well, let me first go to the root zones and find out, where is dot org being served from?
And then it goes to the dot org servers and says, now, tell me where is ICANN.org being served from?
And it kind of goes down until it actually gets the answer and it's sent all the way back.
So on the name server side, it finds the I.P. address, sends it back; right?
Now, as Steve demonstrated quite effectively just a little while ago, there are multiple places whereas these questions are being asked and answers being returned, there are places where it can be hijacked.
The answer can be modified, you can be redirected.
In the case that Steve showed you, he redirected you explicitly to a different place.
But if there was somebody who was much more malicious than that, you could not -- you don't have to do that.
You can simply listen to all of the traffic that was going on, which, again, Steve showed.
He was able to see where the traffic is going.
You can find out information without you, the user, even knowing what's going on.
Let's talk for just a minute about why is this an attractive target.
You know, Russ Mundy about a year ago had what I thought was an excellent presentation in which he presented a few reasons why the DNS is actually a pretty ripe target for attack.
There are technologies out there that use the DNS to mitigate spam and phishing.
But there is dollar -- there's a lot of money there for the bad guys.
Today, if you go on Google and you look at DNS hijacking tools as the key word, you will find free tools available that will allow you to hijack and provide spoof data on the DNS.
Now, be warned, some of these tools if you install on a computer also install spyware that'll then also help take over your own computer.
There are other things.
For example, stock tickers and RSS feeds.
You know, there is no authentication, you type in, you know, finance.yahoo.com, and you think you're going there.
It could easily have been put up on a different site, giving you different information.
You think it looks real, but it may not be what it really is.
And if you look at -- on the eNom side, which maps telephone numbers to services in the DNS, manages a case where you get auto-redirected to the wrong place.
What are the things that can go wrong?
You can have forgery.
The DNS data being returned to your ISP can be forged.
As Steve showed a little while ago, it's pretty easy on a wireless network.
Poisoning is possible.
The DNS data itself can be modified.
And what happens then is that your ISP or ISPs upstream, their cache can have valid information, so it would -- provides a valid response, but it's wrong.
It's been poisoned.
As we were also showing before, eavesdropping is pretty easy.
There are other things that can also go wrong.
And I won't get into a lot of those details.
The zone data itself can be altered.
Various components along the chain can be impersonated, and updates can be made that are not authorized.
But you would never know it as a user.
In 2005, Allison Mankin, in a presentation, talked about an ISP attack.
Users of an ISP had specific software, you know, spyware, spam, and pay-per-click Trojans, from various sites.
They picked up the software due to redirection. Okay?
They thought they were going to place A. They ended up going to place B.
It resulted in spyware and different Trojans being installed on their computers.
Now, when the attack was detected and measures were taken to correct it, but here is the interesting thing, when the -- those who were analyzing the attack went and looked at the cache of the ISP, they found a whole bunch of DNS names that were spoofed.
There are a few examples on the screen.
But as you can see, there is financial incentive at play here in addition to a number of just -- it used to be just do it for fun.
But it's -- there's real money to be lost here.
So let's talk a little bit about DNSsec itself; right.
So what does it do and what is it?
I'd like to characterize DNSsec, it's the Internet's answer to identity theft.
You know, as much as your own identity can be spoofed and stolen if you are not careful with it, in a similar way, at the DNS level, at the network level, when you say you want to go to a particular place and you're redirected somewhere else, you know, that's, you know, thievery, your being redirected somewhere else.
What does it do?
It protects users from -- the intent is to protect users from DNS attacks that specifically cover things like spoofing or cache poisoning or modification of information.
But, additionally, it makes systems, the actual computers that are doing the job, it provides it a way to detect that such an attack is actually happening.
And how does it do it?
It does it because almost everything in a DNSsec implementation is digitally signed.
And what that means is that when a resolver, when a machine actually says, I am getting a response to a request, it has the ability to go back to authenticate, is the origin of this data actually the right one?
Okay.
And it also ensures integrity of the DNS data that is being passed through.
Because along the way, if data is modified or otherwise compromised en route, there is something called a signature.
The signature is no longer valid.
And the way DNSsec is set up, there's a chain.
If the chain is broken midway, the information is no longer propagated.
It's no longer sent on; right?
So digitally signed is, in techie terms, it's called public key cryptography.
And the short form of it is, it's got two things associated with it: A secret, private key, and an open, public key.
And again, in layperson's terms, DNS messages request responses are scrambled using the private key.
Now, when it's scrambled that way, you need the public key to actually unscramble it.
And this is called signing, in, again, a technical way.
And as a result, when a response is received, you now can -- because you have the public key, right, as a resolver, machines along the way, when they have the public key, they can unscramble this message that's coming back, and by unscrambling it, they can say, I now know who sent this message to me; right?
So you can authenticate where the message is coming from.
And as an aside, DNSsec is really a short form for DNS security extensions.
I was talking just a little while ago about the chain of trust.
The concept behind chain of trust is the following: If I trust a public key from someone, I can then use that key to verify the signature, and by doing so, I can authenticate the source.
Whoever or whichever machine sent me that information.
So you've got to make sure that the root zone key can be trusted.
And once -- and the way DNSsec is set up, at the top level, if that key can be trusted, that -- at that top level, there are cryptographic pointers that are pointers to each of the lower zones that say, if you get here, here is a authenticated way to tell you where to go next to find out the next set of answers for DNS requests.
Because -- and each pointer is validated with the previous validated zone key.
So there is -- you cannot get to the next step if the previous step hasn't already been validated.
And at each step, because it's signed, there is a great deal of integrity of the data that's being given to you and that you're passing on.
Now, with the chain of trust, this is a -- the idea here is, you only need one key.
The key at the root zone.
That's all you need to validate all the DNSsec keys on the Internet; right?
So if the root is signed, you can use the -- at the root, it then has pointers that say, for all the zones underneath the root, assuming a day where all the zones are signed, the root will say, here is an authenticated way.
Here are the actual cryptographic -- encrypted pointers to where each of these next zones are.
At the next zone level, similarly, it'll have pointers to subzones; right?
So it's a pretty easy way to make it happen once you have both the zone signed at the root as well as at the next levels down.
Now, how to update these keys and how to propagate them in a safe and secure way, there is work under progress.
And this is not completely done as yet.
I'm going to take just a few minutes and talk about some of the technical details behind DNSsec.
As I had mentioned earlier, every set of DNS data in the DNSsec protocol is authenticated.
And this DNS data is called a DNS resource record set or RRs.
So some of you may know these as A records or MX records, or DNAMEs or whatever.
You've heard these terms.
But kind of combined together, they're called resource records.
Every one of them gets to be authenticated.
The other thing that DNSsec also allows and provides is, it authenticates the absence of DNS data.
So, for example, XYZ.ICANN.org does not exist, will be brought back to you in a pretty authenticated manner.
The other thing that DNSsec as an Internet protocol and a technical standard has done is, it creates four new DNS record types.
And I won't get into the details of what those are.
You can look them up.
And I'll show you some sites that you can go and look them up on.
And it validates using the chain of trust, which I talked about just a minute ago.
Each answer is signed.
A couple of things DNSsec does not do.
It does not guarantee that your data is going to be -- that the data you send back and forth is going to be confidential.
It merely makes sure that there is integrity of the data and that you know who it's coming from.
But there's no guarantee of confidentiality.
This does not provide -- this is no substitute for the other secure mechanisms you must use.
And it also does not provide, you know, protection against denial of service attacks.
That was not its original intent.
So -- and it does not do that today.
Now, SSL and IPSec, IPSec, some of you may know this as VPN.
That's what -- when you go on VPN, you're actually implementing I.P. security.
And that's not enough for the DNS attack that is we're talking about.
Just SSL or just IPSec, or even the combination of the two will not stop you from having spoof data and from having the DNS identity theft to happen.
I want to spend just a minute about roles and responsibilities.
There is a pretty large group that has to get involved in the DNSsec effort here: Registrars, network operators, registries, ICANN, root server operators, ISPs.
They need to coordinate and interact to make DNSsec work well.
Now, what are some of the technical tasks that have to be done?
You have to create DNSsec-capable name servers from the top level, from the root zone, top-level domains, and the lower-level zones.
And then policies have to be put together, be put together.
For example, there is a -- there is something called zone-walking.
Now, I had talked about this, and without giving you the techie term for it, before.
If you go to the root, you know where to go next, cryptographically, and then further down.
If you take the dot com zone, assuming it is signed, for example, you could, theoretically, discover every single name in the zone by simply using DNSsec.
Now, there is work underway to provide some security and privacy in that area.
The other thing that also is being figured out is how to handle a rollover of a key.
So we talked about, okay, there is keys, and because there are keys, you have security, and you have some integrity in the DNS data requests/response flow.
What happens if the key has to be changed?
How do you pass the new key on?
How do you roll it over?
And how do you do it in a way that is safe, that's secure, and fast?
Right?
And that work is also yet to be done.
And Sabine, some of your questions kind of reach out to that area as well.
Now, something new has been brought up in the DNSsec area.
And you will hear sometimes folks saying "DLV," "We have implemented DLV."
And I wanted to take a minute to talk just a little bit about what that is.
It's a short form, yet another acronym.
But it's really -- it's DNSsec look-aside validation.
Paul Vixie from Internet -- Internet systems consortium, ISC, in a press release, this is what he said, you know, if the root isn't signed and if TLDs are not signed, then the DNSsec spec offers no way to start wide-scale deployment, right.
So his idea, and ISC's idea, which is currently implemented, it's an interim approach.
It compensates for no signed root.
What it does is, it provides a secure location where you can obtain the DNSsec validation information, okay.
It's not -- it's intentionally not an IETF extension.
But ISC has implemented it in bind 9.3.2, and later.
And it's managed by ISC.
So what next?
The root must be signed.
And, again, Steve spoke about that.
This is an area that's certainly going to have -- that requires -- this is an area where the technology has to be implemented, but, really, it's not a technology issue; it's -- it's -- there are so many other things that have to be figured out.
As Steve said, Sweden was the first TLD itself to be signed.
The DLV registry allows a look-aside mechanism kind of in the interim.
But one of the things that I think does need to be done is to evangelize the need for DNSsec at industry -- in industry, organization -- consortiums, in companies, and in organizations.
And policies have to be established.
These are important things.
Because one of the things that -- as a registry operator, one of the things I hear from registrars and ISPs is, "Our customers aren't asking for this.
Our customers, there is no buzzword about this."
And one of the questions that I'm typically asked is, "Does DNSsec stop phishing?
If it does, then we have a reason for deploying it."
Well, it doesn't.
But it doesn't yet have that level of need that's been established.
And education is an important component there.
That kind of concludes my prepared comments here.
There are some URLs on the screen in terms of places to go.
There is an excellent set of tutorials that RIPE has put up.
The link is there.
This presentation will also go up on the ICANN Web site.
So you should be able to pull it down.
The last slide that I have here are various mailing lists, various active discussions, mostly technical.
But if you have technical people in your organization or people who want to learn and interact and participate in discussions about DNSsec, there are a number of excellent mailing lists that you ought to think of, and at least if not participate, at least look and listen.
Thank you.
Any questions?
>>VINT CERF: Oh, are you going to use the microphone?
Maybe someone can pull that microphone and then we can hand it around like a hot dog.
>> BOB HUTCHINSON: Hi, I'm Bob Hutchinson.
I had three questions for you, RAM.
Twelve years in the making.
When will DNSsec spec be complete, in your estimation, in terms of the whole chain, key circulation, everything?
Second question, --
>>RAM MOHAN: Let me take it one at a time.
My memory fails when I hear too many questions.
So let me just try and answer this.
Yes, it's been 12 years in work.
I think we're at a point now where we're -- from here to the point where it's ready for deployment -- I mean, the -- for example, we would -- one of the problems identified just a few years ago was, you know, tree-walking.
In the past, something like that could have taken three, four, five years to actually get resolved.
But in this case, the solution was actually identified pretty quickly, and practical implementations are there now.
So I think there is momentum behind this.
Both qualified technical people and qualified nontechnical decision-makers who are involved in the IETF process are actually paying attention to it.
So I'm very hopeful that -- The thing about protocols is that, you know, just when you think it's done, it gets obsolete and you've got to go and start something new.
So a specific answer to when will it be done, it's hard to give an answer.
It's an IETF process, and it's a pretty consensus-based process.
But there is a tremendous amount of momentum, I think, compared to where it was many years ago.
Your second question?
>>BOB HUTCHINSON: Second question.
So if we don't really know, like, within, like, a year or two whether the whole spec, the key circulation, everything will be implementable, then I guess my second question is going to be difficult to answer, which is, when will DNSsec be required in the root and the TLDs?
Do you have any time frame or is there any notion of that?
>>RAM MOHAN: I'm going to actually ask Steve if he would like to join in on this.
Again, I don't have -- I can't tell you when.
But I can tell you that as a -- both as a TLD registry operator and as a service provider for multiple TLDs, in dot org, for example, DNSsec implementation has been established as a very high priority for implementation.
And it's -- you know, it's all the way at the board levels.
There are committees and there are -- there is a tremendous amount of focus on making it happen.
But I'm unable to give you an explicit date for it.
>>STEVE CROCKER: I can see this swinging around to me.
Sweden is up and running.
There will be some other TLDs, I would say, hopefully, during the course of this calendar year.
Not so many, but a couple.
And then I think things are going to break loose rather substantially in 2007.
I think the root process will be visible, all the public processes that we talked about earlier will take place.
I think all the mechanics are straightforward.
I don't think that's the issue.
In terms of TLDs, there are quite a few TLDs that are doing explorations and test beds and laying the foundation.
And I think that, again, without wanting to speak on their behalf, but just integrating what I'm hearing and making a reasonable assessment, I would say that things will start happening in -- pretty vigorously in 2007, if not earlier.
We have a DNSsec deployment newsletter which you're welcome to sign up that we put out once a month with news.
And, fortunately, we're able to find things to put into that newsletter.
So that's a positive thing.
And as I say, I think you'll see a quickening process that will take place fairly rapidly, actually, in the latter part of this year and going into next year.
>>BOB HUTCHINSON: And the last question is, does DNSsec run all the way to the user resolver?
And if so, is the user resolver in windows DNSsec-compliant at this point?
Or do you know?
>>RAM MOHAN: Best of my knowledge, it's not.
Other questions?
Thank you very much.
>>VINT CERF: RAM, this is slightly off topic.
But there is a similar vulnerability to the DNS problem that shows up in BGP routing. And there's been a lot of debate about the use of SBGP and whether it's overkill or too processing-intensive.
Other suggestions that have been made involve signing of route registry information so that it binds an AS number with a set of I.P. addresses, and all signed with a key.
And then you could use that during the time that you're actually running BGP updates to decide whether an update announcing an I.P. address associated with a given A.S. number is or is not valid.
Is there -- to your knowledge, is there any activity along those lines underway in anyplace, IETF or elsewhere?
>>RAM MOHAN: I think by far the most provocative thing that's happened is Vixie's DLV mechanism.
There's -- there are a lot of hallway conversations in the IETF about doing something similar.
But I haven't actually seen something that's crystallized into -- I don't even recall a bird of a feather meeting that has come together and said, "Maybe we can implement something similar."
>>VINT CERF: I'll take that up with Thomas Narten.
I see Mouhamet has his hand up.
>>MOUHAMET DIOP: I just want to say that this discussion has been raised during the AfriNIC meeting.
And part of the option that people are trying to look at is, are we going to use the regional Internet registries as the CA for the signing?
Because the -- I mean, the questions that have been raised all along this presentation is, who are we all going to trust in order to build this whole infrastructure of public and private key.
So are we going to give that authority to IANA or can we trust an organization like the regional registry in case of the routing environment.
And I think that this might be a good solution to rely on the regional Internet registry authorities for the signing.
So it's not already decided, but I think that it can be a way to move forward.
>>VINT CERF: Thank you, Mouhamet.
>>STEVE CROCKER: Add just a tiny bit to that.
This really is a bit of a separate topic about routing security.
I know from -- there are parallel discussions for routing security compared to DNS.
They're parallel, but they're not in sync.
And they're, I would say, considerably farther behind for a couple of reasons, one of which is that there is not a natural organizational structure behind routing, as there is for DNS.
So the mere fact that ICANN exists, for example, and IANA exists and that there's a hierarchical DNS structure actually is helpful despite up-close, it sometimes looks very chaotic, but it's much worse over in the routing area.
>>RAM MOHAN: Thank you.
>>STEVE CROCKER: With that, let me invite Maria Zitkova, from SITA.
And we'll get set up here.
>>MARIA ZITKOVA: Thank you so much.
I think I should precede my presentation with a little comment and thank you. Some of you know my computer stopped working on Monday, and the presentation was on my computer. And I am very thankful both for Steve for letting me borrow his computer to do my presentation and most importantly, Tina Dam, who helped me retype my presentation to her computer.
Okay. What I would like to do is basically share with you some views and experiences we have made from discussions about DNSsec in the (inaudible) community, and I will share with you a little bit about dot aero itself.
The dot aero is much more than a domain name registration service.
Sometimes in 2000, when my colleagues in SITA looked at the idea of ICANN (inaudible) domains, they looked at it and said, well, actually, our community has lots of different coding systems, and we use all those legacy communication systems that predate Internet.
Maybe one day, somehow, we will need to move this to Internet. And the coding systems that we have will need to be met somehow in some other digital identifiers.
And I said, okay, well, maybe let's have a look. We can try it for DNS.
And I have to say that in 2000, it was an idea.
From the perspective, from where we stand today, dot aero is a community initiative. It is a, first of all, a normal domain registration service as any other gTLD. The relationship has been cooperated by Afilias, but it is also a tool for developing maintaining policies that are very specific to the aviation community.
We work with a number of aviation organizations and associations which are members of something we called dot aero council. And the long-term objective of the dot aero initiative is to use this DNS structure as a tool works for the community to help us with all the convergence and changes with voice over IP. And you will hear later about RFIDs. And the DNSsec is an important factor.
When I talk about DNSsec with my colleagues in the aviation community, and I will often use airlines and aerospace as an example but this equally applies to other segments of the community, it occasionally happens that they have heard about DNSsec, but it's not too many of them.
And it is fairly clear that from the I.T. community at large, people who are not involved in DNS, DNSsec is something very distant.
They don't see what it is, what it should be doing, how they could implement it. Occasionally they hear something about, well, but we need to sign our root and we still don't know when and how. You had from other registries last year or on the previous DNSsec workshops there is no customer coming asking.
So one could reasonably ask one's self why are we actually here? What are we trying to do?
We can look at it from a completely different perspective. We can look at it on the technology itself. I believe many of you probably had a very nice report of sign post in cyberspace and that characterizes the risk of a message being passed between servers is one of the top security challenges that the DNS is facing.
And yet, in DNSsec, we have a standard, and we have something that commercial solution doesn't have. We have an open technology that can help us to address this issue. And aviation, as probably other segments, is (inaudible) using the Internet. And this is something we might very well need to be able to use the Internet to its full potential.
So I think that the DNS deployment is really about the awareness within the wider I.T. community. It's about understanding what it is and what it can do and what it cannot do.
And last, but I think the most important, about the ability of the technology to actually solve real problems. We have to be able to demonstrate on very specific problems what does it do, how does it solve them.
Just having a little bit of security for everyone is a very hard case to solve.
So if you look at it from the context of the aviation, what are the problems? You probably all, everyone, I assume, are traveling on an airline to come here. You may have changed a couple of airlines. And everyone's assumption was that the changes will be instant, smooth. Your suitcase will make it.
Well, the airlines may have computers, yet they had to cooperate with each other.
So the very specific thing on the aviation is a very high level of integration (inaudible). There is a strong cost-cutting pressure, obviously. And then the security is very, very important.
And last but not least, and it might be an interesting consideration for DNSsec, one of the consideration that my aviation colleagues often say about technologies is before we choose a technology, we have to make sure it will be here in 30 years, because if we are going to build an aircraft and if we are going to build some data processing that is supposed to serve this aircraft, this aircraft will be flying in 30 years so the other things must work too.
So it's another important consideration that they will put into the equation.
There are a number of very specific high-level I.T. projects that are going on in the community.
The new air bus, the new Boeing, they will both be essentially a big flying network.
The aircraft, even in the air, will be fully connected to the base systems. Every aircraft part is going to be tracked electronically. And if you look at the initiatives that are in the more passenger oriented area, IATA has announced last year, actually, 18 months ago, a simplified business initiative, and that has been a decision by carriers, how can we make our business more flexibility, faster, and use the available technologies.
And what did they do? They have decided that by 2007, all airline ticketing must be based on E-ticketing. It may sound boring but what it means is that you will no longer have a paper that has a value. You can have a printout, but all the important information will be in the database of a carrier. And it may be a different carrier than the one you are flying with. So they have to make sure they can communicate very reliably with everyone.
The second initiative is using common self-service skills at airports. This is very similar to the concept of ATMs for cash. You come, you check in at a kiosk, no matter what airline you are using.
The third one is using bar coding standards for boarding passes. Again, this is an identification technology, and for the technology to work on a community scale, it will need some sort of communication processing of identifiers.
The fourth of the initiatives is putting RFID tags on all baggage. And since the initiative has been announced, it has been also extended to RFID tagging of spare parts and RFID tagging of all assets at airports.
All those items, all those identifiers, somehow, somewhere will have to be managed in a digital form.
And if you follow what is happening, for example, around EPC global you will find the DNS itself is an important technology in this context.
And the last initiative I should mention is the paperless cargo.
Right now, in these days and months, the technologies and the standards to ensure security of all those communications are being developed.
There is lots of work about public infrastructure. There is a development of global security policies, certification bridges between different industries are being built.
This is the time for us to look how does DNS security fit into this whole picture. Because many of those who are developing those standards only just heard about DNSsec. And it might well be that some of the problems they are trying to solve could be much more easily addressed with this as an open technology.
To give you some examples that the community is trying to explore, it has held that distributing public keys even for a close community is a very costly and complex exercise. And in some situations, DNSsec may be a useful and helpful tool to do this.
What we have to do, though, is we have to understand what are the right scenarios where DNSsec is good, and where do we need something much stronger.
And balanced between the two, because on the one hand it's the cost, and on one hand is the sort of security and reliability.
You may be surprised also to find that many IP-based systems that are used in the community, they still don't even use DNS. Lots of communications are configured with fixed IP address to fixed IP address.
I can't go to all the reasons, but I do still think that it might be that DNS security is one of the missing elements why DNS is actually not used.
And it is clear that communications from one fixed IP address to another are inflexible. There is a price to pay. So there might be very well a cost saving in actually deploying DNS security, only if the I.T. experts in those segments actually knew what it is, how it works.
And last but not least, I think it is actually going to be very important, if you think back about all the initiatives from IATA, you saw the RFID on bags, you saw the two-D bar codes. These are the technologies that are very likely going to use some form of domain name system.
The EPC global standards define something that's called object naming system, and it is effectively a DNS implementation for data processing that relates to RFID identifiers.
If we put this kind of processing on DNS, we have to be double sure that this information cannot be spoofed because we can't afford having aircraft part identifiers spoofed or a phone number spoofed. This is critical and I think this might actually be the drivers for the actual deployment of DNSsec.
In summary, looking at the DNSsec from the perspective of a sponsored community, for us it's not about how many more domain names we can sell. It is about is there anything of a value that we can deliver to the community. How much we can help them to improve their current communications. If we can do that, we can deploy DNSsec.
But in reality, and I think that this is a very important consideration which has general application not just to our community, adoption of solutions typically starts with small, very clearly defined scenarios.
I think we are misleading ourselves if we think that the whole world will adopt a solution immediately. We have to find very specific cases where it helps right now, and then it's going to move further.
And one more comment also I wanted to make, and that was the reason for our part of the presentation. We have to look at very real problems that individual businesses are facing or communities and solve those.
In the context of specific programs and correctly combined with other technologies, I think that there is still a nice way to go.
Now, to show that it's not just me speaking for the aviation community, I'm very proud to announce that in October, at ATA's e-business forum, there is actually going to be a one-and-a-half hour panel session that is dedicated to DNS security. And this is going to be the first time when the DNSsec experts meet with the security experts that work in the aerospace and airlines, and they will have one-and-a-half hour to debate and discuss how the security in airlines and airports and the skills of the DNSsec can fit together.
That concludes my presentation. I can understand it was a little different, but I would like to see if there are any questions.
>>VINT CERF: I have to dash off to a TV interview, I have to tell you I was so excited to see that list of applications that you are considering.
That's very creative.
And for the first time I realize there may be applications that can use DNSsec in sort of the least part of the edges of the DNS, independent of whether the rest of the path to the route has been signed.
This is a very, very interesting outcome. It says that we can start doing DNSsec at the edges for some useful purposes. Very, very interesting. Thank you for that.
>>MARIA ZITKOVA: Thank you very much for that comment. It has been a comment I was planning to make, and I forgot.
But I think that while this is true, I still think that the signing of the root is important. Because this is how we can bring DNS security to the end user. And also one thing that is not in this presentation but I think is very obvious, like banks need to very much rely on the stability and security of the Internet for their customers to come, exactly the same scenario applies for airlines.
Many customers check in or buy their tickets online. This is a very important distribution tool for airlines, and it's really important for them that they can continue making it secure, and also that the Internet actually stays one so that the customers don't have to use different systems in different countries as they travel.
Thank you.
>>STEVE CROCKER: Thank you, Marie. Any other questions?
Good.
All right. Thank you.
I'd like to turn over -- turn into panel discussion for a moment.
Thank you very much. Thanks.
Let me ask Mouhamet and Alain to start.
Do either of you have a statement or something you would like to say with regard to DNS security?
>>ALAIN AINA: Okay, thanks, Steve. And thank you once again for pushing for this workshop.
I think that for African community, awareness about DNSsec and technical workshop are very needed. And I think some ccTLD and some people from our community are asking for a workshop. This is something, we need to work on it and see what we can do. And if we can get more awareness, a workshop like this, that would be a good thing.
>>STEVE CROCKER: I think that's a very good thing.
There are a number of DNSsec training workshops that take place, and I -- I understand that there has been some discussion about doing one in Africa in the next several months sometime.
>>MOUHAMET DIOP: Thank you, Steve.
It seemed that the most hard topics that need to be discussed at the technical level have been raised already. Regarding, for example, how all these systems are going to rely on -- which are going to play the role of the single (inaudible) for the distribution of the key and so on.
So the point that we can share here is on an African perspective, what can we do in order to be ready because we know that this discussion have been raised for over 12 years regarding all the RFC that have been issued regarding the security of the DNS.
I wonder that if AfTLD, that is the new African ccTLD organization, that in which you find all the ccTLD manager in Africa, it will be also a very good place and a good candidate to try to promote awareness and training for people at the regional level and at a national level.
One of the commitment that you already have from some of the CC is this message is from the CC from Senegal that have shown great interest in starting doing some lab test locally in Senegal and trying to see how we can develop that level of awareness and expertise, because as Alain have said, we have two big workshops in Africa that are really technical for ISPs, run by AfNOG, and we have the other one that is the African meeting.
So we have a new one that is the AfTLD, and both of them, we're trying to get all the technical people that try to work around the technical aspect of the Internet be ready to exchange and increase the level of expertise that we are trying to build as part of the capacity-building program for the whole Africa continent.
So I think that it will be really important that the DNSsec group include part of its program, like how they can fit into the regional outreach program or the regional training program that people are trying to set up.
So the AfTLD have presently made their general assembly on -- during the week on Sunday, I think. And it means that we have a new organization with whom we can deal with all the problem regarding the DNS. And they are really eager to get things moved on in their own agenda.
So I think that one of the important step is to be ready to help whenever we schedule a meeting, or training program at the regional or national level that Steve can see if there's any resource available in order to help somehow develop the skill at that level.
Thank you.
>>STEVE CROCKER: Mouhamet, that sounds like an absolutely excellent idea.
I did hear some very positive things about the AfTLD meeting here.
Is there another -- what is the schedule of meetings? Is it intended that the AfTLD group will meet at ICANN meetings or will they have their own meetings? And is there a schedule set for such meetings?
>>MOUHAMET DIOP: I think that we have in the audience a representative from AfTLD here. We can share with them. We have the new president that have been appointed to chair the AfTLD in Africa. Michuki is the CC manager for Kenya, so he can give precise response regarding that point.
>>STEVE CROCKER: Good. And let me ask you for the transcript if you would identify yourself clearly so we can get it spelled properly here.
>>MUCHIKI MWANGI: Thank you, Steve, Mouhamet. My name is Michuki Mwangi, M-I-C-H-U-K-I and then M-W-A-N-G-I, from dot KE.
We had a meeting and the success of the afTLD meeting actually allowed us to select a new board in addition to the existing executive committee. And we also did have a meeting and agreed that we will try, in essence, to have teleconferences every two months to try and see how fast we can try to achieve all objectives that have been laid out over the next period of the next 12-month period.
And also, we will try and meet at AfriNIC meetings wherever possible during the regional AfriNIC meetings, like the next one in Mauritius, hopefully.
And also, at the AfNOG meetings. This is an annual meeting that is held across Africa in back-to-back meetings with the AfNOG and AfriNIC trainings.
And also, at AfriNIC -- ICANN meetings that are held in Africa we will try also to bring together the CCs.
When the ICANN meetings are held outside Africa, it will probably not be feasible to see African -- or, rather, many CCs from Africa attending these meetings because of the constraints that they face in terms of financial and so forth.
So we will try and maintain the meetings to be within Africa as much as possible.
And teleconferencing.
Thanks.
>>STEVE CROCKER: Good.
Well, to the extent that we can be helpful, we'd be more than happy to help provide guidance or support for DNS security. And I look forward to engaging in more discussions and interactions quite vigorously over the next several months.
>>MUCHIKI MWANGI: Thank you.
>>STEVE CROCKER: Thank you.
So let me call on other panel members. Ram.
>>RAM MOHAN: This is a question for both Alain and Mouhamet as well as other African folks who are here.
What level of government interest and support exists for something like DNSsec?
>>ALAIN AINA: I could say, let us know, but I am not a good guy for political. Maybe Mouhamet. But my view from my perspective, I am not seeing any public interest of supporting DNSsec.
>>MOUHAMET DIOP: Thank you, Alain. I think that it could (inaudible) a more political guy than him. I can take it that way as well.
I think the situation of the CC in Africa can give you an answer to your question. Because it is quite a diverse situation on who is managing the CC in the countries.
And also, the added question is what is the level of penetration, of implementation of E-government application like if the government is really aware of what can represent the Internet and a secure DNS for them as a layout for all the application they are trying to run on top of it.
So I think that on both case, I'm going to start with the first question regarding what is the level of implication of the government on the CC management.
We have in many African countries private management scheme. We get some other scheme where we have a mix of civil society, private sector, and government jointly managing the ccTLD. That's the case, for example, for Kenya. They came from a situation and they go to a process of an inclusive process where they call for implication from all stakeholders and they form and a committee and they work for the best interest of the whole Kenyan country.
So we get also some bad experience where the CC country is managed outside of the country and not necessarily in the benefit of the country, and it is really a conflicting situation where people are trying to go through redelegation.
So this is really a very diverse situation where you cannot say that the government really have a strong implication in the management of the CC.
But the trend is after the WSIS conclusion, that government will become more and more concerned about what's going on regarding the management of the CC.
So the second part of my answer is how far the government is going in order to implement E-government approach in order to use IP technology as the heart of the annual strategy of building application. And this is really a very strong movement, I can say from my Senegalese perspective, that the government have really been involved in a strong E-gov approach with all application running on top of IP network. And of course security become an issue. And we can say that the need for awareness is really strong on the CC side and also on the strategic side.
So I think that doing a regional program for making people really aware that they can do something to make the Internet more secure and it's really something that's going to help to push, really, the agenda for government to build E-gov application and E-gov strategy in Africa.
So that's why I think making Steve work closely with the CC community to help get some strategic joint effort and to build regulatory bodies and government being part of the awareness program will be something really important for the development of the DNSsec.
>>STEVE CROCKER: I think that's very helpful. And it -- oh, yeah. I'll call on you.
I think maybe we should attempt some assessment or rough survey across the different countries in terms of combination of readiness for DNSsec and the relationship between the government activity and the ccTLD operator.
There was a question? Or did -- somebody was standing up.
Yes.
>>MUCHIKI MWANGI: Yes, thank you, Steve. I just wanted to add on to what Mouhamet has put across, is that the diversities of what exist among the CCs in Africa that for many governments to start understanding DNSsec before they understand DNS or what is the CCTLDs function is quite a constraining factor at this point in time.
Taking my example of Kenya where we have a multistakeholder establishment to run the registry, until we have a -- I participated in a DNSsec training in cape town two years ago, the ICANN meetings, and went back and proposed maybe we should do DNSsec.
It was not taken up seriously by my board, you know, as a priority project.
So that also tells you that in as much as we made progress in terms of the way we run the registry, the priorities of looking at what is important at that particular point in time is issues of penetration vis-a-vis security.
So again, that has significant effect.
However, as a registry, we have been looking at how best to try and implement it in stages so that when it's time for us to go fully fledged, then it will probably take us the shortest time possible.
But we have already started a bit of groundwork in the KE registry.
>>STEVE CROCKER: Thank you, that's helpful. Any comments from the floor? Any questions? Mouhamet.
>>MOUHAMET DIOP: I can add that something specific to Africa is not -- I don't think it's a bad thing. It's just something that's going to help a lot when the continent is trying to catch up, is whenever you have a good experience from one country, it's very easy that other country come and look at this as a success story and duplicate it in other country.
So this happen very often in other area and I can give you an example. On the lawyer side, because all about the cyber or about the security and the data protection and the change in the law in order to make it support the new evolution of the electronic exchange, it become something that when some country start making the change, we have roughly the same law, and it's very easy for them to do exactly the same thing in their environment.
So why I'm saying that is we see the same things happen in the early '90s when they start getting the Internet access with one country. They just, I mean, duplicate the same model in the old different west African country.
They use the same upstream provider. So it's just -- this mean if we concentrate our effort even in order to get one or two ccTLD well managed, getting all the skills regarding the deployment of DNSsec, it will be very easy for them based on the language sensibility and all this stuff. So it's going to be easier for them to replicate or to diffuse this knowledge and this understanding in the other part of the African continent.
So I really insist, and I think the message have been heard, that doing things right now and trying to make people who are (inaudible) ready to move ahead, get the knowledge they need in order to move forward, will be something that is going to be really helpful for the next future deployment.
>>STEVE CROCKER: That sounds very encouraging, and I understand that you and your colleagues in Senegal are, in fact, very interested in being on the forefront.
Let me ask each of the panelists for one final comment, and I'll just move right down the row starting with RAM.
>>RAM MOHAN: Thank you, Steve. Thank you for having me here.
It seems to me that there are three things that are very important to actually make DNSsec a reality.
The technology component we have already talked about. Everybody talks about the technology component, but it seems to me that there are three critical pieces to make DNSsec happen. First is education, second is funding, and third is interest.
And we need to get these three components together, else all the best technology in the world is not going to be enough to make DNSsec a reality.
>>MARIA ZITKOVA: Thank you. I think -- does it work? I have two comments.
I think first of them is one thing that somehow came out but it was not mentioned too openly. And anytime we are talking about a technology that's open and that's essentially a standard, it has the potential to close the gap between, from my perspective, large carriers and small carriers, but I think it is also the closing between, say, more developed countries and less developed countries, because this is something that's accessible to anyone. You can just take it and use it. It doesn't depend on your market power, how much you can pay for a specific software.
And I think this is one thing that's very important for DNSsec, and we should keep this in mind.
The second thing that I wanted to mention and that very much was the reason for my presentation, I think that it's very important for us to go out to other I.T. communities that are trying to solve some security-related problems that do not necessarily think today that they may be related to DNS at all, because only this cross-breeding of ideas I think is what's going to make the implementations happen. Thank you.
>>STEVE CROCKER: And as you noted, you're having your own DNSsec workshop as part of the air transport association meeting in October, and I am looking forward to working with you on that.
Mouhamet.
>>MOUHAMET DIOP: I think that it was -- the message have been done. Ready to move forward. And I am just a relayer of the message because I work closer with the CC manager in Senegal, and as I have state initially, they are really excited to move forward on the experimentation, deployment, and gaining awareness on that. Thanks very much.
>>STEVE CROCKER: Good. And Alain.
>>ALAIN AINA:Thanks, Steve. And once again I will call for support to have (inaudible) in Africa. Education is part of the critical piece of the system so we need to train people on DNS, on network security, on DNSsec.
When a structure like AfTLD, AfriNIC and so on will be happening to get the information to the private sector, public sector and so on. But we really need to build capacity if we want the community really to support and then to implement this stuff.
>>STEVE CROCKER: Thank you.
Let me thank the entire panel, and let me thank all of you for your attention.
I know this is a topic of interest and growing interest over time.
We very much want feedback on what you have liked and what, perhaps, you didn't -- wish we had done differently, perhaps, in this.
And we'll take that as guidance for future meetings.
As I mentioned at the beginning, we have been attempting to run workshops like this on a regular basis, and we try to tune them and adjust them to improve their utility.
So feedback is not only welcome, but I think it will be -- you will see the results right away in terms of the next meeting.
Again, thank you all for coming.
With that, let me close this session, and there's still a full day of other meetings for our grueling ICANN schedule here.
Thank you.
(Applause)