ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>STEVE CROCKER: I apologize for the early hour.
And I think that means the people are going to be trickling in for a while.
So that puts us in the awkward position of deciding to start with very few people.
And I appreciate each and every one of you who has made it here -- or delaying a little bit.
I think I'm going to hold things off for a few minutes, but not terribly long.
And then we'll launch forward.
So bear with us a bit.
Thank you.

(Pause.)
well, good morning again.
We remain a distinguished, compact, small group here, so we're going to do the thing which you're all well-accustomed to.
I want everybody to move on down.
Come on down!
Come on, stand up, move in.
It's going to get worse after this.
This is just the beginning.
Empty out the cheap seats there, down in the middle here, get in the front rows.
Thank you, Pat.
Plenty of room.
No crowding.

>>BILL MANNING: You should tell them there's power up here.
>>STEVE CROCKER: There's power in front.
And electricity, too.
It's too early for those kind of jokes.
Sorry.
Yeah, that's fine.
Yeah, third row's okay.
Stage fright, really?
All right.
Well, thank you.
I appreciate the cooperation.
Since we have a small group, we'll make this as informal and as interactive as possible.
We have a very distinguished set of people who are going to walk through different parts of the process.
And I'll be a little clear about this in a moment.
And I want you to feel free to ask questions of each of the presenters, and then we'll have a question and answer period at the end.
I'll watch the clock and make sure that we're out of here on time.
But I think we can accommodate a fair amount of interaction, and I think it'll be helpful to do that.
So with that, welcome to workshop on deployment of the DNSsec protocol.
DNSsec is the new -- long in coming, but new DNS security protocol.
And this session is focused on deployment, and with some focus on the -- attention to registries.
People that are going to be in front of you today, I'm Steve Crocker.
I'm a co-chair of an American effort to push forth the deployment of DNSsec, working in conjunction with people really all over the globe.
Peter Koch, from DENIC, Bill Manning from ep.net, Suzanne Woolf from ISC, Jaap Akkerhuis from NLnet labs.
Daniel Karrenberg from ripe NCC, Matt Larson from Verizon, and Sam Weiler from SPARTA.
The -- oops -- we have -- oh, there we go.
The agenda today, there will be a presentation from Peter on DNSsec basics, Bill Manning, and perhaps Suzanne Woolf will present on DNSsec service availability.
Bill Manning has a demonstration, which we hope works.
And if it works, it's the attention-getting kind, where you walk away feeling less secure than you were before.
We will have a panel on myths and facts, a brief break, then a panel on software issues and then another panel on transition.
And I'll wrap up with questions and answers.
There is a meeting of the registries that takes place I believe starting at 10:00, and the purpose of the break there is to allow kind of a smooth transition.
So in about an hour and a half, give or take, we'll have that break.
But it'll be pretty brief.
I showed you who the presenters are.
Here are the people who will be on the myths and facts panel.
And here's the people who will be on the transition panel.
With that, let me ask Peter to come up and get things started.

>>PETER KOCH: Okay, good morning, everyone.
My name is Peter Koch.
Thanks, Steve, for the introduction.
And I'm going to tell you now some of the basics of DNS security.
So what am I going to talk about?
First, when you talk about DNS security, the first question is why.
Well, there are some weaknesses in the DNS, and I show you some of the details.
Well, there are weaknesses in there, but the DNS hasn't been invented yesterday, so we have gone away with those weaknesses for quite some time now.
Why still it is necessary to talk about DNS security.
Let's have a look into that what could implementations do?
Is it about bugs or the protocol?
We'll have some look into that.
What exactly will DNSsec bring us?
What are the benefits of DNSsec.
Finally, how does it work?
I won't bore you with protocol details and bits and bytes.
But some of the 32,000-foot-level information.
The WEATURES of DNS, weaknesses and features.
The DNS was invented 15, 20 years ago in a time when the Internet was a friendly place.
So ease of access, lightweight protocol, saving bandwidth and so on and so forth was the imperative at that time.
Today, there are millions of interacting components, well, this is true for the Internet at large, anyway.
But there are millions of interacting components where you just send a query in, some magic happens within that large network and you get an answer back and you trust it.
Still, you don't know where the the answer originated.
This is one of the main problems.
The DNS doesn't provide for any cryptographic security without DNSsec.
Spoofing is, of course, possible.
DNS is UDP-based and UDP is just I.P, the raw Internet protocol, with port numbers.
There is no authentication in it.
Anyone could spoof the I.P. address of a name server and send you answers that you asked for, although you asked the original server.
DNS is based on UDP, as I said, and that is a lightweight protocol.
There are no connections.
That means spoofing is, again, rather easy.
Someone is sending out a packet.
It's stateless.
Someone is sending out a packet and is expecting a response.
And it may happen that the response originates from a different place than the query was sent to.
And that different place might not be a friendly one.
Then there is some technicalities in there.
There is a little protection in the DNS protocol against unsolicited answers.
This is the IT field which is a 16-bit field.
That means we have roughly 65,000 different values in there.
And as a net attacker, I have to guess the particular value that was in your query when you asked for WWW .ICANN.org.
I have to guess this particular ID.
There are some attack methods which help getting away with this number.
65,000 packets is not too much.
And there are several texts possible that even lower this number.
One of those is the birthday attack.
You can remember that is the one that, surprisingly, gives you a much better opportunity of spoofing answers.
And, finally, the DNS very much relies upon caching and so-called additional section processing or additional information.
DNS servers usually try to be cute and helpful, and they do not only provide the answers you ask for, but they provide the answers you will be going to ask for, like, by the way, you asked for the mail server for ICANN.org.
And here is that I.P. address.
And there's some opportunity that those friendly name servers are not that friendly.
They will probably hand you out I.P. addresses that are a bit far from reality, like forged I.P. addresses.
So what do today's implementations do to circumnavigate the threats I presented?
Well, to the last point, most of those implementations today ignore the matter -- much of the additional information.
If that friendly name server just provides for an I.P. address for a Web server or for a mail server, they will ignore that information and go themselves asking the name server in charge for that particular address.
Today's implementations also will apply credibility heuristics to DNS answers.
DNS responses or DNS answers are comprised of several sections.
And implementations do some magic to give different weights to sections in the answers depending on where the answers originate from this helps mitigate some of these attacks, especially the additional section attacks, but it doesn't go very much deeper.
Today's implementation also try to really randomize these transaction items and maybe also the port numbers so that you really have to exploit the complete ID number space of 65,000 IDs or maybe even 65,000 port numbers if you try to attack someone who has an outstanding query and who you want to send a forged answer.
Recursive servers also usually allow for restriction on that recursion.
That is, you're not supposed to offer recursive services to anyone in the world, because that means you open up yourself to certain kind of attacks where any one in the world can make your resolver, your recursive server query a particular DNS query which may result in a cache poisoning.
Today's implementations offer you the opportunity to switch that off and just offer recursion to your particular clients.
So what we see is that the implementations are strengthened.
There's some intelligence in those implementations to mitigate these attacks.
But they are not immune.
The attacks are still possible.
They are probably a bit harder, but they are not immune.
So what are the main DNSsec benefits apart from dealing with those attacks?
The main points are, DNSsec -- sorry, DNSsec provides for data origin authentication.
That means you as a resolver or as an end user and the resolver on behalf of you can assure that the data, the DNS response packets arriving at that resolver arrive from exactly that point in the network where they were entered, that is, in the DNS zones.
Information for www.ICANN.org would carry a signature which says, well, this particular record, www.ICANN.org, originates from the ICANN.org zone.
And the ICANN.org zone maintainer entered this particular record into the DNS.
And it doesn't originate from somewhere across the street where one of the attackers sits and tries to poison caches.
Connected with data-origin authentication, of course, is data integrity.
Authentication without integrity is pointless.
It doesn't make sense if I know well it originated from ICANN.org.
But maybe it had been modified in transit.
Both, of course, belong together.
With those two components, we can really be sure that DNSsec applies, www.ICANN.org, I have the response in my hand or on my screen, and I can be sure this is the information that was entered into the ICANN.org zone by the responsible zone maintainer so how do we get there?
I've already talked about signing, signatures, and so on and so forth.
That's no magic.
Public key signatures have been used on the Internet for quite some time now, mostly for E-mail communication.
The fact that you don't use E-mail, secured E-mail, signatures on E-mail or even cryptographically secured E-mail or the fact that you don't see many signatures or don't sign your E-mails yourself probably has to do with the fact that there is no global PKI, no public key infrastructure.
So coming up with a solution for DNS, saying, well, all we need is we need a PKI and then we leverage on that and then we make the DNS secure will be a nonstarter.
So we don't do that.
We do not need a PKI, because we have a distribution mechanism for keys and signatures for free.
It's the DNS itself.
Keys are distributed through the DNS, and the signatures and certificates and so on and so forth, everything is in the DNS itself.
No external PKI is needed.
Security NS is surrender-independent technology.
There is no proprietary plug-ins needed or something like that.
It's an IETF proposed standard.
And don't be confused by the word "proposed."
It's just the entry maturity level for IETF standards.
It's documented in three IETF RFCs which have been published in March this year.
We will hear about details on that in a later talk, I guess.
There are separate keys per zone.
Every zone has a zone maintainer, is able to generate a key pair, a public and a private key, for the zone, and deal with that.
So you can track back information to each particular originating zone.
And then we have a chain of trust, like, I mean, if I go and go out and generate a PGP key for me and claim I am, well, the Pope or whoever, you won't believe me, because nobody would sign that.
They would only sign my identity.
And we need that chain of trust with DNSSec as well.
Someone claiming to be responsible for the ICANN.org zone needs some signature actually saying, yes, this is the ICANN.org zone and I checked this key with the ICANN.org zone maintainer.
So we have a chain of trust.
And that follows the delegation process which is happening anyway.
So there's no big magic and no big interaction on sideways.
Some more details.
What DNSsec does.
DNSsec authenticates the DNS resource records.
They are the units that are carried in DNS responses, like all addresses of www.example.org.
DNSsec can also authenticate negative responses, like the absence of a certain name or of a certain type of records, as in this example, RSS.example.org doesn't exist.
And DNSsec is able to prove that.
DNSsec does this by introducing four new record types, which are dealt with almost automatically.
So I don't show you how the records look like because the zone maintainer and the managers shouldn't be interested.
It's in the software and in the tools.
There are at least two implementations widely available which fully support the three DNSsec RFCs.
And again, I guess, Sam will talk to this in his presentation.
So digging a bit deeper into the technicalities, what happens or what should happen?
To get your zone secure, the zone maintainer first has to generate a key pair, a public key and a private key for the zone, to sign the information.
Dealing with a public key is easy.
It's named public key, so all we have to do with it is publish it.
And we publish it in the DNS, which is easy.
It's one of those new record types, the DNS key, the key is put in, it's published, and it's available to anyone.
The private key, of course, should be kept private because it's used to sign your information, and only you, as the zone maintainer, should be able to sign and authenticate that information.
The private key is then used to sign all the records in the zone like the name server records, the SOA records, the mailing (inaudible) records, and the address records, of course.
And not only the records are signed, but to prove the absence of information, also the gaps between names are signed.
So I can prove that between two names, there doesn't exist any other name.
And the cert information that is signed is to create the chain of trust through the DNS tree, that is, the so-called DS record, which is the second of the four new record types.
And the DS record is there to say, well, that delegated zone, example.org, really has that key, and I, as the dot org, or whatever the TLD manager is, I as the TLD manager say, yes, I have an interaction with that zone maintainer or with the registrar, and we sign, the delegation goes to that key.
Signatures, then, are put into the DNS signature response packets alongside the information you asked for, alongside the address records for Web server, for example.
The response contains the addresses, and then, by the way, here's the signature of this address.
And then you can find out that this information is really authentic. And this information will be put into the DNS response packets only if the client asked for it.
If the client said, "I would like to have secure DNS responses," the server, if it is able to support DNSsec, will enter the signatures into the response packets.
This is to ensure backwards-compatibility and not to confuse non-DNSsec-aware resolvers.
What has to happen on the consumer side?
We have a chain of trust, I said, like the TLD manager has a key pair, of course.
They are signing every records -- yeah, all the records in their zone.
They are signing the DS records for the delegated zones.
Second-level zones, if they do delegations, as they may be, they sign all their records in the zones.
They sign their delegations.
So this is how it goes down the tree.
What happens at the root?
Well, of course, the root also needs a key pair.
And that is like the addresses of the names of the root service.
This is the anchor, and in that case, it's the main trust anchor.
So the root key, the public root key, of course, must be widely published and well known, because it will be entered into millions and millions of validating resolvers so that they will be able to follow the chain of trust.
And the anchor of that chain of trust will be the root key.
Applications on the consumer side will need a DNSsec-aware API, of course.
And, again, I guess Sam is talking to this later.
So what is a task for a registry?
What is, yeah, an excerpt of those tasks.
First of all, because that is the easiest thing to do probably, deploy DNSsec-capable name servers, as I said, and as Sam will reiterate, I guess, DNSsec-aware software is available, and it can be deployed, without deploying DNSsec itself.
The point is that the software should be in place so you can go ahead with deploying DNSsec once you have dealt with the other problems or tasks, say.
So once you have done that, you should design and practice key handling and key handling procedures.
You need to generate keys.
There's lots of information available.
At the end, I have some URLs where you can find more information, for example, on how to deal with keys, key lifetimes, signature lifetimes, key sizes, what are the procedures, how many people should have access to keys, some suggestions on all of this.
Sure, you will have to review and maybe define new policies and procedures.
The DNSsec information, the fact that a delegated zone is DNSsec-secured, means that you have to validate the key information from that (inaudible) zone.
So that will influence the procedures in which -- with which registries deal with their customers either directly or through a registrar.
So belonging to these policies to be reviewed is, of course, how you deal with the registrars.
The registrars are probably supposed to hand you the customer's either DS record or the keys so that you can sign the DS records and prove that a certain zone maintainer, a certain customer really is in charge of maintaining a particular zone.
And for many of you, that will mean have a look at how you deal with EPP.
An EPP extension to deal with DNSsec is on its way in the IETF.
And I guess it either has been approved or is in the last stages of being approved and then subsequently published as an RFC.
If all this preparatory work is done, you have the opportunity to sign the DS records, generate and sign DS records so that the delegated zones from the TLD, yeah, can be marked secure.
And the chain of trust is available to the validator/resolvers.
I guess I'm a bit running out of time. The -- I will skip this part.
Now the question is now -- well, I've talked much about techie stuff like public key things and signing zones and so on and so forth. Is it really necessary? Nothing has happened so far.
Well, there haven't been any earthquakes in Luxembourg, but nobody would guarantee it won't happen.
Honestly, we don't want to fuel panic. There are no -- no, we don't, we don't fuel panic.
There is no guarantee that in the very, very near future there will be an attack. But on the other hand, nobody is going to sign that there won't be an attack.
Please have in mind that the DNS vulnerabilities are not about bugs in implementations. Well, there may be bugs in implementations, but this is not what dnssec is aiming at.
The absence of data origin authentification is a protocol inherent vulnerability so the protocol addition DNSsec is necessary to make this DNS secure. You can't do it just with fixing implementations because you can't fix what isn't broken.
There are many, many components in DNS service, resolvers and so on and so forth, which all have to be configured correctly to come to a point where the attacks I had on my earlier slides will be mitigated. So it doesn't really help.
Even the most sophisticated implementations can't protect you in the long run. Spoofing is possible, even with clever implementations.
I'm talking about spoofing. There are some guys out there, maybe some hackers that may be able to do this. Yes, they are. And what do these guys do? They publish their tools. Those tools are readily available. Just go out, Google for DNS hijacker, and you'll get a lot of hits. Yeah, don't install it, but see what I mean. They're available.
Most of them target the local resolver. We'll probably see a demo later. That means they intercept traffic between my laptop and the DNS name server that is available for this conference, for example.
Some, of course, are more advanced and can intercept traffic or can spoof traffic in the wide area Internet.
So, then, why doesn't happen anything? Why don't I read any usual news tickers, why don't I read about large-scale DNS spoofing attacks? Well, attackers are clever times, but they are also lazy. And the incentive is actually low for them, because, for example, phishing is so damn easy. Why deal with DNS packet spoofing if I can make so many more EUROs or dollars by phishing? That doesn't mean the opportunity isn't there. Bad guys are out there, so we should be prepared.
DNSsec is not the only solution. We're not going to sell you DNSsec as the solution to all security problems. It's just a small piece in the security puzzle. And like a comparison to the real world, probably all of you are car riders. We have different security measures. We have safety belts. Not all of us use them. Well, then we have the air bags, we have different electronic devices keeping the car on track, we have guardrails, so on and so forth. Nobody is claiming that you only need one of those, and so aren't we.
We're saying the DNS is a very basic technical infrastructure and a very low-level Internet protocol, and it needs security.
HTTPS, for example, or SSL, as you might know, is not enough. It is helpful in many cases and it works in many cases as long as your users are not accustomed to clicking away all these boring pop-up windows talking about invalid certificates or something like that.
But HTTPS is not always applicable because not all communication in the Internet goes over the Web.
We have ENUM. We have, for example, those fancy new DNS-based antispam measures. SSL or TLS, HTTPS won't help that. There are lots of applications that bring new levels of indirection where the information from the DNS is not directly an IP address but some different information, like an ENUM or like in these antispam measures. So every level of indirection brings an opportunity of forging end points. So this is a real threat and DNSsec can help mitigate that threat.
So it's a right point in time, a good point in time to start dealing with DNSsec, preparing.
The problem is when the attackers, tomorrow maybe, start to -- well, get interest in DNS spoofing, we can't just ship a patch and make all the applications secure because of that bug. It's not a bug. It's a protocol problem.
So we need preparation time. We need to review procedures, we need interaction between registries and registrars, between registry and customers, that is DNS zone maintainers, and that takes time. We need that preparation.
That means attacks don't start maybe tomorrow, don't probably start next week, but there is a fair chance that they start sometime next year or the year after.
We need the preparation time, and this is the reason why it's a good idea to start preparing today.
So why -- who is going to start? Looks complicated. Let the others start. Let the roots start, let the interested users start. Huh-uh, that won't work out.
First of all, it's a good idea to have the security measures in place before the catastrophe arrives. This is called prevention, and it's a Good idea these days.
The secure DNS tree needs signatures at all levels. That means signed TLDs, of course, yes, and a signed root. That's one that is politically interesting, which is why I won't talk about this any longer. It needs signed TLDs, and then of course signed zones at the deeper levels. But the problem is the early adopters, the geeks that may be interested in signing their zones, well, they are geeks today, they are your average customer tomorrow, they can't have signed -- they can't have DNS security without signed TLDs. So this is important.
And finally, of course, it helps securing the general technical infrastructure. That's always a good idea. So another incentive to start dealing with it at the TLD level.
And by the way, working for a TLD myself which has this zone walking problem, the zone walking problem is no excuse of saying, ah, well, we'll wait with dnssec before the zone walking problem is solved. Zone walking is a problem, but it's not the only problem. And it's being worked on in the IETF, so there are lots of other tasks that can be attacked now.
Finally, if you would like to have more information, find people working on DNSsec, on DNSsec deployment, there is this DNSsec deployment working group that Steve introduced, and the URL is up there. There is the IETF DNS op working group which is actively preparing recommendation documents for operational practices, like I said earlier, key handling, key lifetimes, what to think about with respect to key length and so on and so forth.
The URL is up there.
There is a collection of tools at DNSsec.net. There are various other working groups, and for example I picked the ripe working groups, the DNS working group at ripe, the technical security working group at ripe, and the ripe ncc DISI project which is preparing DNSsec, for example, on the dns reverse tree, the address to name mapping. And finally, there is a list in Sweden which is in English dealing with DNSsec -- well, gory technical details.
>> It's not DE, it's SE.
>>PETER KOCH: Oh, I'm sorry. It's se, yes. This is domain name hijacking. It was not intentional. I apologize. It's SE, of course.
Okay. That's it. Am I allowed to take questions?
>>STEVE CROCKER: Yes, we can have a question or two and then move forward.
>>VINT CERF: Hi, I'm Vint Cerf. This is on? And I didn't come in for the whole meeting, so if I'm asking a question you already answered, please just say so and I'll ask you later.
Getting all the software out that understands and responds properly to a signed response to a query sounds like a fairly big challenge. Is it literally all the resolvers in the network would ultimately need to have new software to check signed responses? Is that a correct understanding?
>>PETER KOCH: I guess the question was whether all resolvers have to be DNS DNSsec ready.
>>VINT CERF: No, I understand they don't all have to be simultaneous DNSsec ready but if we're going to make use of signing of responses that come back, I assume it's only useful if all the resolvers will do that, or it's preferable if all the resolvers will do the checking. Because the ones that don't do the checking won't be checking, and that won't be a good thing.
>>PETER KOCH: Yes, you're right, you must have access to a DNSsec aware resolver, which is called validator in that case most of the time, to make use of that signed information.
>>VINT CERF: Okay.
>>PETER KOCH: But that doesn't mean that the resolver on my laptop needs to be DNSsec aware.
>>VINT CERF: Yes, I understand that. I do understand that.
I'm just looking for ways of motivating people to install new software, point number one.
Point number two, Steve answer Ford me yesterday and I want to double-check, when you make a query to a server that is capable of sending back a signed answer, that only happens if you ask for the signed answer; is that right? So you don't have the problem of a signed answer coming back unexpectedly and the old software not knowing what to do with it.
>>PETER KOCH: Yeah, that's correct. There is a bit to be set in the query that says please give me signed answers if you have.
>>VINT CERF: Thank you.
>>PETER KOCH: So this is the backward compatibility issue.
>>VINT CERF: The only other hard question which I don't expect you to answer on the spot is what happens if we have to do a key revocation.
>>PETER KOCH: Thank you.
(Laughter.)
>>SAM WEILER: I'm going to attempt to answer Vint's first question which is does every resolver need to understand DNSsec to get benefit from it. I believe that was your question; right, Vint?
>>VINT CERF: No, what I said was, all the resolvers -- if not all the resolvers do this, then some resolvers will accept answers that may not be valid. That's all I'm saying.
>>SAM WEILER: That I believe is a correct statement. I think there is still benefit to be gained. DNSsec allows you to detect malfeasance on the network. If only a few nodes are doing detection, you can still get benefit from it.
>>VINT CERF: Absolutely.
>>SAM WEILER: At this point, I've forgotten your other two questions.
>>DANIEL KARRENBERG: Daniel Karrenberg. Isn't it such that if you use a caching forwarder that does checking for you, that even without a DNSsec capable resolver you get some benefit because you can trust the -- at least the information that gets cached is checked?
>>PETER KOCH: So you're saying that caching forwarder is DNSsec aware?
>>DANIEL KARRENBERG: Yes, if the caching forwarder is dnssec aware, you get some benefit even if your resolver isn't.
>>PETER KOCH: Yes, sure. So this is like delegating the responsibility for verification of these answers.
>>DANIEL KARRENBERG: which you do already.
>>PETER KOCH: Yes.
>>DANIEL KARRENBERG: (inaudible).
>>PETER KOCH: But you don't have any reason to, than you have.
>>STEVE CROCKER: Thank you very much, Peter. Bill Manning.
>>BILL MANNING: Good morning, my name is Bill Manning, and Vint, some of the questions you ask, if you stick around, if you can, there will be some discussion about those questions. There is not unanimity in the answer.
So Peter talked a little bit about this being equivalent to, in fact, a large jigsaw puzzle, and there seems to have been, over the course of the last, oh, I don't know, four or five years a little bit of misunderstanding about what some of those puzzle pieces are. So I'm going to try to tease some of them apart, particularly in the context of the root zone.
So the DNSsec actually is a couple of parts. The DNSsec itself is a set of tools, methods and operations to protect data integrity or provide data integrity and to authenticate the origin of the DNS or origin of the data.
So you can say this came from this set of servers and it wasn't tampered with in transit. That's what DNSsec does for you. It won't necessarily protect you against corrupt data.
The service availability is data preparation and data publication. How do I actually make this stuff available to the rest of the Internet? There are two distinct components.
So for DNSsec, the primary impact for data preparation is a number of phases. For most people, you have to now generate keys and you have to manage those keys. And that becomes a new part of your operational mode. So instead of just editing data, stuff that comes in, you're going to get some additional data about keys and you have to maintain and manage those keys for yourself and for others.
You then have to add a process for signing the data. DNSsec as designed assumes that you will edit some data and then process it by signing it.
You will also have the need to exchange keys, so parents and children, when you make a delegation to a child, I delegate ICANN.org as the org person to Vint, Vint is expected to create some information and hand it back to org where org maintains that.
We expect that at some point Vint may want to change his identity, change his pin number, and so there is a key rollover kind of concept that needs to happen.
So there is a communication, a more frequent communication between parent and child.
And you have to be able to hold that keying information reasonably.
Those things are new aspects of operations.
Most of this can be done in the context of normal registry operations. The keys are just additional data. There's nothing really special about them. They're the public keys.
The difficulty here is that the design is not really amenable to rapid or dynamic update. This is really looking at the historical thing.
So some DNS operations which do essentially near real time, I know that ultra DNS doesn't really have the concept of a zone file that you can sign. It's not really amenable to that and that's one of the difficulties in really making DNSsec across a variety of implementations.
Looking at that, that's how the DNSsec works and that's not really the service provisioning.
The service provisioning is the DNS. Somehow or other you get this signed data, this zone file, out of a registry and to the service publication people. In the case of the root zone, we get the signed data, we pry it out of ICANN and the IANA, and get it to the root NAME SERVER operators.
For other registries that may be the same people. For the root zone it's a distinctly different set of folks.
The requirements for publishing that really boils down to one point, is that all of the servers for a particular delegation, if you're going to sign the data, they must be able to load and serve the grown, which means they have to be running capable software.
For the people that run those servers, there's no real need for them to be actively involved or even know about the keying issues, holding of the key, signing the data. They're simply publishing.
In the context of root servers, the root servers, we have a series of things that we think are appropriate and important. Attributes. We want stable operations for the roots. We want it to be reliable, dependable, available and consistent. And some of the things that let us do that is that we, in the past, today and for the foreseeable future, all of us load the root zone provided by the IANA. Now, that may change, may be not, I don't know, but for right now, our stance is we take that from the IANA.
It would be nice if the IANA was to given us some additional hints that this was data from the IANA, and make that available to the rest of the community.
The root server operators have maintained some diversity in software. We really don't want a whole lot of commonality so we have people running various flavors of software.
DNSsec, when we're asked if we're ready to do that, we have to think carefully. The DNSsec compliant code is new. There are, as pointed out earlier, only a very few implementations that claim DNSsec compliance.
And each of the operators, because we are independent organizations, we're doing independent evaluations. Some of them take longer than others to do those evaluations.
Changing the code base on the root servers often demands a clear and sufficient justification. Why do we want to change a stable working system?
And if you talk to the individual root server operators, you'll find that each of them has a slightly different take on what constitutes a clear and sufficient justification.
Some of the operators, if you look at them, are ready now. The root name servers are running DNSsec capable code. Some are going to be ready this year, they've made statements about that. And some of them have said they're going to be ready six to nine months after there's a compelling case made, because it's going to take them that long.
In general, we think that the root server system will be ready to take a signed root zone in 2005, if that compelling case can be made; i.e., we get a signed zone.
There are still some areas of active discussion, though. Because not only do the servers on that service need to be able to serve -- load and serve that data, there need to be several other things that are sort of outside the actual service provisioning.
We need a time line for signed data. So looking at the IANA processes and their discussions and negotiations, we need to know from the IANA when that data is actually going to be available in a signed form, because that may be part of the compelling case.
We need to coordinate server readiness, making sure that, in fact, we're all pretty much ready to go.
That's true of any registry and the authoritative service for that registry. You need to know when you're going to be signed and you need to check to be sure that the people providing your service are ready to do this.
There are some best practices that are needed. We need to define how the root key rollover is to be done, if it is to be done at all. Some people think in fact the root key will never be compromised. Some people aren't that optimistic. So we need to have some discussion about what to do, how do we do that, because if we -- the root key is compromised, there is a whole lot of replacement that has to occur.
We need to look at software upgrades for authoritative servers, recursive servers and the revolvers. There will be some slides later that look at some numbers.
And then provisioning requirements are met. PETEr touched on this briefly. A DNSsec signed zone is larger than an unsigned zone. Some preliminary numbers, if you have a single key that's signed and it's an average size thing, your zone may double.
It may triple in size.
This means that the disk space you're storing it on and the memory footprint is going to be larger. The data bandwidth for moving it in and out will be bigger and the CPU cycles for signing it, you need to have those as part of your processes.
For most zones that I've looked at, this is not a particularly difficult issue. For the root, it's trivial. For very large zones with tens of millions of entries, it becomes an architectural discussion.
That's the end of my slides for right now.
Comments? Questions?
>>DANIEL KARRENBERG: Daniel Karrenberg. You mentioned that in the case that you are doing dynamic updates, there is a problem with DNSsec because it assumes a more static regime.
>>BILL MANNING: I said that it is not as amenable.
>>DANIEL KARRENBERG: Not as amenable. Okay.
Given that dynamic updates are really only effective when it concerned an addition of a new name or new records, how relevant is that? Because of caching. You cannot remove DNS information immediately because it's cached all over the place. So the only case where that really could matter is when you add something new. And then it's not an issue, either, because you also add the DNSsec information.
I don't quite understand your argument there.
>>BILL MANNING: I am aware of a couple of business models which allow large numbers of entries to be registered simultaneously. I may be a speculator in domain names, and I will go into a dictionary and I will register 10,000 new entries, or 100,000. Is my order of magnitude right? Okay. So 10,000 or 100,000 new entries out of the dictionary in a ten million entry zone. I may not wish to actually resign all ten million entries. I may want to do incremental signing, and the current set of signing tools don't easily support incremental update.
>>DANIEL KARRENBERG: But the architecture does.
>>BILL MANNING: The architecture does but the tools we have don't. The tools were developed for the legacy'S kind of dns.
Geoff.
>>GEOFF HOUSTON: GEOFF HOUSTON. This is hopefully a much easier question, and it is possibly a yes or no. In looking at the root DNS signing and in hearing you talk about the INTERCHANGE between the parent ZONE and THE delegated zone, the BASIC question is while the DNS is a hierarchy, is it necessary for my parent zone to have DNSsec before I can sign my zone?
>>BILL MANNING: No. You can sign --
>>geoff houston: In other words, having the root signed is more about the integrity of the root than a necessary precondition for the deployment of DNSsec everywhere else. In other words, I can deploy DNSsec before the root gets signed.
>>BILL MANNING: Oh, absolutely.
>>geoff houston: Exactly. Thank you.
>>BILL MANNING: Suzanne.
>>SUZANNE WOOLF: Sure, just kind of --
>>BILL MANNING: Pretend you're a Swede and stand tall.
>>SUZANNE WOOLF: Just kind of a quick follow up on geoff's question and the answer. The problem is not if geoff signs his zone and tells all his friends to put the key in his resolver. The problem is if everyone wants to apply DNSsec. Having the key in is a way to possibly scale.
>>BILL MANNING: Steve, am I up next?
>>STEVE CROCKER: You are. And this is show time; right?
>>BILL MANNING: I think this is show time.
Anybody looking at the screen, briefly? Okay. That screen right there. The little thing that says hijack, hijack, hijack, hijack.
Some of you may have seen something as a result of doing some DNS queries. Let me walk through my slides, if I may.
I am not the author of this material. I am not FUJIWARA KAZUNORI, who is a person who works for the JPRS Japanese registry services.
He and some of the other folks who did this work were students of mine a couple of years ago, and we talked a little bit about some of these things as they were moving on to new activities.
So I'm going to, if our infrastructure works properly, I'm going to try to demonstrate a DNS spoofing attack.
We're going to use a special network, some of you have already seen this, the network SSID is badboy, it's lower case because our support infrastructure is case insensitive.
So the SSID is badboy lower case F you don't want to be a participant, stay with the ICANN SSID.
Now, I'm going to behave today and I'm not going to steal your packets. Most of them. I'm steal a couple of them. But, in fact, I could take all of them and I would get all kinds of interesting stuff. But I'm not going to.
In previous demonstrations, we did. So looking at attacks of DNS, there is a denial of service attack to servers. You can send many queries to the DNS servers and overrun them. Or you can try to. This is a mere disturbance. It's easy to do but as an attacker, what benefits does the attacker get for simply taking out a name server? Maybe redirecting to another server.
A data spoofing attack induces people to go to another site. Some people call this phishing. There's an economical benefit, if I can actually redirect you, entice you to go somewhere else.
I can put you in an alternative root space, I can send you to my Web servers that look like the place you're going. I can do a lot of interesting things, if you trust the HTTP://wwW.ICANN.org to actually take you to the icann Web page and I throw up a little paypal thing that says pay your ICANN registration fees, 20,000 U.S. dollars, and if you type that in and you're on my site, thank you very much for your 20,000 U.S. dollars. It's not going to icann even though it looks like the ICANN site. I wouldn't do that to you and tell you.
>> (inaudible).
>>BILL MANNING: I'm sure.
This is kind of busy. And I think I get a laser pointer here.
The threat here comes from RFC 2833 and we're going to look at some of the threats here. And we're looking actually at a process in the middle. We're going to inject stuff in the middle of a broadcast domain. So we're going to steal the DNS query that comes on a shared Ethernet or a wireless LAN.
If I'm in a hot spot, this is easy.
And I will answer with a spoofed response before the correct one gets back to you.
This is easy and efficient.
And, in fact, we will try and demonstrate that today.
This is faster, easier, and simpler than ID guessing and query prediction, which Peter talked about earlier.
If I was going to do that, I would have to inject in a couple of other places, and my laser pointers are missing, but it's at points 3, 5, and 7 there.
I can do name-chaining, which is basically poisoning the cache in the resolver, the ISP's resolver.
Daniel, if you trust your ISP's resolver and get all of the ISP's customers; right?
Or I can just hijack the server.
Now, some measures that you can take, there's the application side, the SSH and SSL and TLL stuff.
But that's not sufficient, because social engineering says that people will see this little popup banner that says, "I don't know what the certificate is," and most people will just go click through.
Some people look at it like Peter this morning, and he said, no, no, no, somebody's trying to steal my stuff.
And I said, "Yeah, that was me."
Transaction signatures help.
And DNSsec helps.
So what we're going to do is we're going to do packet intercept.
If I was going to steal your packets, I would actually run TCP dump on the destination port on a shared Ethernet.
Since this is a wireless using a shared WEP key, you can do this, I can go to a Starbucks or anyplace that has an open wireless access point, and I can run this spoofing attack.
If it's a wired infrastructure, it's a little bit harder.
The idea here is that you parse the query packet before the name server can get it, generate the answer before the server can do that and then write that out to the network interface.
There -- as Peter pointed out, there are several, there are many of them, DNS hijack is out on the Internet, you can go find it.
You can run it.
I don't recommend it.
There are two here.
One of them is U.S. 800D, which was a project, Linux specific, he did that as part of the IPv6 for Linux.
This was the first tool they wrote.
So for IPv6 support for Linux that the wide people did, the first tools they wrote were attack tools.
This particular one is called DNS attack C.
It took two days of work for a busy grad student. It's about 400 lines of C code.
It uses the Berkeley filters in P cap which are generally available.
It runs on BSD and MacOS systems.
This is easily turned into a point and click.
Most of these are.
So you don't have to be smart as an attacker to actually do these kinds of attacks.
The first time this was run, this was done at the wide project research camp.
There were about 200 people.
Most of these are computer science graduate students or professors or engineers at high-tech companies in Japan.
People that know or should know better.
We told them 15 minutes ahead of time that we were going to attack.
We didn't tell them when.
And this was run on the public network out there.
What happens is is that we -- any DNS A query was induced to go to a specific Web server.
And that Web server and an SSH server.
So, basically, they had little honey pots to go off and get -- collect information.
The environment was 802.11A, 11B with multiple channels.
The attack tools were on a portable PC.
And the destination stuff was also on a portable PC.
And there was a recording PC doing the packet capture.
We're not going to do packet capture here.
They ran both tools.
For the few minutes that they ran, they found 100 I.P. addresses that were captured.
90% of those, 90 of the 100, were induced to go to the fake Web site.
The tool took 90% of them.
By evaluation by dig, people actually going in and trying to troubleshoot this, 80% of the answers were induced. They came from the wrong place.
The social engineering, the smart people ignored the SSH warnings of the host change.
They clicked right on through and went on.
Thank you very much.
There were some failures where the forgery did not work because of multiple channels or wireless reachability.
And if you already have something in your cache, it's faster than going out off the net.
At the time they ran this, it did not support IPv6.
It now does.
So they didn't consider this in an Ethernet switched environment.
But you can do that in a switch by using ARP poisoning or ARP spoofing.
This confuses the switch's ARP table, so you basically bridge ports.
In an 802.11x environment where there's no shared key, you can't really intercept the packets, So when you have tunnels, IPSEC tunnels, it's harder to do.
In a shared network, you can do it anywhere.
It becomes much more efficient.
So we're going to run -- briefly, we're going to do this.
If you want to do this and you have your laptop, please configure to use badboy.
Do not import and use communications.
I cannot guarantee you that Barbara is not going to be sniffing your packets.
Anybody want to try this?
>> Sure.
>>BILL MANNING: Anybody tried this?
>> We're already doing so.
>>BILL MANNING: You're already doing so.
What are you seeing?
>> (inaudible).
>>BILL MANNING: Web stuff gets intercepted.
What will happen is you'll see something like this; right?
You're forged.
This is the dummy HTTP server.
It tells me what I.P. address you're coming from and tells me a whole lot about what your host information and configuration is like.
I'm sorry?
>> The service seems to be unreachable.
>>BILL MANNING: Service seems to be unreachable.
I'm sorry.
Sometimes this stuff doesn't work so good.
Plug it in.
Okay.
JAAP says plug this in. I will steal his packets because he has cool stuff.
So for JAAP, right, this is from his machine.
It says connect and it's got the I.P. address.
The host he was trying to go to is www.ICANN.org.
He's coming in from Mozilla, tells me about what kind of PC he is running a PBC MacOS, and what his browser is.
All right?
So if I'm collecting this kind of information or other people are collecting this information, there is a real strong need to be able to identify and validate where you're coming from.
And DNSsec will not prevent spoofing, but it will let the application know, it can let the application know where this stuff is and when it starts to happen.
So you can see when people are spoofing you.
As opposed to just typing in www.ICANN.org and being redirected and having no way of knowing.
So that's why DNSsec is important.
Thank you.
Okay.
So this is how you put things back.
The assertion here is that DNSsec may help identify and foil -- it won't really foil, but it can identify it.
And if you can identify, you can take remedial actions to foil these types of attacks.
You cannot go there.
You can prevent things.
And we may see with some of the application API stuff a little bit later on today the ability to have an application throw up something that says, "I am not going to proceed because this is the wrong stuff."
So that's my demo.
Thank you very much.
Questions?
>>VINT CERF: Vint Cerf again.
First of all, thank you.
That's the sort of a dramatic demo that's always very compelling.
Just to make sure I understand, the point here is that if you were to -- if I was trying to go with my browser to a Web site or try to send E-mail to a particular target and the DNS response is not correct, that is to say, it wasn't signed properly, do we need to build new interfaces to the application-level software so that the response coming back from the DNS is made visible, so that we have a lot of potential now for application software modification in order to take advantage of and to make visible these problems?
In other words, is the fact that the DNS query comes back saying it's a bad answer needs to be propagated upwards somehow, which means I now have API interface requirements to make use of that somehow.
Is that a correct understanding?
>>BILL MANNING: In a very broad sense, yes. and after the break, Sam will actually talk about what has been done in that area from one particular group.
So applications do need some retrofit to be able to take advantage of this new signal.
Is that right, Sam?

>>SAM WEILER: Yes.
>>BILL MANNING: No more questions?
Steve?
>>STEVE CROCKER: No.
Thank you very much.
And ask that we move along to an interesting panel on myths -- excuse me, myths and facts.
And LISPS.
We have a whole set of people.
Come on up.
Jaap Akkerhuis from NL net labs is moderating.
And we have, from -- turn around and face backwards here, and then it will be commonly from our left -- Sam Weiler, Peter Koch, Matt Larson, Bill Manning, Daniel Karrenberg.
>>JAAP AKKERHUIS: I'm sorry about that.
Let's move on.
As Steve has said, this is the panel.
And we have -- we are trying to keep this short and brief.
But we hope to have some public interaction. And just trying to get the discussion going, we have some precooked examples of questions people have, which this is the first list, myths or facts.
Will the signing of the root that is a real big political problem or just a basic technical matter?
Who can start with that, would like to answer on that?
>>DANIEL KARRENBERG: I think if we don't regard it as just a technical matter, it will never happen.
So if we want DNSsec, I think we have to just treat it as just a technical matter.
The political issues that have been raised are mostly who holds the keys, things like that.
And it looks like at least in the hallways, it is being regarded as a way of changing basic policy.
And I think in this case, policy should follow -- sorry, technology should follow policy.
And the policy is that ICANN IANA currently determines what gets into the root zone file.
So they should hold what's called the key-signing key, which is basically the master key, or master keys.
And the people who actually compile the zone, do the technical editing bit before it gets distributed to the root name servers, which is currently VeriSign, they should hold the zone signing keys, which can be changed much more quickly than the key-signing key.
And as soon as we make this into a geopolitical problem, we might just as well -- it's my personal opinion we might just as well stop this whole DNSsec thing, because it will never -- the discussion will never terminate and we'll never get a root zone that's signed.
And as has been said earlier, the signed root zone is not an absolute requirement to get some benefit out of DNSsec.
But Suzanne Woolf has pointed out quite clearly -- and I agree with her -- that if we have a signed root, it's much easier to get benefit for many places from DNSsec.
So I think we need it.
>>BILL MANNING: And, Daniel, I believe that signing the root zone is just a technical matter.
With a set of keys, one runs through a standard set of processes to generate a signed zone.
So signing it is a technical matter.
You jumped right back out of the technical matter and specified your opinion about who should hold the keys that sign the data.
And from my particular perspective, I am not sure I agree with you about your opinions about who should hold the keys.
And therein lies part of the problem.
It's a technical matter.
It's just a technical matter.
It's the key.
Who decides who holds the keys is a political matter, not a technical matter.
>>MATT LARSON: Well, I guess I agree with both of you.
I would like to echo what Daniel says in that if we -- no, I can agree with both of you.
That's not contradictory.
I think the root zone from a political perspective is the third rail.
You know, that's the rail on the subway that is electrified with 10,000 volts and if you touch it, you die.
So we don't want to look at this as a political problem.
I just couldn't agree more with Daniel about that.
But I also agree with Bill that, you know, we are going to need to carefully consider the most important issue, the elephant in the room here, which is who does hold the keys for this.
And I think that one way around that is to not have a single key for the root zone, but multiple keys, and perhaps distribute them to multiple different organizations.
And that defuses the idea that the root zone key is special and whoever holds it has special power.
If there's multiple keys distributed, that will defuse that and make perhaps what I think could be a contentious issue into much less of an issue.
>>PETER KOCH: Yeah, well, may I add to the violent agreement here.
I think one point we should have in mind is that the signatures in DNSsec stand for authenticity and not for approval of that information, which is where the myths about that power comes from.
There's no power with DNSsec keys.
It's about just saying, "This is what I entered into the zone" and the signatures can come from someone who is not the person deciding what gets in there.
It's like a notary public function more or less.
>>JAAP AKKERHUIS: So to make a quick conclusion, which is probably -- it is actually more a technical problem than a lot of people see is a real political problem, with some small (inaudible).
Moving -- we have been running into the coffee break already.
And moving quickly on to the next more or less combined bullet points, and that has to do with problems of enumeration.
Enumeration is the fact that all signed, completely signed zone, you actually can get all of the details out of the zone.
And there are registries who don't like it.
So the question is, is this a show-stopper for DNSsec and how long will it take to solve this problem?
>>PETER KOCH: Me again?
For us, that is, DENIC, the position has been stated multiple times.
As long as the zone walking or zone enumeration problem is there, we will not be able to deploy DNSsec within DE.
So it is a problem.
But it's not a show-stopper in the sense that we will never deploy DNSsec.
There are solutions to be worked on, different ones, online signing, which is one path to go, which won't scale for a long time.
But the other one is NSEC 3, a protocol change to DNSsec, which is worked on in the IETF, and I'm confident that's a way to go.
And as I said earlier in my presentation, the zone enumeration problem is not an excuse to stop working on DNSsec.
It will slow down deployment in some cases.
>>SAM WEILER: I think the second bullet here, "the enumeration problem prohibits large-scale deployment," there is not consensus on.
We have heard from .NL and .SZ that they plan to sign their zones now even though they can be enumerated.
I think you'll see different registries and different zones having different issues.
For the third bullet point about whether this will be solved in six months, Peter mentioned two solutions, two technical solutions.
One is online signing, which can require extra hardware.
I believe that's ready to go today, though it does impose some burden on the registry.
NSEC 3, which is a protocol change, I think you may hear consensus from the panel that it will not be ready in anywhere near six months.
I don't think we can give you a firm estimate.
It depends on what resources are devoted to implementation and testing.
But it won't be ready in six months.

>>MATT LARSON: I guess just a couple more comments.
I think it's important in the technical community that we hear what these registries are saying when they say that they have an enumeration problem.
I mean, we've heard from .DE, we've heard from .UK, two of the largest ccTLDs, that they can't proceed with a DNSsec deployment as long as the zone enumeration problem exists.
So I think it's important from the engineering community to not push back and say, well, you know, are you sure you have a problem?
Are you sure you've talked to your lawyers?
We don't see that this is a problem.
I think that can be a knee-jerk reaction for engineers.
And I think it's important that instead we simply accept that these are the requirements and that we go back to the drawing board and come up with solutions to the requirements that we've heard.
I'd also like to say that I really think the online signing solution is really not a solution at all.
I mean, I think while technically it's interesting, I think operationally, it's something that's not going to scale.
So I really think the focus has to be on the NSEC 3 solution.
>>BILL MANNING: There's a lot of focus, I guess, on registries in the forward tree, the TLD constituents, if you will.
There's another group of folks that can be considered in some sense registries, which are the members of the NRO.
They're address registries.
Enumerating an address block is trivial.
And so it is not a particular issue.
So in the case there, I would say that for the address side, enumeration will not prohibit large-scale deployment.
For the address side, it's a myth.
And so, I don't know, Daniel, who is more closely tied to a registry, may have something to say.
>>DANIEL KARRENBERG: Oh, I thought that was for the next panel, but still --
>>BILL MANNING: It is.
>>DANIEL KARRENBERG: -- definitely, as Bill says, the reverse tree is that the tree under IN-ADDR.ARPA.
And that basically allows you to translate back from an I.P. address back to a name.
And since it's easy to enumerate all the I.P. addresses, you start with 1 and you end with 2 to the 32nd minus 1, there's no secrecy here.
And that's why the -- at least the ripe NCC, one of the address registries, we looked at the DNSsec and we thought we should promote it.
And we looked at the zones for which we -- our authoritative, the zones which we have to publish, and it was obvious that the reverse zones were the ones that we would attack first.
And we have a project running for already some months to get our reverse zones signed.
And the current time line is that we will start actually making signed delegations in the third quarter of this year, and the current goal is by the first quarter of the next year, that we have all the zones for which we are solely responsible signed and over signed delegations there.
Which is quite an ambitious project, because it's not just, as Bill has pointed out earlier, that you have all the servers -- the name servers DNSsec-ready, but you also have to do the provisioning side and the education side of the customers and so on.
So that's going to happen -- yeah, it's a myth in that area.
>>JAAP AKKERHUIS: Okay.
Let me start to move on to the next thing, and that's just a practical question in between.
But DNSsec would have protected -- will protect against the recent spoofing attacks.
>>BILL MANNING: No.
It won't.
It would not have protected against the spoofing attacks, because DNSsec as we have it today signs the data.
The validation components are immature, which will have to wait until the next presentation after the coffee break.
It won't protect.
But it would help you identify that they were occurring.
>>DANIEL KARRENBERG: Well, I wouldn't say so definitely no.
I don't know which particular attacks you are referring to.
It really depends on whether these attacks -- well, where exactly these attacks occur.
If you insert yourself, just like we did here with this public network, in -- right next to the user, then obviously, it wouldn't help.
But if you insert yourself a little bit more upstream, sort of in the general Internet between the authoritative name server and the caching name server, then if the caching name server would not accept unsigned data for signed zones, it would help.
So it really depends on where the attacker sits.
I think it's a myth that to get some -- to say that to get some benefit from DNSsec, that you will have to change all user software APIs and all that stuff.
There is already some benefit if you are caching forward which you trust already can trust the authoritative service across the Internet in general.
So it's -- I wouldn't say -- my "no" wouldn't be as resounding as Bill's there.
He said "okay."
>>JAAP AKKERHUIS: Okay.
We're running into the coffee break already.
But let's have a quick look at the next slide as well, which I -- which is there.
The first one is, actually -- has there are been mentioned.
The key rollover problem.
You really need to have that in place before you roll out DNSsec or can you make it up while you're going along?
>>MATT LARSON: I think this is a myth to a certain extent.
But I think we do have to be mindful that we are going to need a way to roll keys.
And I'll go back to the statement I made earlier about the root zone, that if we had multiple keys for the root zone and a way to roll multiple keys, this would greatly reduce the issue of key rollover.
So if we could deploy multiple keys right from the start, then there's much less pressure from a rollover standpoint and it buys us time to develop a robust and elegant rollover solution.
>>BILL MANNING: You can deploy DNSsec without key rollover processes defined.
Why would you want to?
I'm going to throw that back as the question.
I can have a very simple latch on my front door as the protection against burglary.
Is that sufficient?
Am I going to want to upgrade my locks or my protection from burglary, from attack, from theft as the sophistication of the attackers improves?
I think I do.
And if we deploy DNSsec without the ability to constantly upgrade capability, I think that we will find ourselves in a very difficult situation in trusting a DNSsec-signed infrastructure where the keys have been compromised.
>>JAAP AKKERHUIS: Well --
>>SAM WEILER: I'm going to refer back to a question that Vint asked about key revocation. DNSsec, rather than having key authentication, uses signature lifetimes to limit the damage that can be done by a compromised key.
That requires short signature lifetimes, it also, ideally, requires the ability to roll keys.
I think that several of my colleagues have confirmed, yes, we can deploy DNSsec without being able to do key rollover. And we can do key rollover easily everywhere except at a trust anchor, a key that gets configured into resolvers. But I think we also need to be establishing the expectation with resolver operators that we will roll over those trust anchors. We don't necessarily need the technical schemes fully engineered and ready to go, but we need to establish the expectation that those keys will roll.
>>JAAP AKKERHUIS: Thanks.
Given the time and we're running out, let's skip the next two bullets and go to the end, final two questions.
Sounds like, just to be sure, you really need application support, and isn't that really the big problem at the moment now we've done the server side?
>>BILL MANNING: I'm confused. The question is not specific enough.
Which -- what is the definition of end user? Some people would really like to be able to look at the 193.in-addr.ARPA zone and look at the signatures on it independently of any other applications and say, yeah, that is really ripeNCC's signature, and look at a different version of 193.in-addr.ARPA, and say, that's Bill Manning's signature. Which zone am I going to load? Bill Manning's or the RIPENCC's?
So there's some ability to discriminate which is useful independent of applications being able to automatically look for it, in my opinion.
>>PETER KOCH: This is the classical chicken and egg trap; right? So we -- we have a problem with early adopters here, as I tried to touch in my talk, because with HTTPS or with peer-to-peer or any new protocol when it was new, some consenting parties are enough to start deployment and gather interest into that particular protocol.
With DNSsec it's a bit more difficult. We heard and we're reminded by Suzanne that having too many islands of trust, it won't scale. So we need the involvement of higher layer, speaking of the tree, registries, like TLDs and the root.
But, of course, those, like us, need expressed customer demand.
This same question could be asked for IPv6 somehow.
(Laughter.)
>>PETER KOCH: Rat hole. Okay. Sorry.
It depends on the particular definition of end user, I guess.
There are interested parties which are talking about DNSsec and which are interested, which are playing around and which -- who sign their zones already and who would probably like to be able to have a signed delegation.
The question is whether they make up enough of a critical mass. And they do it without application support. So from that end, it's a myth.
>>JAAP AKKERHUIS: And Daniel wants to....
>>DANIEL KARRENBERG: Yeah, that's not only the chicken and egg trap, that's also the end user and security trap, because which end user wants security? None of them wants them, wants it, because it gets in the way. It gets in the way of doing things, especially if you're in a hurry or if you're not very familiar with the tools that you are using.
So it's really a -- a question with a lot of traps here.
I think that many corporate I.T. suppliers and some ISPs, especially, for instance, my particular ISP, would probably want to deploy this in their caching forwarders in order to provide more secure NAME SERVERS to their customers without getting in the way. And not forwarding them any answers that they can verify themselves.
So it's not really an end-user question, and it has the same problems, as Peter has pointed out, as new stuff, chicken and egg, and security stuff, does the end user want it, and the answer is no.
>>JAAP AKKERHUIS: Well, I thank you all for trying to unravel the myth or fact, and we're running really into the coffee break.
Steve.
>>STEVE CROCKER: Thank you. We're going to take a very short break. It's 10:15. Let's be back here at 10:22.
(Laughter.)
>>STEVE CROCKER: Seven minutes.

(break until 10:22.)




>>SAM WEILER: I believe we've exceeded our seven-minute coffee break. Steve Crocker, if you can hear me, we're resuming the session now.

Could I see just a quick show of hands, how many people in the room are from registries?
Good.
Do you know if they can hear me out there, Vint?

Welcome back, I'm Sam Weiler from SPARTA. I'm going to try to answer the questions are the tools ready to deploy DNSsec? As a registry operator in particular, can you do what you need to do technically?
Most of this talk is going to be about components registries he needs, some of it is going to be about end-host components.
There are two open-source name servers, authoritative NAME SERVERS, that fully implement the new dnssec specs.
Bind 9.3. Bind has implemented some version of dnssec for years. And NSD from NLnet labs. Both of these are complete implementations. We also have at least one commercial product that has DNSsec support.
The other things registries are likely to need to do deployment are tools. Things to build their sign zones and manage those signed zones. Therefore several projects underway generating components that you can give to your technical staff at the registry and say here, use this to build whatever we need. SPARTA has a suite of tools, some of which I'll show you. Ripe has a set of key maintenance tools. There's a PERL library about DNSsec from Olaf KOLKman at ripe that can be very useful in building things that will work within your business model, and there are some other random tools. JAKOB from SC has a smartcard utility for using private key stored on smartcards if you want to protect the private key material.
So I'm going to show you a Few of our tools. These are all open source, you can use pieces of them, you can contribute back to them. We have a zone visualization tool that's good for testing, zone signing tools, error checkers. We're working -- key maintenance is a little bit difficult. We have some very basic tools there. And all of these are components. You can use them to build your own stuff.
The zone visualization tool let's you see what's signed and what isn't signed, what's signed and what doesn't work. It's a quick check for here's what my signed hierarchy looks like. have I done the right things? You can get this; you can run it. It's fairly simple.
We have a zone signer tool. It automates many of the processes that you can do with, say, the zone signer that ships with bind, but might be a lot easier with an interface around it.
And just to summarize here, I think that there are enough components that you can go give to your technical staff to actually do DNSsec.
Most interestingly, we have really good specs. The three RFCs that came out this spring I think are very readable. The ISG was very fond of them.
I forgot one of my bullets up here is that we have a specification for EPP extensions for DNSsec which was just approved by the isg last week. It will be coming out as an RFC sometime soon. So that's also moderately mature.
Again, lots of pieces.
What about the end host? And first I'll answer the question why do we care about the end host? In particular, why do we care about pushing things all the way into the user's end system and the application rather than just a revolver at the ISP.
Part of that is that users may have different policies from their ISP. They may say I don't want this to be a hard failure. This is an important client e-mailing me. I want the e-mail to get through even if DNSsec fails.
They may even have different policies for applications. They may not care about whether their news feed, NNTP is authentic. They may care a lot more about software they're going to install. They may care even more about e-mail.
So, and what happens if you don't have the application policy? If you don't have the application policy, you can get this vague error message that doesn't let you do anything really helpful. It says oh, look, I failed. Sorry. Have a bad day.
If you did have application policy, you might be able to present the user with a choice. It failed; do you want to go on anyway? Much the way a web browser will do now with a bad SSL certificate.
We've heard from Bill Manning what people do when SSH reports a problem. It's not clear that exposing this choice to the user is so wise. But it would be nice to be able to do it.
So what do we have out there to do that? We do have one full DNSsec resolver in bind. I think there are more coming. There's more development work happening.
As for applications, our team at SPARTA has put together three application extensions. One is a patch for mta's to do validation of SPF records and other DNS lookups in mail transport agents. Another is an extension to the mail client to show those results. And then we have a web browser plug-in that also does validation. All this is built with the same libraries and tools that I talked about earlier.
You're looking at a bounced message, and you're seeing an error that came back from the mta saying that dnssec validation failed. So this is showing the sim mail and post fixed extension showing a DNSsec failure.
Again, this is mozilla Thunderbird. This is using an extension that shows this special header that was inserted by the MTA and it can show a successful validation or failed validation. This extension does work under windows as well. And we have a web browser plug-in. This says use DNSsec validation. Unfortunately, the only error message we're returning right now is the unfortunate kind that doesn't give you all that useful of an answer. It just says it failed.
Which brings me to the part which it would be remiss of me to leave out, which is what's missing? The first we alluded to in the panel which is what happens when validation fails? Right now, DNSsec aware software doesn't give you very much. The bind resolver doesn't give you very many options.
That needs to be fixed. We need to do more development there.
The easiest way to do that though is by exposing the details to the user. You've seen the application plug-ins that start to do that. We do need an API and we do need some more protocol elements, protocol elements for bringing validation results from the ISP's resolver back into the end host. Is that better? And an API for bringing those results from that resolver up into the application.
That API work is in progress. There's been one or two meetings about that already.
So that's ongoing.
Here is a page of resources. These slides are up on the ICANN Web site. If you want to go home, hand these to your techies. This points at the open source software and tools that I mentioned in this talk as well as, at the bottom of the page, a Web page that has bunches of other stuff on it.
Any questions?
Okay.
Steve, is the panel next?
>>STEVE CROCKER: The panel is next. And Bill is the moderator. Is bill back here? Here's bill.
>> It's loud.
>>STEVE CROCKER: I don't know what to do about it, either, because I can't go tell those people to be quiet.
All right, Bill -- is this live? So, Bill, speak up a little bit. Matt, speak up quite a bit, and Daniel your normal voice will be fine.
(Laughter.)
>>BILL MANNING: Okay. So I'm going to speak up a little bit because they're really loud over there.
The panel we were -- Steve, you're going to be up here; right?
>>STEVE CROCKER: Oh....
>>BILL MANNING: No? I was hoping you were going to be up here.
We're going to talk a little bit or go through the panel members, I'm hoping they will do this, try to go through some DNSsec deployment scenarios or activities. I'm hoping that each of them has about three or four slides that they can present. Right? Or you can wing it? You can wing it. Okay. And then take some questions from the audience as to whether or not you think these are reasonable kinds of things to proceed with or not.
So, hang on just a second.
I guess that is on. Okay.
So again, looking at sort of the puzzle motif, we're going to look at DNSsec as a maze of passages, all different, as opposed to a maze of passages, all the same.
We're going to look specifically at the authoritative and what I call the iterative mode resolvers, or some people call them caching NAME SERVERS.
And Vint, I think this will look at some of the things you were talking about earlier.
So if you look at TLD registries, and if they're ready, start looking at some of those numbers. They're at just about under 300 TLDs. Is that right? Somebody tell me if that's right. Is that right? Okay.
An ICANN staff member has given me the thumb's up.
And over the past couple of years since the Shanghai meeting of ICANN, we have had a -- oh, sorry about the cutoff there.
There have been at least 50 TLDs that have received in-depth DNSsec training. So we basically took invitation for TLDs to have their technical people come in and we sat them down and walked through the process of setting up a signed infrastructure doing key management, the whole nine yards.
How long ago was Shanghai, Vint? Steve?
>>STEVE CROCKER: 2003.
>>BILL MANNING: 2003? 2002. So it's been about three years. We're getting about 20 or so TLDs a year.
How long is it going to be before we get all TLDs educated as to the impact of DNSsec. All right? If it's just this small cadre of people, we're in trouble.
So these guys, we've had support from the ripe. Ripe has a training, an aggressive training program. ISOC has a pretty good training program. It's relatively aggressive. APNIC similar. LACNIC is doing the same.
There are some private people that are doing it. AXFR.net, ep.net, that's me. We go out there and do a lot of training but it's not enough. So for the DNSsec message to get out, we have to find better ways of -- and I'm going to pick on somebody here, we're going to have to find a way to get Kim Davies off of his butt and start training those TLD people; right? So the question I have for the audience is, since this is a panel thing, how do we reach the rest of these people?
Okay, I'll ask the panel. How do we reach the rest of these folks, panel?
>>DANIEL KARRENBERG: Well, there's nothing good unless you do it. It's a free translation of a German saying.
So I think you get those people by showing that it can be done and that it's useful. Not just by giving them a training course and telling them, hey, I really want to sell you this.
And so I think we need some significant deployment that actually shows it can be done; "B," gives people a bit more clear idea of the costs involved and the change to their business processes involved to do things, and, "C," shows some benefit.
And I think that's the only way -- my personal opinion, that's the only way how you get -- how you spread something. You show that it works, you show how it works, you show what it costs, and you show what it gets you. And that's what we're trying, at the RIPENCC, as I said earlier, and I can give some details about that, but I don't want to monopolize the floor right now.
>>BILL MANNING: You'll have your chance.
Geoff?
>>GEOFF HOUSTON: This is Geoff Houston.
>>BILL MANNING: Speak loud, Geoff.
>>GEOFF HOUSTON: I'll channel a bit of Dave Clark here from a presentation he did into the nsf community some years ago about quality of service.
If you adopt the model of technology adoption that you develop some cool technology and drop it by the side of the road and hope that the people passing by will realize the glorious attributes of this technology and naturally pick it up and deploy it, you might be successful, but you might not.
If you adopt the proposition that this is a business and a market and try and understand the motivations of the players, you would probably have a clearer vector of what you need to do.
All of these things imply cost. To do DNSsec is going to add to my costs if I'm in that realm as a provider.
Why would I take on those costs? Dave Clark mentioned two basic motivations: Fear and greed. Fear: My competitors are doing it. I will look backwards if I do not do it. I will do it because everyone else is doing it.
The herding instincts of any markets are undeniable, so one way is early adopters. Work with them, coach them, make them understand that there is basic advantage in doing this.
But on the other side there's greed. This is something I can gain additional revenue for. Dnssec signing might not be the same commodity as an unsigned domain. It might actually have greater value that might be translated into greater cost. There is a motivation there in terms of the service provider that I can recoup those costs through incremental revenue.
I feel that when we're looking at a lot of these technologies today, we have given the industry over the last decade an astonishingly large shock with the Internet. They're now reeling. This is an industry that used to invest money over 20, 30, 40 year life cycles and we're pushing them to invest at five year cycles or sooner.
The business cases involved need to be clearly shown to say that yes, you may well have done IP and you may tick that box, but it's not over yet. You actually do need to invest more, and the reason why has as much to do with incremental revenue as it does with trying to stay on top of the ball. Thank you.
>>BILL MANNING: So this is the KO punch. They're reeling; we're going to now knock them out.
>>GEOFF HOUSTON: This could be seen as the KO punch. I wish it wasn't. I wish it was seen more as a way to further strengthen your revenue base by effectively creating more surety at the user level, more value inside the entire industry.
>>BILL MANNING: Okay.
Can we take him first and then -- or go ahead.
>>DANIEL KARRENBERG: Actually, I'd like to agree violently with Geoff here. And actually, the value proposition in case of security stuff only comes after the fear. And unfortunately, it's morally impossible to increase the fear by just showing what can be done in practice.
>>BILL MANNING: Kim.
>>KIM DAVIES: I'm Kim Davies from CENTR.
I think that registries are not lazy.
It's just very expensive and hard for a majority of registries to think about deploying this kind of stuff.
And I think I'd actually like to really echo what Daniel's said, is that you really need the early adopters to show the way.
Certainly, observing the ccTLD industry, once you have one or two major providers that has those resources to experiment with this stuff to show it working operationally, very soon you will get other ccTLDs following the course, because there's a way demonstrates that they can do this kind of technology without the risk associated with making a mistake, wasting the time of one of the very few staff members that they have to throw at it.
You have registries of varying different sizes.
And I think the majority want to deploy DNSsec, see the value in it already, but just don't have the ability to tinker with it at this early stage.
So once it's deployed, once you see it in a few of the major zones, very quickly, you'll see the interest peaking within the entire TLD community to deploy it quickly.
>>BILL MANNING: Okay.
Thank you.
I'm going to hit my last bullet there and point out that for some TLDs, we'll pick on someone who's not here, the Swedish or .SE, SENIC, the Swedes have indicated that they expect to sign their zone and have it in a production-available space by the fourth quarter of this year.
Which then leads me to ask the question, are the Swedes teaching all of the people unregistered under .SE about DNSsec or are they expecting other people to do that?
So that's another question, is a training of people that are underneath you, your set of delegations.
Go ahead.
>> I'm Andrzej Bartosiewicz from Poland, from Polish registry.
You said that there is 20 registries per year taking courses.
But I think, for example, you were not participating in the courses, because we did the tests by ourselves.
So we had our infrastructure, et cetera, and we tested this technology.
So for us and for the remaining registries from Europe, as I know, the problem, is the zone walking.
So probably if the zone walking probably will be solved.
Many registries, like NASK, the Polish registry, will implement this.
And to be honest, we don't need any additional trainings or et cetera.
It's just the technology we can adopt.
So --
(Applause.)
>>BILL MANNING: Okay.
Jaap.
>>JAAP AKKERHUIS: Well, I'm not Swedish and not tall enough, either.
But what I understand from my Swedish colleagues is that one of the pushes of doing DNSsec apart from being -- having a more secure zone is also from the government's end, especially the banking system.
So to have more reliable economics or however it's called.
>>BILL MANNING: Okay.
>>PETER KOCH: Peter Koch.
I won't tell how Swede I am.
The point about education, I guess, is that there are commercial courses out there and they are available.
So what we, as a registry, could do is give some initiation to the -- to that education effort.
But it's probably a fine line between doing this and interfering with other people's and maybe even our members' business.
So we should be careful about that.
>>BILL MANNING: Okay.
We're going to look very briefly, some brief ideas here.
For the authoritative servers for the TLDs, there's something less than 300 of them.
But the authoritative servers for those TLDs, there's something in the neighborhood of about 450 or so.
And some of those will have code that needs to be updated or maintained.
Who's going to do that?
That's actually a tractable problem.
The intractable problem, or it appears to me, is that a caching or iteratives resolvers, those things that sit between the end system and the authoritative servers, we know that there's about 150 variants of code out there by empirical measurement.
There are over 300,000 of those machines in very brief snapshots.
We took some traces and said, "How many are there?"
YO, Daniel.
Okay.
We'll get to you in a minute.
All right.
So the instances that use those DNS servers for resolution needs, if those servers aren't up-to-date and able to handle DNSsec-capable code, what do we do, and they need it; right?
So that says that there's going to be some dynamic between the systems that want DNSsec validation from the authoritative servers and they've got systems in the middle that may not support that.
Tracking those down and doing upgrades across the board will take years is my particular point of view.
And then there is the trust anchors that go in these things, which is of some question.
Daniel.
>>DANIEL KARRENBERG: Yeah, but I think coming back to Geoff's contribution here, I don't think these caching servers will be a problem.
Yes, there are currently very many software -- versions of software in those things, and there are very many of them.
But at the time when fear is already present and some attacks happen and some ISPs can say, well, it couldn't have happened to you if you were a customer of mine, we have all the right incentive feedback loops.
So I think even the number of implementations isn't a problem, because there will be an incentive for ISPs to deploy the right -- to deploy secure ones, and there will be an incentive on software developers to actually implement.
So I don't think we should have fear from the diversity that is there at the moment and from the sheer numbers.
>>BILL MANNING: Thank you.
Steve, did you have something you wanted to say?
You better turn your mike on.
>>STEVE CROCKER: There we go.
I think the discussion about training is very interesting.
I like the idea very much that we could get into a situation where there would be people complaining that we're interfering with their business training, because then we know -- we don't have to keep seeding that.
But if we are short of training, we can certainly put some money into the training process.
And I think that the right time to do that is when enough pieces are in place so that the people who are being trained can walk out and say, "Good, now I understand it.
I will install the software tomorrow."
So the -- there is a little bit of staging that I think is -- still needs to be put in place for the software to become available, for the zone walking problem to be under control, and so all the pieces fit together.
So I think we're currently in an early adopter stage, shaking things down, and getting the operational experience and getting that experience documented.
And I think once we have a sort of front-to-back working system with enough pieces working and demonstrated and everybody using it on a daily basis, even though it may be a small number of players and a small number of resolvers, I think we're then rapidly -- that's sort of like the framework for a large building.
And then we can rapidly flesh that out.
That's the picture that I have.
So I'm looking forward to getting the root signed.
I'm looking forward to some lead TLDs.
I'm looking forward to resolving software becoming available.
And I'm looking forward to interesting experiences being reported of every sort, positive experiences and difficulties and so forth.
And then I know we're sort of launched and on our way.
>>BILL MANNING: Thank you.
That's my sort of take on the DNSsec experience as far as deployment is concerned.
I've asked MATT if he would spend a few minutes talking about some of the concerns and issues for large zones, for registries that have large zones.
I think VeriSign has maybe the second-largest zone in the world.
Maybe the first.
I don't know.
Number two trying to catch up.
Daniel has, as chief scientist, garbage collector for RIPE NCC, has some insight into the RIPE NCC's plans.
He has touched on those briefly.
I'd like to ask him to go into a little bit more depth about a RIR's perspective of DNSsec deployment.
And then, Steve, if you would touch on root signing, where we are with that and where you think -- what next steps might need to be taken, I think that would be great.
So four or five minutes each.
MATT, would you....
>>MATT LARSON: Sure.
Certainly from a dot com and dot net perspective, we're very concerned about DNSsec and what it does in terms of resources required.
Our initial calculations show that the size of the zone is going to increase by approximately three and a half to four times when the zone is signed.
And we've only just begun to research what's going to happen to bandwidth requirements with those -- once DNSsec is enabled.
So, you know, resources are definitely nontrivial when right now the combined number of names in dot com and dot net exceeds 40 million and is only growing.
To that end, some of you may be aware that we had proposed an extension to DNSsec called "opt in" that would have greatly eased the burden on TLD registries in large what I've called delegation-only zones, like TLDs have, that would make it a lot easier to deploy DNSsec because it would greatly reduce the number of pieces of information in the zone that would have to be signed.
Unfortunately, opt in didn't fly within the IETF community, and so we're back to being faced with some pretty serious expense and pretty serious resource requirements as a result of deploying DNSsec in COM and net.
All that being said, it's still technology that we're very interested in.
I think that's part of a registry's mission, is to follow technology closely and innovate where appropriate.
At the same time, you know, we're also a business, and we've done market research more than once on DNSsec and don't see a huge amount of market demand.
So there certainly is tension between the technical side of innovation and the business side of needing to be responsive to the market and to our customers.
And, you know, so the way forward is not completely clear as a result of that.
All that being said, we are interested in pursuing DNSsec implementation, because we think it's the right thing to do.
Because of the size and critical nature of dot com and dot net, we really don't think that we can start with either of those two zones.
We think it's probably more appropriate to get the software developed and the issues shaken out on one of the ccTLDs that we operate.
So we would hope that within 2006, we could see DNSsec deployed on one of the VeriSign ccTLDs that we operate, and that will allow us to understand the issues and deal with them on zones that are, you know, two or three orders of magnitude smaller than dot com and dot net.
I guess I would like to also take the opportunity to point out that even though the DNSsec standards are now finally available, they've finally by published as RFCs in the IETF, there still is a gap between the protocol definitions and what's required to actually deploy DNSsec operationally.
The IETF community is working on operational standards and getting consensus on what are operational best practices.
But I think from an ICANN perspective, I think it's going to be important that we have DNSsec implementation guidelines.
An example of this would be what happened in the IDN space, where, you know, we had the IDN standards developed and then it took some time for the community to come up with IDN implementation guidelines.
And in VeriSign's case, that meant some retooling and some additional effort to make our technology correspond with those implementation guidelines.
And, you know, we don't want to see that happen again from a DNSsec perspective.
So we'd like to not be so far ahead of the curve that we end up having to do additional engineering effort.
So I guess I would take this opportunity to call on the ICANN community to begin developing DNSsec implementation guidelines so that when registries are ready, they can know what's required to do DNSsec.
>>BILL MANNING: Okay.
Thank you.
Daniel.
>>DANIEL KARRENBERG: Well, again, in the vein of there will be nothing good in the world unless somebody actually does it, we at the RIPE NCC, as I already said, looked at tackling the reverse IN-ADDR zones that we are responsible for.
And since Bill challenged me to produce some slights, I have actually impromptu designed something.
So if you can put that up, please.
Oh, it's my problem.
Oh, I see.
I thought, actually, it would do that oh, okay.
Now, it hasn't seen the correct resolution.
Anyway, I will -- this is just a part of the RIPE NCC Web site. And the important thing you will see in the top is the URL there.
There is actually DNSsec deployment going on.
There are concrete plans discussed with our community.
And there is an implementation schedule.
And I will just jump to the bottom of this, which actually shows the implementation schedule.
And there are real dates there, and there are actually real dates that we think we can make.
And the bottom line of it is that we hope to be able to have all the reverse zones that we're solely responsible for, that we don't share with any other registry, offer DNSsec security-enabled delegations by the beginning of next year.
And we are also committed to publish all our experiences with doing that, much in the same vein as MATT has said, let's try this on a small thing first and then see what's involved.
It's the same idea that we're having here, try it on a somewhat larger thing than a small ccTLD, but still something manageable, and see what's involved, see where the gaps are, and publish our solutions to the gaps.
Just as an example.
And that's the whole intention here.
>>STEVE CROCKER: Let me break in and ask, how big a zone to you expect to bring in, how big an order of magnitude.
>>DANIEL KARRENBERG: A slash 8.
It's basically all the address space in a slash 8.
And how that translates into different delegation points depends on how the stuff is allocated.
But it's not small.
It's medium-sized, I'd say.
But you can just look at the registry allocation statistics and see what -- how many delegation points would be involved.
>>STEVE CROCKER: I assume you're talking about a slash 8 for IPv4.
>>DANIEL KARRENBERG: Yes, multiple for IPv4.
>>STEVE CROCKER: To translate that quickly into numbers, a slash 8 is 2 to the 24th or 4 million -- sorry, 16 million binary addresses.
>>DANIEL KARRENBERG: In the end, there's a possibility of 16 million, if you walk down the delegation tree, there's a possibility of 16 million individual reverse address -- reverse mapping entries.
But, of course, the address space is structured --
>>STEVE CROCKER: Right.
>>DANIEL KARRENBERG: -- into chunks, and the stuff that we own dealing with is delegations at the higher levels.
So I'm afraid I don't have the numbers in my head.
I would say medium-sized zones.
>>BILL MANNING: It's about 20,000 per slash 8.
>>DANIEL KARRENBERG: Yeah, on the order of I would say 10,000, 10,000 per delegations per zone.
And there's about a dozen of them that we'll do initially, I think.
Or more than a dozen, actually.
We are also -- much in the same vein as what matT has said, we haven't had all that much customer demand, but we think it's an important thing to do.
And that's also why we have quite actively supported the IETF's efforts in finally getting workable standards out by actually making people available to facilitate that process, shall we say.
>>BILL MANNING: Thank you, Daniel.
Steve, do you want to touch briefly on the root zone signing.
>>STEVE CROCKER: I will.
But I want to continue this piece for just a second.
I think it's interesting to keep track of the sizes of the zones that are signed during this early adoption phase, and, equally, to keep track of the number of entries within the zone, the delegations that are -- that have keys in them.
So there's two elements there.
One is whether the zone itself is signed; and, of course, each of the entries in it.
And then the other is whether the children have passed up keys.
So that means how many children are signed zones as well.
An idea that's been percolating in the back of my mind and is sort of brought to the fore from these presentations is to try to make some of that more visible.
And I'm sort of curious what the reaction would be around the room or on the table in terms of setting up sort of categories, 10,000 size zone, 100,000 size zone, the first million-sized zone that's signed and so forth, as a way of shining a light and measuring progress across the -- you look like you have something to say.
>>BILL MANNING: Well, we could set up class A, B, and C stuff again, if you'd like.
(Laughter.)
>>BILL MANNING: It would be interesting to see that.
I think that getting visibility into smaller zones in the sub-hundred entries is going to be difficult, because, I don't know -- anybody out in the audience signed a zone ever?
The size of the zone you signed, is it more than a thousand?
More than a hundred?
For the ones that have more than a thousand, you can keep your hands up.
More than ten?
All right, okay, so there you go, Steve.
It's a quick straw poll.
>>STEVE CROCKER: I think things get to be interesting up in the above a thousand into the ten thousand-plus range, frankly.
>>JAAP AKKERHUIS: For a production-like test, we used 800,000.
So....
>>STEVE CROCKER: So we should drop the threshold for the top one down below a million just a tad.
Right?
Three quarters of a million. And then you can --
>>JAAP AKKERHUIS: That's all we had available at that time. And we did it just for testing 1.5 million not that long ago just to see if all the stuff still worked.
But not in production environment.
>>BILL MANNING: Steve, if you do that, you're going to lose all of the RIRs except for their V6 delegations.
>>STEVE CROCKER: What do you mean by "lose"?
>>BILL MANNING: If it's 800,000 for above or 750,000 for a slash 8 delegation, you're going to get in the thousands, in the tens of thousands.
All right?
>>STEVE CROCKER: So -- well, so this is a public relations issue as to whether you want to structure the competition in a way that makes the RIRs candidates for the gold star or whether they're restricted to sort of silver-star status or something like that; right?
So Bill is quite obviously needling me here to say something about getting the root signed.
And after this was scheduled a Q and A session and closing.
And we're already ten minutes over.
So I'm going to try to wrap all of those into one thing, if you don't mind, Bill, and take this as the last item for our entire session and go out with a flash of glory here.
So what is there to say about getting the root signed?
It's both easy and hard.
It's easy because the root is a very small zone.
And it should be pretty straightforward to do it.
It's hard for at least two reasons.
One is, because it's the root, there is no parent, and so the key that's used to sign it needs to be distributed through some other process, and so the whole distribution process for the key is special of necessity.
It's possible to view that as part of how you distribute the keys for the tops of other disconnected trust entry points, secure entry points.
So you can imagine a family of trust anchors of which there will always be at least one, which is the root, and then there will be more or less depending upon how connected or disconnected the tree is.
And then there's also the rollover problem.
And then, of course, the one that is attracting a lot of political attention is who holds the key and what are the processes that are used for managing that key and storing it and so forth.
I don't think that we're in a position to give a completely concrete answer right here right now.
It's getting a lot of attention.
It's bound up somewhat, but not quite tightly, with what's the process for signing the zone.
That is, you can't do anything with the key all by itself; you've got to have a process in place for signing the zone.
But the key itself and the generation of it and the promulgation of it can be done independently.
So there's sort of two interwoven tracks there. Getting the signing process in place inside of IANA and the other is getting a key generation and key distribution process that of course involves IANA but also involves the external processes.
We're going to write down candidate processes and procedures and the competing points of view that involve multiple keys and split key storage and all the various other things, and try to get this laid out in a visible and cleanly documented way.
I have in mind getting rid of two things. One is a lot of the hyperbolic rhetoric about all of the far-out kinds of things that can go wrong, and the other is to get rid of the process of endlessly revisiting the same subject over and over again.
So over the next few weeks, I intend to be pretty forceful about trying to draw those pieces of the dialogue together. And I'm not sure I have a date certain for having all that in place, but things have been slowed down a little bit over the summer, partly with this meeting, partly with vacations, and I can tell you at least on my schedule, getting this nailed down is an extremely high priority. And then we will know what we're going to be....
In a few weeks, not very many, the IETF comes up. I suspect some of the key players will be there. As I say, there's not enough material in hand to make a specific commitment, but this is something that we clearly are going to have to nail down and make go forward.
>>BILL MANNING: Thank you. I think that that -- for me, that clarified a lot of the sort of nebulous concerns. You laid out the high points of what needs to happen for the next steps to occur. So that's good stuff.
>>STEVE CROCKER: Thank you. Anytime that I can increase your comfort level makes my day, for sure.
Let me hijack the session from you, Bill, unless there's a place you want to drive it right now, and in the interest -- you know, watching the clock that we're over time here, ask if there are any general questions or hot topics that we should have pursued or comments that you're motivated to make.
Barbara.
>>barbara fraser: I just want to push a little bit on your response as far as signing the root zone. And -- or the root.
Can you elaborate on what will influence the time in which you hope to get this accomplished? You said -- I know you don't want to say okay, I promised to have this signed in one month, but the open-ended a answer that you gave is very similar to sort of the open-ended answer that I think I've heard for the last umpteen years. So is there nor specificity you can elaborate on or is it only something you can carry out behind closed doors.
>>STEVE CROCKER: umpteen years is too long. It will be less than umpteen years.
There are -- I'm going to revisit what I said before but I'm going to try to sharpen it somewhat.
There are two things that have to happen intertwined. They're partly in parallel. One is there has to be the machinery in place inside of IANA and also involving the whole process of publishing the root zone out through the root servers so that you can -- if you had a key, you would be able to sign the root zone and you'd have a process for doing that. And if you break that process down, there is the signing of the root zone entries. That's one part. There's the publication of that out through the root zone servers. And although that doesn't seem like it's a big deal, the root zone servers obviously have to be ready to serve up signed entries, so that's a distinguishable second part. And a third part of the equation is it's all very nice to sign the root zone but it would also be very nice if you can sign the keys coming from the Top-Level Domains TLDs and so there has to be a process for taking in the keys from the children that is the Top-Level Domains and signing !
that.
So if you break down the -- what I'll call the inner interior process, there's the -- just to review, there's the process of signing, the process of publishing, and the process of taking in public keys from the children and folding those into the signed root zone. You can imagine taking in the public keys from the children, but if you don't have any way of signing the root zone, it doesn't do you any good. so there is a natural order there.
So all of that is sort of one large thread, and where we are on that is that there is specification and candidate software development in process on the IANA side. There is discussions within the root server community on getting the root server systems ready. There are 12 different operating organizations for the 13 different root servers. They are not all in uniform state, but many of them are pretty far advanced and the rest are watching closely. That's the optimistic view. And the pessimistic view is nothing happens until the last guy is ready. And what will be interesting is when most of them are ready and the last couple are lagging and then that will become a big focus.
And coming back around to the other thread that Bill was pushing on is, okay, we also then have to generate a key and have a process for managing that key and perhaps for doing rollovers and so forth. And as I said, within the next several weeks, at most, I want to get the elements of that laid out very clearly and see whether or not there is any irreconcilable differences among the community or a sensed voice to move forward.
The target that we have had, and I will use "target" as opposed to something fervent, is to actually have that all up in running, signed root zone operational, by the end of the year.
Now, that target was established well over a year ago, and when it seemed like we had lots of time and we could make that happen. Now we're in the second half of 2005 and there's no mystery that that now looks like it's looming faster and faster and will be tougher to achieve. So it's not within my power to make it happen by myself, so it wouldn't do any good, but time frame in that area; that is, as we move toward 2006 and particularly if we move into 2006, I think the pressure to have the root signed is going to increase very substantially and we're going to start measuring time in weeks, preferably not even months. Because -- not that that's the only way to do things. You could have a lot of the other parts of the -- a lot of other zones signed and you could have trust anchor points and so forth, but if the root is signed, then a lot of things become a great deal easier and that becomes the preferable path for the entire community.
>>DANIEL KARRENBERG: One additional thing, since this is an ICANN meeting, and you have said quite rightly that no one entity can make this all happen and this is just signing the root zone, I think ICANN should look very closely at the processes within IANA and at their subcontractors, VeriSign or whatever, the people actually doing that, to see that they are ready to actually do the things. This might sound trivial but my personal impression from some of the hiccups we had actually with root zone maintenance at the IANA side doesn't give me that much confidence that this won't be the last thing in the Gann chart where everything just depends on blocks on.
So since this venue with ICANN, I should say strongly that ICANN should pay attention and should make sure that they're -- what's their job, that they can do their job, basically.
>>SAM WEILER: I want to actually follow-up on what Daniel just stated. At the cape town meeting last December, the IANA manager told us that IANA would be -- he expected IANA to be ready to sign the root when the root operators were ready to take it, which he expected to be by the end of this year.
Have you heard any signs from IANA that they will not be able to meet that commitment, Steve?
>>STEVE CROCKER: No. There's certainly no -- no statement to that effect at all. At best, I'm trying to paint as accurate a picture as I have from observing rather than reporting on behalf of IANA or any formal statements. Equally, the root server operators have suggested in informal polls that they would be ready in time frames that were -- I think the quote was the last half of 2005. So the last half of 2005 has now started and it will end in less than six months.
So we're in kind of a classic horse race to see who has the slowest horse.
So with that, let me thank everybody for coming. I hope this has been useful. This is part of a series of workshops and presentations on DNS security. Our announced intention and plan is to have a comparable kind of workshop with a greater focus on the registrar part of the process at the Vancouver meeting.
We are extremely interested in feedback, positive or negative or constructive, as detailed or as general as you like. The whole purpose of this is -- two purposes. One is to inform and the other is to engage in a constructive process to move the deployment process forward.
So thank you very much. I appreciate everybody coming and being a very active and attentive crowd.
Thank you
(Applause.)