DNSsec Workshop Cairo, Egypt 05 November 2008 >> Ladies and gentlemen, we'd like to introduce chair, ICANN Security and Stability Advisory Committee and member of the board, Steve Crocker. >>STEVE CROCKER: Thank you very much. We have -- the last time that we had a session like this, we had a relatively small room and it was packed, so I made a point of asking for a larger room, not expecting that we would have a vast cavernous room like this, and my expectation is that there will be people drifting in shortly, so we'll take a second to get started. We have a quite substantial, very dense program, multiple key things that we're going to talk about today, but I don't see our first speaker here, so I need to just sort of tap dance until we get organized. In fact, where are all the speakers? I see one, two, three... Ah. Good, good, good. Let's see. We need a couple more, and then we're ready to roll. All right. Anybody know where Ms. Alexander is? >> Fiona? >>STEVE CROCKER: Yeah. Would you? That would be great. And does this -- sorry while we get -- there we go. Good. >> (Speaker is off microphone). >>STEVE CROCKER: Ta-da, ta-da, ta-da. All right. We've had the benefit of a lot of attention on DNSsec over the past few months, triggered, in part, by Kaminsky's great work at discovering that DNS was even more vulnerable than previously experienced. Also have had significant actions. The U.S. government has made a formal decision that dot gov is to be signed within the next couple months at its top level and that the subordinate zones below it will have to be signed over the course of 2009. And there's a notice of inquiry on DNSsec at the root level, which will consume the first part of our program. There's been action on top-level domains, on services and products, a survey of devices that are at the end users' premises, and recursive resolvers are now starting to become DNSsec compliant and available for public use. We'll cover all of these things, and I think there will be time for a limited amount of questions during the program as we go along, but I'm going to control the pace to make sure that we don't short-change the speakers later on in the program. We're starting with a focus of attention on the root signing, and -- but that does not mean that's the only interesting thing in the program, so I strongly commend that you stay all the way through. I think the work of the ccTLDs and other top-level domain operators and the product announcements and the survey work on firewalls, each is pretty interesting stuff. Where are we... Ms. Alexander is associate administrator of the Department of Commerce's NTIA. That's the agency that oversees ICANN and has responsibility for overseeing the root update process, and I know she's got a super packed schedule so we've tried to fit this in so that it all comes out well, and there she is. Great. So our agenda today, which I hope you've got copies of, we're going to have this discussion on the root signing. Fiona Alexander will start. And come on up whenever you're ready and I'll -- we should be ready for you, Fiona. Pat Kane and Rick Lamb from VeriSign and ICANN respectively will talk about the two proposals that are -- have been submitted and are publicly available. We'll have discussions from Daniel Kalchev, from Demi Getschko, from Ondrej Filip and from Lance Wolak on Bulgaria, Brazil, Czech Republic, and the dot org registries, respectively. And then we'll close with a discussion about resolvers and routers. Wait a minute. Something's missing here. Well, I'm going to find out the hard way where that slide went to that has the list of things. Ah! So a slide out of order. Uma Murali from Names Beyond, Shyam Seshadri -- I'm sorry, I'll get it right -- from Microsoft with a blockbuster announcement they made last week, and then I'll come back with a few words appliances on recursive resolvers. So with that, let me turn the stage over to Fiona Alexander, without further delay. And you don't have any slides, so it's just the stage is yours. >>FIONA ALEXANDER: Thank you. And sorry, I actually went to the other room. I didn't realize the room had changed, and it was quite -- no, there's a sign, but at any rate, my mistake. >>STEVE CROCKER: Sorry. >>FIONA ALEXANDER: Quite a large room, actually, so I will be very, very brief, so you guys can have a more fulsome discussion on the issues that you want to talk about. But I wanted to thank Steve and everyone for inviting us to sort of at least make -- for those of you that don't know -- aware of what we've been doing and encourage you to participate. So obviously a lot has been happening in the DNSsec space for quite a long time. I look around the room and you all are the people that have been doing the stuff for quite a long time. We have received, in the last few months, a proposal from ICANN and a proposal from VeriSign, several letters from some of you in the audience encouraging us to sort of figure out how to move forward. We've been working for a long time with NIST, our sister agency in commerce, other USG agencies, in figuring out what to do and what not to do, how best to do things. And given what this would mean and could be one of the most significant changes to the architecture, we thought the best way to do it was to -- Am I speaking too fast to you? Yes. I do speak really fast. Sorry. We thought one of the best things -- or the best thing that we could do is to put this out for public comment, so that everybody could sort of weigh in on their perspectives, and we issued a notice of inquiry, which is the sort of rule-making process that we use in the U.S. government. I encourage everyone to participate. The NOI was published -- I should know this by heart, actually -- early October. Comments are due November 24th. The NOI sort of basically lays out the issues as we understand them, and then asks a series of specific questions and proposes six potential implementation models about how to sign the root. So we are sort of agnostic. We haven't taken a position on what's best, what's good, what's wrong. We encourage you all to do that. We say, "These are the models based on some of the proposals we have received, and some of the other ones we've discussed internally with the U.S. government. What's your opinion on these models? What's your opinion on other models? Are there other ways to do it?" And we also sort of say, "DNSsec -- once we figure out how to sign the root and that gets done, that's only the beginning." So full deployment of DNSsec is going to take a lot of people, a lot of actors, all through this DNS hierarchy, and one of the reasons we ask some of these questions is to make other people aware and make sure that they're wanting to move forward as well. I think one of our concerns is that once we figure out how to sign the root and that's done, that everyone says, "Great! The Internet is safe and secure!" And that's only the beginning and there's a lot more work to do. So part of the reason we did the NOI was also a little bit of awareness-raising in that regard. I know, I speak really fast. All the interpreters hate me. But I think that's just sort of just briefly where we are. The document is on our Web site, ntia.doc.gov, if you haven't already seen it. I think so far, we've got 10 or 12 comments. Comments tend to sort of slam in at the last week or so, so we encourage you to be very thoughtful in your response. If you have questions, please give us a call. We're always available for that. I would also say to this group in particular, and the people involved in this space: You guys have, again, been doing this for a long time and we really look to you as the experts. If there's other issues you think we should know about or be aware of, or just think we're not doing the right thing, please call us. We're always here. So... >>STEVE CROCKER: Is there access over there? Pat Kane from VeriSign will talk about the proposal that VeriSign has submitted, and possibly some related matters. Do you need that? Your slides are -- >>PAT KANE: No, they've got my slides. >>STEVE CROCKER: They've got your slides and here's the mechanism for -- >>PAT KANE: Great. >>STEVE CROCKER: And you'll see them on there. >>PAT KANE: Fantastic. >>STEVE CROCKER: Okay. Good. >>PAT KANE: Thank you, Steve. As Steve said, I'm Pat Kane, with VeriSign. I run the naming business, responsible for com and net as well as some other TLDs that we operate. The first thing I want to do is I want to acknowledge -- that sounds really loud -- I want to acknowledge Ken Silva, our chief security officer and chief technical officer and Matt Larson as the authors of this specific proposal. So to that, I hope not to slaughter it while I'm presenting it. So when it was put together, one of the things that we wanted to be able to do was to recognize that the objective is to sign the root zone as quickly and as practically as possible, such that each TLD operator could be determinate on signing their own zone and creating chains of trust. So to do that, we ran through some very basic thoughts around the proposal and what it should look like. From a time perspective, we thought the best thing to do would be be able to, first of all, preserve the existing roles and responsibilities within the process today. There are three people that roll through the process today: ICANN, the Department of Commerce and VeriSign. And we thought that from a practicality standpoint and a speed standpoint, that that should remain the way that it is today. We also believe that the responsibility for the root zone key signing key should be split or shared across multiple entities. We also believed that whoever is maintaining the zone or creating the zone should also stay in that role, and actually sign the root zone as well. We believed we should continue to use the existing processes because they are proven. The players in the area all know how to work with each other. We know all the players as well. And we should continue that, moving forward. And the lion's share of the time spent between now and rolling out to production should be spent on doing significant testing. So from the standpoint of preserving the existing roles, as I laid out, no changes will be made. IANA would still receive the requests from the TLD operators. They would accept them. They would check them. And they would move them on for approval from the oversight body, which would be the Department of Commerce, NTIA specifically, and then those would be approved and sent to VeriSign for signing in the root and creating the root zone and pushing that out to the root zone operators. Each role really would be maintained the same way they do today and would be reflective of each organization's skill sets and current organizational capabilities. So when we talk about shared responsibility for the root zone or root zone KSK or a split responsibility for that, it really should have multiple organizations that are responsible for that. We believe that there's a valid currently-in-use authorization technique today called M-of-N which could be are used very successfully, where "N" is the number of people who are able to authorize the use of a key and "M" would be the minimum number of people that would need to use it to actually use that key. So the question comes up if a key were to be split or be shared across multiple organizations, who would be appropriate for -- to participate in that ceremony? We believe that those should be the existing root zone operators today. Largely because they're already trusted by Internet today, and to serve up content within the root zone. They already have established track records of performance and skills and capabilities. There are varied organizations. They are located internationally. They are academic. They're noncommercial. There are commercial entities as well that all participate in this. So there's a varied number of people and organization backgrounds that would be able to participate in that process. And last, and I think one of the best reasons, is they're neutral and they have no stake in the contents of what's in that root zone. And lastly, you would need a qualified third party to be able to hold onto the KSK, and we believe that that should be VeriSign today, from the standpoint of moving forward with speed and accuracy, in that today VeriSign has those skills. We've been in this business for a long time, and it's one of our core businesses. And so we have a skill set here that the others that if we were to maintain the same roles and same responsibilities, that comparatively we have more experience than the others. So VeriSign to sign the root zone -- oops. So like I said, VeriSign would sign the root zone. Appropriate organization, and it would be complicated and require extra protections but one of the things we believe this would do from the standpoint of how this would happen with the signing is that the root zone operators would actually come to a VeriSign site in Mountain View and share that process and actually all would participate, at least a minimum of "M" would participate in signing the key and then carry those keys with them. So it's an important function and must be treated accordingly. We do have the appropriate facilities. We've been doing this, like I said, for many years. We have a primary site in Mountain View, plus two disaster recovery key signing -- key ceremony rooms that these ceremonies could participate in, and VeriSign would be happy and willing to move forward with that process as well. So again, significant testing should take place, and this should be where the lion's share of the work is required. We can't just sign the root and hope for the best. It has to have participation. The test beds that are currently in place today, not just the VeriSign test bed but the ones that are operated by ICANN as well, should also be used as part of participation from different players, so that we can get to a signed root zone and permit the registries and the TLD operators that want to be DNSsec enabled to do that as quickly and as practically as possible. Thank you. So that's the root zone proposal. One thing that -- this is the proposed architecture that the white paper or the proposal itself walks through very well, so I would encourage you to take -- to download that and read through that. But I do believe we have copies as well that we can distribute later today. So if there's questions on that, I can take some of those questions now. Steve, is that appropriate? >>STEVE CROCKER: Yes, we have some time. I think what would be helpful is to take maybe a couple of questions now, if people have them, but then to also open up questions after Rick has talked on questions that might apply to both your talk and his talk. >>PAT KANE: Okay. >>STEVE CROCKER: And perhaps Fiona's as well. Are there any questions that people want to ask specifically about -- to Pat about the VeriSign work? I've got one. As you might imagine, I read the proposal, and one of the things that caught my attention was actually not in the proposal itself but was in the cover letter. There was some mention about com and net. Would you want to comment about that? >>PAT KANE: Yes. And I was going to comment on com and net after -- after there were any questions. And if there's not, I'll go right to that. The. >>STEVE CROCKER: Ah. Okay. >>PAT KANE: But one of the things that we've talked about with com and with net specifically is that when we got to dot com, we wanted to make certain that the size of whatever we sign is the last possible thing that we have to learn from. The challenge with com is that there are a tremendous number of registrations in that, and so any approach that we took, we would want it to be able to move forward with a TLD or a registry that was smaller. So one of the things that we're in process with today is that we're working with EDUCAUSE to present to the Department of Commerce a proposal to actually DNSsec-enable dot edu, and so that will be our first step in that process, because since we provide registry operations and services to EDUCAUSE, we thought -- and they ride on a very similar platform to what dot com and dot net do today, that that would be our first step moving forward. And then since NSEC3, of course, has come out and we have the opt-in capability, that is what we would apply to dot com over time. What the time frame looks like for that, Steve, we've not laid out a specific one, but that is our first step to follow on with dot net and then with dot com as well. We believe that it's probably 24 months before that process culminates, but that's just an estimate based upon, you know, not knowing what we're going to discover through the edu process. >>STEVE CROCKER: Very interesting. Thank you. Any other questions? Let's see. We have a protocol for questions. We have people with microphones and numbers, but no takers at the moment, which is fine, actually. I suspect things will heat up in a bit. Good. It's a feature of the size of the room that that diagram which is pretty -- should be easy to read is too far away, I think, to make out all the pieces. Are there any specific elements of that that we ought to focus on? >>PAT KANE: Well, I mean, I think what it does is it preserves the process today and shows that the root operators would be a large part of the process in terms of the use of the key, and that that would happen at a minimum every month. >> We have a question here in the center of the room. >>STEVE CROCKER: Thank you. >>MARK LUKER: Hi. I'm Mark Luker of EDUCAUSE. We're very interesting in helping to move the DNSsec process forward and look forward to demonstrating some leadership here. I want to emphasize to everyone, though, that we're operating this domain under a contract with the Department of Commerce in the United States, so any agreement or decision to move forward would need review and approval by the Department of Commerce. >>PAT KANE: Thank you, Mark. >>STEVE CROCKER: Okay. We have another question in the back here. >>ELMAR KNIPP: Elmar Knipp from CORE. Let's assume that community wants to have your solution. How long does it need that you can switch it on? >>PAT KANE: How long until we can switch it on? Well, I think that's a determinate of the testing process. What that time frame looks like would have to be discussed with everyone that's involved in the process, which would be -- include ICANN and the Department of Commerce, so I don't have an answer for you at this time. >>STEVE CROCKER: Got to get used to this. >>PAT KANE: Thanks, Steve. >>STEVE CROCKER: Thank you very much. All right. With that, let me ask Rick to come up. We have Rick Lamb from ICANN talking about the proposal that ICANN has submitted for signing the root. >>RICK LAMB: Well, hello, I am the DNSsec program manager at ICANN, and so I've spent a lot of time working on DNSsec and it's been my life 24 hours a day. So the ICANN proposal -- I'll just go to the first page. Oh, do I push this? All right. Okay. First of all, just a quick description of DNSsec. I'm sure everyone in here knows everything about it, but it protects the lookup just like SSL, HTTP protects the conversation. It is about security and not control, and you'll hear that in my presentation. It's not a change of control. It doesn't affect existing applications. There's no encryption. And if you know about PKIs, public key infrastructure, it's that for DNS. And if it's secured and trusted, particularly at the root and through the chain of trust that's developed through the root, it can be a platform for innovation. Many have come up to me and talked about that. Next slide. I don't expect -- thank you. I don't expect anyone to read through all this. This is really just for reference, but there were a number of recent events that led up to this. Some of them are, of course, calls from the community to get the root signed -- many calls from the community -- as well as dot se Sweden signing. Real trailblazing work by them, and you'll find that they lead the way in many of these efforts. Brazil, Bulgaria, Puerto Rico, Czechoslovakia, dot museum, dot gov as Steve said, dot org, dot ca, dot uk, they're all about to come online. So we can go through this process and go through these. I won't go through each one of these things. But, you know, Dan Kaminsky's attack, that certainly did add some urgency to the whole effort as well, and has kick-started a lot of this stuff. And then thank you very much to NTIA for doing the notice of inquiry, because this now really brings the point home. All right. A quick overview of ICANN's root signing proposal. There's no change in current control, so there's no administrative change in any of the current control of the content, okay? Approvals, just as my colleague Pat said, the whole mechanism of approvals and everything stays in place. Our proposal accepts no compromise of security. We have no constraints. We are just looking for the most secure solution we can come up with. The other key aspect is designed by the community for the community. In our efforts in designing our test bed and our test signed root that's been available for over a year, it's the community that helped us design this. It's the community that pushed us toward T there are a number of experts in that community. Sweden, of course, being one of them. Dot UK or Nominet the other. And as well as many others, security personnel. No one organization holds the -- or controls the key. That is a given. That's at least our goal. We are community-driven so if the community says otherwise, we just do what they ask. We are community driven so if the community says otherwise, we just do what they ask. Let's see. Regular auditing, reporting, of course. Timely deployment, that means don't get it done right away, get it done right. That means plenty of testing but still, you know, building on the signed root that we already have deployed, building on experience that's out there, the experience inside and out. Of course, automation is something that we've learned over the past couple years, something that is very critical and important to DNSsec. Flexible, it's got to be a flexible design, there is an evolving landscape both technically as we get lessons learned with DNSsec deployment and with policy. And, of course, it is all Open Source. Let's see. All right. Here is just a list of some of the important elements of root signing. We believe that there should be complete transparency in this, broad stakeholder participation, it has got to be flexible, reliable and trusted above all. The solution that results in this has to be something that is maximally secure -- balancing various concerns, of course, in the community but also it's got to be maximally secure. And it's got to be the trust that DNSsec promises to bear so that people can use it. And then this last bullet is on the flexibility of it's got to be a continual process. This is not a design-once-and-then-go-away thing. This is something that is changing. There has got to be a continual process where there is international participation in both the management as well as the operations and any changes to the DNSsec deployment at the root. Okay. Trust -- as I said in the beginning, trust and security are the focus of the ICANN proposal. One of the main things here is to understand that each -- in DNSsec, since it is a public key infrastructure, each level in the domain name forms a link, is a key pair where security is the key aspect. So what's created here is a chain of trust. And if you think of the root as being one of those links in the chain of trust, many things tie to the root. All the TLDs tie to the root. That root link, therefore, has a lot of pressure on it and has to be scrutinized very carefully. Again, if it is done right, it will be a platform innovation. One of the things people told me DKIM for anti-spam efforts as well as SSAs, some security there, as well as other aspects I have heard people talk about how actually SSL certificates for Web sites sometimes use as a key part of their vetting process the DNS. And, boy, that's a scary loop there. So, you know, we definitely want the DNS strong and done properly there. Next component, of course, is trust in the root key. This was explained a little bit by my colleague as well. There is -- anyone can generate a key and sign a root zone. This is just software, all right? So it is really trust in that key that is important. So the resultant signed root, it will have no value if someone just decides to set up another test bed and generate a key. It is trust in that key, and it is trust in how that key is generated. This is one of the key aspects of looking to the community to design this process, the process designed by the community, for the community. It is something people can all trust in. I see this as a classic Internet play. The Internet is cooperative by definition. You get various players on different sides trying to achieve the same goal, and they have to come together to do this. So, therefore, the ICANN proposal looks to broad stakeholder participation in the key ceremony. This would be something where the keys are generated, and the process and procedures for that generation are in place. What's very important in that process is the publication and attestation to the processes and procedures. So, of course, this all done with a certain amount of balance and stability and security. I mean, one example, of course, would be if for every signing of the root zone that happened every day you required all fifty hundred members to be there to show their keys or show their badges, this is something that would affect stability. That's an extreme example. You can see there are various combinations of that. All right. This is an overview of the -- general overview of the design of the ICANN proposed root signing. It may be kind of hard to see there, but the general idea again is to preserve trust from TLD operator to signed root. This is a key component here. IANA as part of its IANA functions has established trust relationships with many of these TLD operators. This is not just technical checks. There is human involvement there. There is face time, meatspace some people may call it. There is a careful vetting process that goes on there to make sure that what is being given is, in fact, right and is intended. The ICANN proposal intends to be preserving in that trust and security and accountability from the TLD operator to the signed root. And once the root is signed at the outside of the gray box right before the yellow box, it actually can be -- the root zone at that point is completely protected. That file cannot be modified. This is what's called a digital signature. Once it is signed, it is safe. The idea is to keep that at least not necessarily all controlled by one organization but within one organization you can see the green box is there, specifically that the keys themselves would not be controlled by IANA, they would be controlled by other -- by this key ceremony, by multiple participants. But physically in order to achieve maximum security, these devices would be co-located in a facility that did not require transference of data. Move this along a little bit. All right. ICANN's capabilities, we have sophisticated "L" root operations. There are 13 root zones out there -- root zone servers out there. The "L" root operations are run by ICANN, and they're pretty fancy and very secure facilities, 48 machines per instance. Anyway, we have comprehensive registry failover processes and procedures that we've developed. Root zone management is our business, so it is key to our existence. DNSsec is part of our strategic plan and budget. So all of our DNSsec efforts have been very well funded. Thank you. And signed -- we've had a signed dot arpa and root system that we worked closely with DNSsec experts to develop and deploy. It has been in public testing since June 2007. The interim trust anchor repository -- I will touch on at the end of the talk -- it is something we have had in place that's about to be released for TLDs. This takes some of that TLD information and offers it in another format those wishing to experiment with the DNSsec at the root. We also have some skilled staff. But in particular, we have even some people that actually have worked on other signed roots, Puerto Rico. We have a gentleman named David Soltero which works there and he is the developer for dot pr. All right. Preparedness. Again, I apologize for, a big room like this, for some of the small font there. IANA's signed root was designed closely with DNSsec experts. It is based on Sweden's deployment. It is a very similar design, same sort of key rollover mechanisms. It is publicly available for well over a year. We continue to collaborate and develop on other efforts including signing dot arpa, which was another request that was made from another organization. So that's ongoing. The crypto we have written software in house that deals with crypto interfaces so we have become very familiar with some of these fancy crypto boxes that store the keys. A very key component of this whole DNSsec thing because once that public half of the key is published, it becomes very valuable. Now it becomes extremely important that the private half of that key is protected at all costs. This is very -- a focus of our efforts. We've given that back as Open Source, of course. Some of the work on that. Let's see. We deploy only these FIPS140, level 4, this is the highest level device. They are used by U.N. treaty organizations. We have many of them, but they were purchased in our being deployed -- have been deployed on our test signed root. And one of the differences between this and any other HSM is that in this one if you touch it or tamper with it, it just destroys everything inside it. So it is pretty formidable. Let's see. We've developed various sample key ceremonies and other key management approaches because we know this is a critical component. You know, I can go through some of those. But there's a part of the key ceremony, of course, is to get everyone involved and everyone to participate in the process. But it is also -- you also have to look at the whole picture here. You definitely would have backup sites as well, and so it may not have been crystal clear in the published proposal. But the backup sites would -- could also be a check on the system. So if there is, you know -- those that have concerns about key control and how this is distributed, backup sites by definition have to be able to act fully as signers of the root zone and be able to published. So they could be, in fact, be chosen by the community as other entities, other organizations or a combination of organizations, should that be deemed proper by the community. So there is a fair amount of checks and balances on the system here. Current operations are in secure facilities. Multiple biometrics, secure containers, list goes on. But the main point here is ICANN is here to serve the community. We are not in a position -- or it is not our place to tell the community how to design this or how to do this, not only does it take away from the trust in the system but it is just not our place. So we look to the community to tell us what to do. Part of a -- a key part of our proposal is a public consultation with DNSsec experts that are out there and this would be something that we would look forward to. We even call out in that list of experts, of course, VeriSign, NIST, which is the U.S. government standards organization as well as many others. So that's -- we look to the community to tell us what to do and it is your root. We'd like you guys to design it, your root signing system. Quick, just a little picture just to show what we have sitting behind our test bed. That's a busy little picture you can look at at your leisure. You can see there is a safe there. It is a NSA, top-secret certified, DSA Class 5 safe. That's where all the equipment is placed in. We have multiple of these crypto modules that hold keys, multiple signers, multiple name servers. Everything is redundant. Everything is copied. Everything in that red box is in the safe. There are multiple layers of facilities control, as you can see, biometrics going on the outside the eye with that. And you can look at this at your further leisure. There are a number of test machines out there that actually feed off of our test bed already. And you'll see in the lower left-hand corner, it says Test A through Test N. We would be really happy to test with the root server operators. If that's what the community asks, we would love to work with them. Just another slide showing, if you actually want to see the status of the test. It is at this Web site. That's what the Web site looks like. Green bars turn to yellow bars or red bars depending on if something is needed, a signing has to occur. Or if there is a problem with one of the sites, one of the operations, they change color. You can also see a copy of the signed root, if you click on "root." Go ahead and test it. We've had recursive public DNSsec resolvers. There is one now at that I.P. address, that name. Thanks to OARC for helping us with that. Bang away at it. Testing here is one of the most important aspects of doing anything at the root here. We certainly do not want any hiccups along the way. That would be an extreme detriment to DNSsec and DNSsec deployment. We have master name servers for those of you familiar with name servers at those I.P. addresses. One them is actually an Anycast. Thanks to PCH for that. And if you want to secondary -- if you want secondary to run your recursives off of any of those things, contact me. Happy to set you up. This is now a little bit commentary on the notice of inquiry. This is what I have seen. This is -- reading the notice of inquiry, I would just -- real congratulations to NTIA. This was a really good read, very technical, fair, accurate treatment and issue. Very good. However, one of the things that was absent throughout all the flow diagrams and some of the work was the depiction of that trust and that vetting process and the keys that actually get exchanged between the TLD operator and the rest of the system. VeriSign and ICANN proposals published in their entirety, great. Comments, of course, we have heard that over and over again. I will keep saying comments from all the stakeholders in the global community are really important here. It is a technical notice of inquiry. But this is good. This is our chance to do the right thing. So regardless of which way or what your comments are, comment. Quick comparison of proposals. ICANN's proposal, we don't have any restrictions in design. We are just looking for the most secure solution we can in the most timeliest fashion. IANA vets the TLD keys like they do now with other information and immediately signs the zone. Vet it, sign it, protect it. DNSsec experts will design the final system. KSK handling, all those issues that involve some of the community interests and we will implement it. Communities can determine how, who, where, including backup sites and mirror sites. VeriSign's proposal -- hopefully I get this right -- IANA vets the keys, transmits keys to VeriSign who signs the zone file. Uses M-of-N KSK handling. Again, if that's what the community would like ICANN to do, we're fine with that but it assumes that IANA cannot create the zone file. Okay. Quick description of what's missing in the notice of inquiry. And that's just a picture there. I'm just, again, pointing out that the connection between the TLD operators and the vetting process and the rest -- and the signed zone is not covered and not necessarily discussed. And that's -- you know, what about security here? Where is the security in this particular picture? I mean, there is security between the root zone maintainer and various other pictures but nothing between the TLD operator and the signed -- signing of the root. Just a little effort there in need to try make that a clearer. I look at this all as a chain of trust. The root anchor there is a top lock there. This is part of the ICANN proposal where we would both vet and sign the data so we would authenticate, validate and protect the data all in one step. Then the next chain in that infrastructure, in that chain of trust of keys, would be the keys from the TLD operator which we have vetted and then further on down the chain to the second level, third level and fourth level. This is an important picture from the viewpoint of it eliminates any potential avenues of corruption between transmission between the various organizations. What other proposals -- I'm not pointing to the VeriSign proposal. But in general what is not referred to, not looked at, taken into account is that chain of trust. Transmitting the vetted information that IANA has vetted regarding keys through to another organization will require another link naturally. And naturally being good engineers we will encrypt that link to try to protect it. The issue here is, well, okay, you encrypt this link. Now you have another set of keys. Why have this other link? It is who's going to manage that key? How is that key protected? And in the earlier slide, I pointed out how critical this link at the root is because so many other -- all the other TLDs and all the rest of the Internet count on this link. This link should be designed simply, completely securely and with the minimum number of avenues for any kind of corruption, be it intention or unintentional, regardless of what the reason, this should be a single link. That's the point of this picture is to show that while there is a key sticking out of that one last piece, it is not clear who necessarily might control that key or just simply manage it. Okay. This just goes down the list, why add another link? Who has the key to this link? How's that managed? Would you trust your savings to this link? I mean, I know the stock market has not been doing well. But when I do a trade on one of these brokerage pages, I worry sometimes. This is something -- really every time you look at a security problem, you really have to ask yourself: Would you trust your money to that particular connection and that particular operation? So this is one of those cases where I personally get a little nervous when I see any unnecessary redirection of data. All right. Just to summarize the ICANN root signing proposal, no change in current control. DNSsec is, first of all, not about control. It is about security. Our proposal would not change the control or how the zone is generated, how authorizations are made or any of that. We accept no compromises in security. We don't create that extra link in the middle. We -- as soon as we have vetted that information, we sign it and at that point it is protected. It doesn't matter where it goes or how it is published. Community buy-in, designed by the community for the community. Timely deployment, sure, we have had a fair amount of time on the test bed. But understand and agree that testing is very important here and happy to test with anyone and to develop the extensive programs as well, as needed. Flexible and open. DNSsec is still a changing landscape. People are learning more things as they deploy this, and there is also going to be changes in policy as well. It has got to be flexible in both respects. ICANN with it's consultation processes and various mechanisms to handle that is a perfect place for that, a perfect organization for dealing with those sorts of inputs and those sorts of changes. Last thing. It's your root. Help design it. Test it. Run it. Make it a platform that people can build new things on. And, again -- I will repeat it again and again, your feedback counts. You've got until November 24. I don't care what your feedback is, say something. Without some point or some set of comments that we can base a future direction on, we may have nothing. So, please, just please look at the NOI and try to comment on that. Now, this is just a short -- I promised to say something really short about the interim trust anchor repository. This is just a description of what that is. It is a mechanism to publish those top-level keys, to publish those TLD keys for domains that operate DNSsec currently. This would allow not only testing but would allow a one-stop shop for people to come and get this information. Of course, the Web site and distribution mechanism will be protected. It will be protected with a certificate, a SSL cert as well as a PGP key. But it is a temporary thing. This is there just while we work out the details about signing the root and how that happens. This gives people the opportunity to move forward and not have to wait. A quick note on publishing formats. Of course, there is various ways we are going to do this. We'll have a Web site. We will have it in machine readable form as well as well as the file format, which a lot of the name servers would like. Well, availability of this is going to be very soon, a week or two for the top-level domain operators so they can play with it, so they can try revoking and things. And then it will be reset and actually will contain the valid records that people can then use and soon be open to the general public for their opportunities to draw off the listed keys. That's it. Thank you very much. This definitely was not done an alone. I've had a tremendous amount of help from the various experts in the internet community on DNSsec and there are just too many to list here. This definitely was just not a one-man effort. With that, any questions? >>STEVE CROCKER: Thank you, Rick. Let me try to stimulate a lit bit of interaction here. Certainly anybody who wants to ask a question specifically of what Rick has said is welcome. I see, Bill, you are raising your hand. We've got people with microphones and numbers. But the question I want to throw out for general discussion, what's the most important aspect with respect to getting the root signed from your perspective? We have a little bit of time and I would be interested in one or two or three responses from anybody who wants to jump up and say, Here is the key thing from my point of view about signing the root and I see Daniel here. >> BILL MANNING: Can I jump in Steve while someone is getting Daniel a microphone. I guess I will. My name is Bill Manning. And this is for Pat and for Richard. The Internet is by some accounts an international activity. And the root zone affects global networking. And both the Department of Commerce NOI implicit and the VeriSign and ICANN responses explicit talk about U.S. government security regimes. Are those sufficient on a global context, or are there other security regimes which might be more secure or differently secure which should be added to the mix? That's the first question, and then I'll pass on for later. Is FIPS140 the right thing, or is there something better or different that would be useful? >>RICK LAMB: If you don't mind, Pat, I will say something. You certainly step in. We looked for other standards other than the FIPS standard. It turns out there are very few of them. We are perfectly happy to buy -- that's just money. Whatever the device out there that the community deems appropriate, we'll purchase with the right standards. Right now I will say my experience has been the FIPS standard. There are a few others. There is the Canadian parallel to the FIPS standard and, of course, the devices we have purchased meet both of those. As far as I understand it, the European standards have not -- there is not one solid standard on that. So I know that's not a clear answer, but point to them and we will be happy to look at them. >> BILL MANNING: There is nothing from Asia that has been considered? No Asian equivalent? Nothing that has emerged? >>RICK LAMB: I have not found one. Maybe Pat knows something about one of those. I have not found a public standard from Asia. >>PAT KANE: Clearly that's not my expertise in terms of that because I'm delivering the presentation from a different part of our group. That's what my understanding is, too, that there's not much out there. >>STEVE CROCKER: Good. Daniel? >>DANIEL KALCHEV: Daniel Kalchev from dot bg. I have my perspective from a TLD operator that has already implemented DNSsec. And the comment is once the root zone is signed, it is very simple. They are little things. The first thing is that this will put more value on our efforts. And the second thing is since we participate in the various groups that try to encourage people to implement DNSsec, I think that when the root zone is signed, there will be much more pressure on other registries at all levels to implement DNSsec because users will start to recognize that they can have some real value of the DNSsec. And this also includes the vendors of various software that will make use of DNSsec. Thank you. >>STEVE CROCKER: Good. Any other comments? Andy Linton. >> Andy Linton from dot nz. We are in the position that we would like to sign our -- sign the nz zone. We are not ready to do it tomorrow, but a signal from the top level of the hierarchy that it was good to stay in the root would remove a barrier to us proceeding with this. We are not going to do this until the root is signed. So there is a bit of a catch 22 here. But that would be good for us, and the only concern we have is one of the test ensures stability of the process. >>STEVE CROCKER: Good. Anyone else? You're standing up. >>SUZANNE WOOLF: Suzanne Woolf. I wear many hats in these venues but speaking now as one with long experience as a root name server operator. You have all heard both of these plans talk about needing a diversity of oversight. And one of them explicitly suggests people with that responsibility be drawn from the root zone operations groups. I personally would really like to know if that's something that the community would want those organizations to be responsive to doing. Because as been commented on, there is a great deal of trust from the community in the root server operators. That's taken very seriously. And one of the questions that I personally have about how all of this should unfold is would that be an acceptable and desirable extension of what root server operators are already doing? Or would that be sort of risking mission creep and having, perhaps, an inappropriate extension of a job that the community seems to feel we are already doing very, very well? So if anybody wants to provide comment either here or privately, I would be very interested in hearing. >> Yes, back here. >>BILL MANNING: This is Bill Manning again and this is my second question. Both the VeriSign proposal and the ICANN proposal do not speak in any depth at all with regard to emergency key rollover. What happens when the key is compromised, because it will be? How do you roll the key and get it deployed into the Internet, the new key, successfully? I would like to see that added as an adjunct to your proposals. >>STEVE CROCKER: Thank you. It's a fair point that we need to shake down all the different aspects, including the distribution of new key. Yeah. >>STEVE DELBIANCO: Steve DelBianco with Net Choice Coalition. So many of the press reports this summer, whenever DNSsec is mentioned, call up the Kaminsky vulnerability and the NOI from our Commerce Department, since it mentions DNSsec, seems in everyone's mind to immediately suggest that signing the root zone would have or would prevent the kind of Kaminsky vulnerability. And I'm honestly confused about that and wanted to know whether that's an immediate and logical connection or is it just sort of that we're laying the groundwork for signing the actual zones where you could potentially frustrate a Kaminsky type vulnerability? >>STEVE CROCKER: Let me take that. Signing the root by itself won't kill off the Kaminsky problem. You have to sign all the zones and the resolvers that make the lookups have to check the signatures, then the Kaminsky thing is totally closed off. I'm obliged to be a timekeeper on all of this, and so let me thank Rick and Pat and Fiona who -- appreciated -- she had a very dense schedule and was able to come only for a short period of time. And so with that, let me move on to other aspects of DNSsec besides the root zone. Daniel, it's your turn. And then we're going to have a series of relatively short talks. Where's Demi? >>DEMI GETSCHKO: Here. >>STEVE CROCKER: Here. Good. And then Ondrej. And so -- and in relatively quick order be prepared to come up. Thank you. Pleased to have Daniel Kalchev from Bulgaria. >>DANIEL KALCHEV: I will have this very short presentation which has -- it's a little bit strange development in that originally I was expected to give some presentation on our experience with DNSsec, but having been to several DNSsec-related meetings lately, I discovered that on most of those meetings, the presentations that we give out are focused on what we have done, how we have done it and things like that. There is not much information on how others can actually implement DNSsec, why they should implement it and so on. So I decided to research the presentation and just give some kind of cookbook of what you need to successfully implement DNSsec. It is far from complete, but I hope it is something that you can look at and make your own considerations. The first question is, of course, why implement DNSsec at all. DNSsec has been around for actually many years, and we can consider it an important extension to the DNS protocol. Until recently, it was not so urgent to implement DNSsec because most people were happy with the performance of the current DNS implementation which was recently demonstrated in a spectacular way, let's say so, that was not very secure and we could not have entrusted. So what DNSsec actually does, it provided assurance that the data registry or some name server operator is publishing on the Internet so the DNS is authentic, it can be verified through the end users, and the end users that is actually the software that is used to access the Internet can verify that you're opening the site you would like or you're sending e-mail where you would like. It protects against some of the common attacks. One aspect, which is not very recognized is that DNSsec is actually improving the quality of registrations. And this is something that all registries should consider very carefully because this is one of the most important aspects of our service. It's also introduced more discipline in the way DNS servers are configured. There have been many cases now when the DNS system was not properly configured but is still sort of working. When DNSsec is implemented, this is all going to break. And this is one thing that probably scares some people, but I think that if we start doing it early in time and do it step-by-step, not do it when it is absolutely necessary, then we will be able to resolve most of these issues and in a way improve the quality of the DNS. And the last thing, there has been a lot of talk related to DNSsec on the security aspect. It is important to recognize that DNSsec is more about the quality of domain name system than it is about security. And I have observed how some people get really scared when they hear the word "security" especially in the registries world. They start thinking about some strange people look in rooms and things like that. DNSsec might require some of these aspects, but it is not about that. So here are the things, in my opinion, that you need to think of, not necessarily in this order, but that are important that each registry considers when they think to implement DNSsec. The first thing is supporting your name server's infrastructure. You have to think about a platform for creating and managing your keys. You have to think about the security of the keys, how to protect them. And also the key management when you replace keys and so on. You also have to design a platform for signing your zone information that is adequate and appropriate for the size of your domain. You have to automate and again automate any changes you have in keys, and you will have changes in keys. And last, you have to design your policy how you authenticate your registrants, and so you delegate the security further. About the name server infrastructure, the interesting thing is that this time the major software that is used on the Internet for name servers already supports DNSsec. Some of the software has supported DNSsec for several years. But still there are many authoritative name servers that are not really up to date. So this is one important task you have to verify that all of your name server infrastructure, including the infrastructure you subcontract, is able to serve DNSsec records. And in some respects, you may have to plan for upgrades of hardware, software and band width because DNSsec will generate more traffic. The platform you need for key generation is something that has created a lot of, let's say, allegiance. You have to put some, let's say, common sense on these other ways, you will not be able to overcome it and you cannot move to the next stages in implementing DNSsec. You need to be able to create quality keys, and for this you need a source of entropy. You may need some kind of cryptographic accelerator devices or devices where you keep the keys. You may need to keep both keys if you have been in zones that you mentioned you have to do frequent key rollovers. It's also important that you make a choice of adequate key size because the key size will determine the time it takes to locate the signatures for you and for the resolvers to check the signatures. And also you have to make sure that you keep some status and history information for your keys so that it is easier for you to handle later rollovers. About the security, this is a very long aspect, I would like to make it short because there is not very much time. You need to protect the private part of the key signing key. There are many, many ways that you can do this. You can use all kinds of smartcards, tamper-proof devices, you can split the keys in several pieces, give them to different people and so on. You may use all kinds of network isolation where you create the keys in one place, you transport the keys out to another place and so on. It's always better to destroy the keys, if you suspect that something is wrong, than to disclose the keys. So this is something that you have to keep in mind. And also many people have, let's say, the false sense of security that if they hide somewhere the key, they're protected by DNSsec. And as I mentioned before, DNSsec is not only about security, it is here to protect the authenticity of data you publish. So if somebody can have access to your registry database and they modify the records that you store there, you will not gain any more security if you have very secure safe for the keys. And, of course, this somehow relates to the previous presentations. This issue is very serious until the root zone is signed. When the root zone is signed, the responsibility will move to the upper level. So if you have, for example, a key compromise, you can just send the new key to IANA and you will be saved then. And, of course, the zone signing key can be changed much more frequently so there is not much security problem there. About the zone-signing platform, I have heard several comments from registries of very large zones that they have one significant problem with performance. So that this is one of the reasons they haven't implemented DNSsec until now. It is true that if you have several million of records, you cannot just sign all of the records at the same time in very short period of time. And if you tried that, you will not be able to have frequent updates. But there are still several considerations here. All signatures have lifetime. You can adjust the lifetimes of your resource record signatures so that you don't have to re-sign the records all the time, you have to re-sign only the changes. And you can also consider something very important here. It is the size of the zone-signing key which also greatly impacts the signing performance. If you do frequent updates, there is absolutely no point that you have very long key because the time it is exposed to cryptographics, attack is not that long. So there are many portals here, I will not go in much detail. Another important thing when you consider deploying DNSsec is to design as much automation as possible. Of course, you have to have the zone information automated when you sign it, but also you have to automate the key rollover processes. You will have to keep some database of changes, lifetimes, time when you will change the keys and so on. It's very easy to implement and actually you should do this in all cases for the zone-signing key. And I would want to emphasize one point here. If you do not automate, you should probably forget about DNSsec because you will always have a place for human errors. >>STEVE CROCKER: I think that's an extremely good point, and I thank you very much and appreciate your talk. I find it quite exciting that the dot bg domain is one of the earliest ones, and I continue to applaud your initiative there. Thank you. In the interest of time, let me ask Demi to come on up. Thank you, Daniel. Demi Getschko from Brazil. >>DEMI GETSCHKO: Thank you, Steve. I will exchange some ideas about what we were doing in Brazil to deploy DNSsec. It will not be a technical presentation but a collection of ideas of how you can in some way stimulate your customers on the chain of DNS in your country to be aware of and to deploy this technology. Dot br is a country code delegated in 1989 and established the hierarchical structure under dot br. And then we have second level, third, and fourth level of registrations. The main registration is in third level under dot com dot br, but we have other -- around 70 second-level domains under the dot br. In 2007, in June, we began with DNSsec signing five small zones, the dot br zone, that is a small zone, of course, and four second-level zones, the blog br, eng, for engineering br, eti br and gov, government br, we signed these five zones and of course we hope that the people under those zones will also assign their servers and the ISPs have to contribute in some level doing the same in the recursive servers of their servers in their possession. After that we expanded the DNS to almost all the second-level domains in Brazil. You can see this in this link here. I will not show it now, but it's available. And we also published what would be the policy to generating periodically the key signing key and the public keys that are available in this other link you can see here, registered brk, the key signing key. Okay. Then we mentioned this idea of spread in DNSsec with another idea we had before the DNS, but there was an idea of creating safe havens for special kinds of domains. For example, one of the major problems we have in security in Internet is phishing. And phishing is very bad for banking systems or so. If you have your banking system mixed with other million domains in dot com dot br, it's difficult to prevent false names that can lead the users to confusion and maybe even promote some kind of fraud or so. Then we had the idea to congregate, for example, the banks under a special subdomain under dot br that would work like a sponsor domain. Then we have the guarantee that only banks would be under the dot b dot br. And this idea added to a mandatory DNSsec in this second-level domain. We will create really a safe haven for the domains under this level. Curiosity -- curiously, the first second-level domain that asked for use this safe haven was the judicial system in Brazil. Originally they were under the dot gov dot br, but they don't feel comfortable to be together with the government, they are not executive, jus.br is another kind of function, another power. Then we created the dot jus dot br for the judicial system in October 2007. And they populated very fast this domain, very rapidly. And actually, I supposed the whole judicial area is under dot jus dot br and this is a mandatory DNS domain, DNSsec domain. If you are under dot jus dot br, you have to have DNSsec implemented in your DNS. The second one may be more impactant second level, the name was bbr for banks. We began in September this year. And we have almost 80 or 90 domains under bbr working right now. And this is good because this forces in some way the ISPs and the other members of the chain of DNS also to add DNSsec to their servers because, of course, the people who like to have the guarantee that when they try to access the bank site, this is really a bank site. How I said that we got to this is in twofold. First, guaranteeing that the name and the dot br is a bank because it's a sponsored domain and second level adding mandatory DNSsec to this. Here we have the curve of growth of the domains in Brazil with DNSsec. >>STEVE CROCKER: Demi, your slides are not advancing. >>DEMI GETSCHKO: My slides are not advancing? I'm sorry, I have to -- >>STEVE CROCKER: There's two ways to do it, I think, you can do it or they may be able to do it. >>DEMI GETSCHKO: Oh, sorry, my fault. Okay. Anyway, this is the name of the domains I talked about, the DNSsec domains, nothing very crucial here. This is the jus.br in 2007 and the bbr in 2008 and I was talking exactly about this graph here, that is the growth of DNSsec domains. You can see the first jump at the end of the last year with the jus.br entering the arena. And we saw also the bbr beginning to play two months ago. Okay. Here is the entry, the DNS entry for jus.br. You can see that the DS records is over there, the delegation signature record, and we see here the bbr, also with the signature records over there. Okay. Next steps. By far the major second-level domain in Brazil is dot com dot br and the second is dot org dot br. Those are the biggest zones and represents about 95% of the total. We have some concerns to put DNSsec in these zones until now because we want to have DNSsec 3 deployed because DNSsec 3 supports -- we will not reveal the zone file if you want to go to walk in the zone file. Then now is time to sign these two zone [(inaudible) and the DNSsec 3 was tested, we are running DNSsec 3 dot br zone to test this extension. There was information available in that link over there. And we are ready now to sign also the two biggest dot br zones, the dot com, dot org and dot br. Basically, this is just to tell you the numbers. We have about 1.5 million domains under dot br and 1.3 is dot com dot br or dot org dot br. Okay. Thank you. >>STEVE CROCKER: That's fantastic. Thank you. Ondrej? Ondrej Filip from the Czech Republic. You guys just launched, at the end of September. >>ONDREJ FILIP: Thank you very much. My name is Ondrej Filip, and I am CEO of CZNIC, the domain name registry for domain CZ and also the Czech ENUM domain. I got about six minutes to talk about the launch of the DNSsec, so I will be quite brief in some slides. I will not describe the company at all. The most important things for DNSsec is that we have a very liberal registration model. We don't apply any restrictions. We have a flat model, so we don't have any sub-domains like dot doc, dot ch, nothing else. The end users sister directly under dot cz. We have about 30 registrars and we have the registry-registrar model. That means we do not serve the end users directly, so everything is done through the registrars. We have close to a half million of domains in dot cz and close to 5,000 in the ENUM tree, and the dot cz is quite fast-growing. It's about 36% per year. Or that's the number from this year. We had several assumptions for starting the DNSsec implementation. First of all, we wanted to -- DNSsec to be available for both zones, for dot cz and for the ENUM as well. We have a shared registry for those both domains, so that would be nice to have all the keys and all the contact details in one place. We also wanted to have the large hosting providers, so we implemented key sharing. That means that a hosting provider that has multiple domains of customers can use just one key to sign them all. There is just one item in the database that applies for all domains, so that reduces the overhead and things with the key rollover and such things. Also, we wanted to have it free for the users. We don't think that the security is some special service. It's just a feature of the domain, so we don't have any fees regarding the DNSsec. And we didn't want to change the model that works for the domain name registration, so we still wanted to use the registrars to serve the end users. We wanted to -- DNSsec to be fully integrated into FRED. FRED is the open source registry package that is used by us, but -- and for some other countries, so it's an open source system that you can install and run a top-level top-level registry in your place. You can look at the URL that is on the screen if you want to test it. Of course we wanted to follow all the RFCs. We wanted to have a large key for the key signing keys, and such things. We were working a little bit about the zone walking problem. In the time we started the DNSsec implementation, the NSEC3 was not available, so we talk a little bit with our personal data protection office whether they think that the zone walking is a problem or do they think that our zone, which is not published normally, contains some personal data and we got a final approval that they don't think there's any problem regarding the zone walking. And the last thing, at the time and is still is the issue today, there was no central repository except the Internet consortium system's DOE, so we decided to put all keys into that repository. So how it began -- sorry for the typo. How it began? In a spirit of Czech tradition, all the big things started in a pub drinking a beer, so we didn't want to have some exceptions and we started in the same way. As you can see, there are five people -- me, my two colleagues from dot cz, Richard Ram and the most importantly, author of RFC no. 1, Steve Crocker. We had a very nice evening after the IETF meeting in Prague. We sat at a very nice restaurant and we talk about DNSsec and we agreed that dot CZ this year will be signed and we will start DNSsec. So a few months later, we make a first public announcement that we are going to implement DNSsec. We issued a white paper that -- for the local community that described the way we want to implement DNSsec in dot CZ and to have something for testing and for playing with all the keys and all the stuff. We signed the ENUM zone for Czech Republic. Two months later, we waited for the comments from the public. We issued the final version of the document, and we started the development. I think it was said here before me, the technical part of the DNSsec is just really the small part, so it took us -- I don't know -- three months to ADAPT our system, to ADAPT our Internet processes, so in August we were able to release the new version of the system and make a test bed for all registrars to test their system, if they are able to connect it to the new version and so on. In the beginning of September, we signed the dot cz and still we didn't start any end user key records, registration, nothing like that. We just signed the zone. We still are waited for all registrars to be ready to ADAPT their system to our system, and at the end of September, we opened the registration for the end users and the end users started to register their key records into our system and we generated the zone for them. Today, we have about 250 signed dot cz domains. We have also six ENUM domains signed. The DNSsec is supported by the largest registrars, so the registrar that covers more than, I don't know, 70, 80% of all registrations are all ready for DNSsec. Some of them made a special product because they realized that talking about DNSsec is probably too complicated for the end users, so they just made a product called "Secure Domain," which means that you have a domain has hosted on the platform of your registrars, and the registrars takes all the name of the signing and key rollover and such things, so that makes the DNSsec very easy for the end users. A very good point was that we got huge support from one of the largest newspapers in the country called (non-English word or phrase) dot cz. They signed the zone in the first day, in the first moments, when the system was available, and they wrote an article about it, so the thing that check zone has signed was also published in the general media, like TV and general-focus newspapers. Also since the beginning some of the ISPs joined that we really spent a lot of time talking to them, explaining to them why DNSsec is important and what they should do enable DNSsec on their servers. And of course we made a work page that contains information about the DNSsec in Czech Republic, and also there's a very simple test that shows the end user whether his or her ISP supports DNSsec or not. You can see the green key that if you see that key, that means your resolver supports DNSsec and is validating the Czech domain. So that's a simple test for the end users, and if they see the red key, they can ask, "What's the problem" of the ISP or the maintainer of the network. What do we need to do? There's a lot of things we need to work on. As I said, the technical part is just really the small part. We will continue in communication. We talk with the largest ISPs to set up the -- to enable DNSsec on their resolvers. We speak with the portals and search engines that DNSsec is here, that they should secure, you know, their domain. And of course we speak with the large companies -- banks and newspapers, all the companies that have some important information that the end users read daily. And last, but not least, we communicate with our government, because we also like to have the governmental domains to be signed. We prepared our laboratory for testing the DNS compatibility. There are some issues in the ADSO modems and the end user equipment with DNSsec, so if we will step a little bit further and also the end users would enable DNSsec on their local resolvers on their personal computer that could cause some problems, so we are working in advance on that. And we also -- we are also developing some tools and try back-fixing the software and hardware and there is a lot of boxing in the DNSsec integrated software and hardware, so that's the task of the laboratory. We are trying to educate our local community. We make some seminars for newspaper articles and such stuff. And of course we communicate very often with the other registries. It would be very helpful to have other registries in the region with signed zones. And that would be very helpful for us if the root zone would be signed, of course. Oh, any other solution, ITAR would of course help but of course signing the root would be the most -- the best thing for us. So thank you very much. >>STEVE CROCKER: That's fantastic. That really is spectacular progress in a short period of time. Very impressive. I also like that picture very much. [Laughter] >>STEVE CROCKER: That was a -- there's a good story behind that picture, but I'll hold off on it. But in a bar sometime. Or over a beer, which is the best place for it. Yeah. There's Rick. It's a fun story. [Laughter] >>STEVE CROCKER: Thank you again. Lance? Good. We have Lance Wolak from Public Interest Registry. PIR runs the dot org top-level domain, and on the progress toward getting dot org and working with others to move the whole industry forward. >>LANCE WOLAK: Thanks, Steve. So I have two topics I'd like to get through quickly here today, watching our time. I'd like to talk about our milestones with our rollout of DNSsec, but before I do that, I would like to go through the industry coalition, DNSsec industry coalition that we started recently and some of the activities there. Back in July we reached out to the technology community and asked them, you know, what things would help in the streamlining of the DNSsec rollout from registries and speed up the adoption. They came back with a number of great recommendations and different items to look at, and also they felt very strongly that it's really up to the registries to kick-start the adoption of DNSsec, and then the registrars, after that. So in the August time frame, we started up an industry coalition, with the goal of accelerating the adoption of DNSsec and providing a uniform rollout among registries. So we pulled together just a very -- a short group of -- short list of registries that were involved in DNSsec already, and it initially started as an informal industry coalition but about a couple weeks ago we began to put some formal items in place, including a memorandum of understanding with guiding principles. This coalition's open to any TLD that is involved in DNSsec rollout, as well as any technology or software development companies. So in pursuit of this goal, how are we going to do this? Well, we want to establish consistency of tools and applications through the sharing of best practices among the registries and the development and engineering representatives from those registries sharing specifications, shared nomenclature, even things as tactical as sharing a common table of contents for an implementation guide that would go from the registries to the registrars, for example. So we also have a goal of trying to get good educational material out to the various folks that are implementing DNSsec, as well as to the general public. So this is not just another group. We'd like to observe a rule here, which is to -- for all the members participating in this, let's check our political agendas at the door, any competitive differences among each other. There are some competitors within this organization. Check all that stuff at the door. We're all in the same boat. We're all trying to develop tools and applications and various other items to streamline the adoption. And I'm very pleased that everybody's observed that and we're able to focus on some very good projects. So the goal of this group is to talk less and do more. We recognize that there's been a lot of discussion around DNSsec over the years. A lot of discussion on ways to implement it and not. But we want to get to work immediately and start rolling out some specific projects quickly. The current participants in this coalition are us -- dot org -- Afilias, Nominet, dot se and Shinkuro. As of last week, NeuStar has joined this coalition. And I understand NLnet Labs is in the process of joining this coalition. We have about ten other organizations that are interested and should be joining in this coalition within the next couple weeks. Among them a number of other registries. So again, this coalition is open. You're all welcome to join. Any TLDs or software development organizations out here today, please see me afterwards if you'd like to participate in this. So when we got started in August, we had a lot of great ideas in our first meeting of what things we can work on to streamline the adoption and speed up the adoption of DNSsec, but, you know, we had a lot of different opinions and a lot of different priorities among the members. So we decided to go through a decision modeling process to prioritize all these great ideas and to go through a single decision together and arrive at what's our top priority and so forth. So we set a goal of within three weeks we would have these priorities identified, projects identified, and immediately begin development work on these. So within three weeks, in September we arrived at a list of items. So within these -- this decision modeling activity, we wanted to derive what would be produced as a combined work group, so what it is is priorities for the work group, priorities on the projects that we would collaborate on. What it is not is prioritizing all of our individual efforts as organizations on DNSsec. So the items that we're going to work on together, those are the items that went through this decision model to prioritize. So we had two decision models. First was to identify our priority targets. That is, our early adopters of DNSsec. And the second decision model was to identify the critical requirements of each of those early adopter segments. And then the final step was to create a project plan with specific assignments taken on by the participants, and these assignments were in the form of tools and applications, educational material, and advocacy efforts. So the first decision model yielded these priorities for early adopters: Hosting companies, DNS providers, other registries, registrars and software/hardware security vendors. And then the second decision model identified these critical requirements to address within each of those early adopter areas. So tools and applications, educational material, material that would be rolled out through the various folks implementing DNSsec, and then advocacy efforts. So in that order that you see there is the order which we put the priority on these critical requirements. Okay. So for each of the early adopter segments, here are the assignments we had. I won't go through all of the early adopter segments. You can go through this presentation at a later time and look at the details. But just specifically on this highest priority early adopter, the hosting companies, we looked at tools and applications to provide the hosting companies with the streamlined implementation guide, and again, this is the various registries that are participating in this coalition are sharing their ideas and best practices, as well as specs and again, even table of contents of this implementation guide. So when this guide gets rolled out to the hosting companies and in other cases to registrars, ISPs and so forth, that this implementation guide would look the same coming from these registries and they wouldn't feel that they would be implementing a different flavor from each registry; that it would be a very similar flavor. We had educational materials on our list of priorities for hosting companies, to encourage them to adopt DNSsec and also to provide them with sell-through materials, so that they could sell the value of DNSsec to their customers. We're also taking a look at creating some type of a DNSsec-ready seal for hosting companies to use on their Web site. Now, these logos and readiness seals are sometimes overused, and, yes, there are challenges to managing these and the handover of these. But I think what's behind this that's important is that there's a set of self-assessment criteria that a hosting company would go through to determine their level of readiness to move forward with DNSsec. And that's really what we're trying to capture here with this particular item. Okay. So as I said, the other priority early adopters are listed in this presentation. I won't go through all of them right now, in the interest of time. So I'd like to know what all of you can contribute. If you would like to join the coalition. And what you think of the effort, and I sure would like to talk to you after this session to get your opinions, your thoughts. Our contact person at Public Interest Registry on this coalition is Lauren Price, and her contact information is right in front of you there. And then the second topic I'd like to go through is the DNSsec activities specific to dot org. So with DNSsec at dot org, we've put in place the traditional product launch process. One that you might see with software development organizations. But we've done this to coordinate our DNSsec development activity, marketing activity, policy activity, et cetera, all the way through initiation to beta test and to production readiness and rollout. So with that, we're closely tracking our critical path milestones and I will say that the majority of the technology-related work with preparing for DNSsec should be completed by the end of this year and moving forward. The zone signing for dot org in our friends and family, or beta test, launch is on track for the first half of 2009. Like any other development process, software development process, there's a lot of internal and external dependencies on dates, so I don't have a specific month time frame on this, but as we get to about the first of the year, January 2009, we'll be able to zero in a little closer on a specific date for these activities. In terms of our marketing activity, as you know there's a lot of market conditioning going on out there with DNSsec. There's a lot of organizations that are discussing what they feel is the value of DNSsec and why the industry should move forward. There's also a lot of fear, uncertainty, and doubt that's out there as well. We have a blog that we've started which we call the FUD Busters blog to take a look at the fear, uncertainty and doubt, and try to bring some clarity to it. You know, what is -- what is fact, what's fiction, and, you know, in a lot of the fear, uncertainty and doubt stories, there's a lot of truth behind that, and so we'd like to pull out of that what are some of the challenges that we should extract from that information to help us and improve our readiness to roll out DNSsec. So with this blog, we're attempting to bring clarity to a lot of the voices and a lot of the information that's out there on DNSsec. We're also participating in a number of conferences this year and into next year. I just came from the RIPE conference in Dubai prior to coming to ICANN, and we've been participating in a number of other technology conferences about what we're doing with DNSsec at dot org and also about the industry coalition. If you'd like to help in our marketing activities, our contact is crystal Peterson at dot org. She'd love to talk to you. She's also here today and feel free to meet with her after this. Thanks, Steve. >>STEVE CROCKER: Thank you very much, Lance. That's great. And one of the areas that is important in this overall equation is the registrars. I've been working with Uma Murali from Names Beyond. Come on up, Uma, and talk about the work that you're doing. This is coordinated rather well with the PIR and folds into the launch of DNSsec in dot org, as well as also supporting other domains. >>UMA MURALI: Ladies and gentlemen, thank you so much for giving me an opportunity. Compared to all the technology presentations that I have heard, we are a novice but we really have a head start in the DNSsec area. Let me tell a little bit about who we are, what we are. I represent Names Beyond. Do I press this? We are an established ICANN-accredited registrar. We provide high-value and high-end sponsored top-level domains and our vision is very simple, provide good security service and good secured technology with a great value. And DNSsec fits right into this area for us. When we talked about DNSsec, I was just wondering, why do we need this? And why do our customers need DNS security? DNS is not safe. It doesn't matter whether it is a small registrar, big registrar, small company, a big company, if you are an ISP or if you are a profit, non-profit, it doesn't matter. It is each one of our responsibility. If you are running an Internet business and if you are online, it is our moral responsibility to make sure that our customers, when they type in their Web browser the Web site, it resolves to the right Web site. And it needs a lot of outreach and it needs a lot of communication, education. I know we have taken the baby steps, but we have taken it towards the correct, right direction. DNS making it accessible to our customers, how can we do this? What are the challenges? I know on top of my head the first very challenge is DNSsec is very technical. And it is sometimes scary if are not used to it. And I know a lot of our customers are going to say, hmm, DNSsec, what does it do? Will it fix my viruses? Phishing? Spam? So there is going to be a lot of ongoing awareness, education. And I know most of the articles today we are seeing on the net, online, it is all technical and very little business-oriented DNSsec information is available today. We also want to provide a convenience to our customers. We want to make it easy and say, huh, it is no problem. And the reason I am saying this is because we are leaders in some of the sponsored top-level domains today, and they already ask for authentication and it is already a two-step registration process. Some of the sponsored top-level domains like dot travel, dot coop, dot aero, they already ask for authentication. That is the same thing we are going to pass it on to com, net, org, info, or any ccTLD. You authenticate your customer and say, Hey, this is what it is. This is the security key, and here it is and pass it on to the registry, pass it on to ISP. It all sounds great, but it is just a baby step and we are right in the process now. We have the first step, as somebody else said now, the first step is automation. We have automated the key signing, the key transmission and the retransmission. We have also incorporated the key generation of the zone signing and everything into our regular security that we follow in our regular registration process in our domain management panel. We have incorporated the DNS security, so it should be going smooth. Just a little flowchart here that how we are going to incorporate it. It is signing the names that are hosted with us and that are hosted with somebody else. Simply, we have just divided our customers into two categories. There are going to be customers who are using our name servers and who are bringing their own name servers. That's it. And what are we asking them and how are we taking the data and we are passing it to the registry on to the ISP accordingly. We have done the legwork, and we are really proud to say that already we are on the process of trying some signing of the zones for some of our customers and we are doing it in the test bed. And great thanks to Shinkuro and PIR. We are friends and there are actually a lot of -- in the online here today, we have a lot of information available. We use BIND software, and it is an outside software and we use NSEC3. So it should be -- we already actually -- we are doing it in the test bed. And if anybody is interested, please come on over and we'll talk about it. And if you want to test it, we are also looking for ideas. It is just a process. We are not out there. There are a lot of open issues and open-end questions, what we are going to do, how we are going to do. We are really excited about the DNSsec area, and we'll take the questions. We might not have all the answers today but, definitely, we are on the process of working on if it is with PIR and Sparta and Shinkuro and we will get the answers. Any questions? Steve, is it appropriate to ask questions or can comment. Contact us later. You have our e-mail address. And maybe in the next ICANN meeting we will have more improvements and more developments. Thank you. Thank you for giving us the opportunity. >>STEVE CROCKER: Thank you very much, Uma. I think by the next ICANN meeting we will have a bake-off and have interesting statistics. Question? >>DENNIS JENNINGS: Steve, Dennis Jennings here. I would like to ask a question of the last speaker. Supposing I was a concerned citizen in my own country and I was anxious to persuade my bank to take DNSsec seriously, how would I go about it? And is the tool set that was being talked about there a useful starting point for me? >>STEVE CROCKER: I think that's a pretty interesting question. You're in Ireland. I have no idea how to convince the Irish banks to do anything. But let me introduce you to each other and suggest that you have that conversation on the side here. Uma Murali, Dennis Jennings, distinguished member of the board. I don't know how to have a useful group discussion on that, so we'll take that up. I'm very pleased to welcome Shyam Sheshadri from Microsoft. We've been working quietly with Microsoft. A whole team has been working with Microsoft for a couple of years and we now have visible fruits of that. So take it away. >>SHYAM SESHADRI: Thanks a lot. Thanks for giving us this opportunity to be here. This is my first time at an ICANN meeting so let me begin by introducing myself. My name is Shyam Seshadri. I am the program manager at Microsoft for Windows DNS server and client. Let's see if we can make this work. I don't think I need to sell the slide to anyone here. We all know that when the DNS was designed security wasn't really a prime focus. And over the last several years, we realized that securing DNS with more than just stopgap solutions is what we need. A long-term solution is what we need. DNSsec is emerging as the clear winner in the space. I do want to make a point that Microsoft recognizes that DNSsec will play an important role in the long run in the next few years. This is something the entire community is coming together, and it is with great honor I am here to announce that Microsoft is now supporting DNSsec in Windows 7. So last week we announced Windows 7 to the world at the Professional Developers Conference in Los Angeles. It is actually two products. It is Windows Server 2008 R2, which is the server queue. I can look there, too. And it is the Windows 7 client, which is the client's queue. Both DNS server and client in Windows 7, that's what we are calling it internally, will support DNSsec. Our goal is to provide end-to-end deployable story. So we are integrating our DNSsec solution with technologies like IPsec and group policy. And for those of who you are familiar with the security controls that have been proposed by the U.S. government in NIST SP800-53, Windows 7 DNSsec will allow federal agencies under this mandate to be compliant with the requirements of this -- the development proposals and security controls. I want to give a quick overview of our implementation. This is a fairly technical bit of a talk so apologies if it gets a little too draggy. On the DNS server, the DNS server will allow you to sign a zone using an offline sign tool that we're providing in-box. It can host the signed zone as a primary or secondary. And for those of you who are familiar with our implementation, it also can be stored in active directory. That's a third option that we can provide. You can configure and manage trust anchors in the DNS server and the DNS servers will use these trust anchors to build a chain of trust. On the client, the client is a non-validating security-aware stop resolver. It doesn't roll off the tongue very easily. What it basically means is the client will depend on its local DNS server or its configured DNS server to perform validation on its behalf. The client is aware of security so it will check to make sure that the server has done validation on its behalf. And if it hasn't, it will throw the response away. It won't return it to the application. It is aware of DNSsec even though it can't perform validation on its own. The entire behavior on the client is controlled by policy. Now, in a model like this, it is important to secure the last top. I think that's pretty obvious. Microsoft is strongly recommending the use of IPsec for this purpose. We've designed our client such that the client expects the server to produce a certificate with a special EKU that says, I am a DNS server and without the certificate, it won't allow the IPsec session to be established so that adds a little bit of extra security to the overall communication. Now, I'm not going to talk a whole lot about this slide. This is really for those of you that look at the deck offline. It kind of gives you three examples of how our implementation works between server and client, so I'm going to skip this and move on to actually explaining these with a pretty picture. No. That one. Yep. A couple of things I want to mention here. This is slightly simplified, for one. And, secondly, I have split the example between server and client. So apologies if I kind of flip back and forth between the slides. There are two things that I want you to focus on on this particular slide, the two boxes on either end. The one on the left that says "name resolution policy table" and on the right is the "server trust anchor store." The name resolution policy table is really the policy I was mentioning a few minutes ago that defines the DNS client's behavior. It tells the client what to do when an application queries for a particular name. So in this particular example, there is a rule in the policy table that says when an application queries for something.example.com, which is in this case denoted using the wildcard star.example.com, do IPsec to your local DNS server and set the DNSsec okay build, which, basically, means tell your DNS server, I understand DNSsec and I expect you to do validation on my behalf. On the service side, you can see in this particular example the server trust anchor store has trust anchors for example.com and contoso.com. So when a client queries for a name in either of these domains, the server will go ahead and perform DNSsec validation because it has the trust anchors to be able to do so. Now, let's look at the three examples. In case one, the client is querying for www.example.com, ask for its policy table. The policy table says do IPsec and set the DNSsec okay build, so the client is going to go ahead and establish IPsec and I expect you to perform validation for me. The server has the right trust anchor, so it can go ahead and do this. And the response, the server will set the DO bit which means I have performed validation and I was able to successfully validate the response and it will return the RRSIG which is, basically, the signatures which accompany the responses. In case two, the clients querying for just an example www.Microsoft.com. There is no policy on the client. There is no trust anchor on the server. This is just a plain vanilla DNS query. In the third case -- and this is actually pretty interesting -- the client is querying for www.contoso.com. Notice there is no policy on the client, but there is a policy on the server so the client will not set the DO bit. It won't tell the server that it knows DNSsec. But the server has a trust anchor, so it will go ahead and perform validation anyway but it won't return responses to the client saying that it validated the response. So if you look at the other side of the picture on the server side, in case one we saw the client bits of the DO bit. The server had the trust anchor so it went ahead and did validation. It returned the DO bit and the RRSIG in the response. In case two, like I said, that's just a plain vanilla DNS query so no trust anchors, no DO bit, none of that stuff, that model still continues to work. In case 3, even though the client did not indicate knowledge of DNSsec, the server had the trust anchor so it went ahead and performed validation anyway but it does not tell the client that it did validation. So in the third example, you can almost replace the client with a down-level client that does not understand DNSsec and the model continues to work. The Windows 7 DNS server is smart enough to protect a down-level DNSsec unaware client in this model. So switching tracks a bit, I want to talk a bit about interop. Obviously interop with non-Microsoft implementations of DNSsec is really important to us. And this is going to be a key focus area for our beta and prebeta testing that's actually going on right now. But I want to sort of reach out to the community at this point and ask the community if there is interest in having some kind of an interop test fest where we basically get a bunch of DNSsec implementations, server and client, maybe get network hardware, firewalls, switchers, et cetera, into a lab and basically beat it up to make sure that things work. This is really something that the entire community is moving towards, and we kind of need to make sure as a whole all implementations work across the network. So if this something that's interesting to anyone, come ping me offline and we will have a chat about this. In terms of Windows 7 roadmap, like I mentioned, at the Professional Developers Conference last week in Los Angeles and at the WinHEC, the Windows Hardware Engineering conference that actually starts today in the U.S., we are distributing prebeta builds of Windows 7. It is an early build, but it does have DNSsec in it. So if you have access to these builds, go ahead and test DNSsec and give us feedback. In terms of general availability of Windows 7, we are targeting something approximately in the three years from Vista time frame. So that kind of puts us out into Q1 of 2010. It largely depends how well our beta goes and what kind of feedback we get. That's the time frame we are looking at Windows 7 general release. This is contact information. I have my e-mail address there. I have the e-mail address of our core DNS team at Microsoft. We'd love to hear from you, ask us questions. Send us your thoughts generally about DNS as well as we would love to have some e-mail chats going on with you. And that's about it. I can take questions now, but I know we are pressed for time so I will handle it offline if anyone wants to chat. Otherwise I can take a couple questions now as well. >>STEVE CROCKER: I would think this is important and we can certainly take a few questions. Yes. >> (saying name). You said in your presentation that you are supporting DNSsec with -- what is known as DNSsec (inaudible) 4033, 34, 35, RFCs. What are your plans for doing DNSsec to be able to support for NSEC3? >>SHYAM SESHADRI: Right. So at the moment, our implementation does not support NSEC3. It just so happened that the timing of the RFC becoming an RFC and our implementation didn't quite work out. So at the moment, we don't support NSEC3. But if it turns out that this is something that is needed, then it is definitely something we can go back and consider. But as of now, our implementation doesn't support NSEC3. >> Yeah. Well, my understanding is most of the TLDs applying to a signing in the future use NSEC3. So I think it would be worthwhile considering that for a future release. >>SHYAM SESHADRI: Absolutely. Absolutely. There is no question about that. It is definitely something that we want to have in our roadmap going forward. >>STEVE CROCKER: Good. Other questions? Ah. >>DENNIS JENNINGS: Dennis Jennings, the Irishman. You mentioned a security reference -- a U.S. security reference. What are the implications for that for international installations? And in particular I am thinking about access -- emergency access to it. Is that built into that standard -- I would imagine it is -- that security agents of the United States have methodologies for getting access to our systems or am I completely over-interpreting that standard? >>SHYAM SESHADRI: I'm sure you can answer this better. >>STEVE CROCKER: I will listen to your answer first. >>SHYAM SESHADRI: So the security controls I mentioned really -- again, this is my interpretation of it -- is something that applies to U.S. federal systems, U.S. federal I.D. systems. And so my understanding is that any U.S. federal I.D. system that's capable of hosting a DNS server must host a DNSsec signed zone. So it really only applies to the U.S. federal systems. Is that right? >>STEVE CROCKER: I haven't made a careful study of the federal regulation but these are the so-called FISMA, Federal Information Standards Management something. And I believe that the principal focus is on the protection of systems, setting standards for U.S. systems and, hence, for products procured by federal agencies. So I don't recall if there is any access issues in there. But in any case, DNSsec is not a confidentiality mechanism. So you are referring, I think, to the CALEA and so forth. This is really fundamentally disjoint from that. And so I know that there is a sensitivity and perhaps the little fear that a federal regulation might carry with it some hidden trap door thing. I don't think that there is anything like that involved in these regulations. So this is serving very usefully as a market driver as well as protecting the U.S. federal systems. >>RICK LAMB: Hi, this is Rick. Thank you. Very good presentation. One of the questions that I keep getting asked about may be down in the weeds. How do trust anchors get distributed? You being on most of the desktops in the world, it seems like an obvious question to ask: Have you guys thought about how trust anchors might be distributed into your server products? There is a RFC 5011 out there which might provide some guidance. But you guys have Windows Update. You update certificate lists all the time. Could you speak to that a little? Thank you. >>SHYAM SESHADRI: So you mentioned desktops. Again, our client is non-validating so there is really no technical reason for the trust anchor to be on the client. It is really a server that needs to have the trust anchor. At the moment, I don't have a good answer as to what we prescribe as the best way to put the trust anchor into the server. I can say that once you get it in, our integration (inaudible) allows it to kind of replicate to the entire network. You just need to find a secure way to put it into one DNS server and it will find its way to all of them. I don't have a good answer for what we prescribe. >>STEVE CROCKER: One last question. >>DENNIS JENNINGS: Thank you, Steve. I'm sure you are planning these interoperabilities bake-offs at places like the IETF and so on. Would it be useful to have demonstration of such interoperability at the next ICANN international meeting in Mexico? >>SHYAM SESHADRI: That's something we can definitely think about. The interop fest I was talking about, I'm sort of bringing it out for the first time here largely depends on how -- what kind of feedback we get and how much interest there is. But if it goes well, I don't see any reason to not have such a thing. Obviously if that's something that fits in well with the agenda at Mexico, then I'm sure it is something we can talk about. All right. Thanks a lot. >>STEVE CROCKER: Thank you very much. I like that question, Dennis, because it puts stress on the system all over the place, including the stress on the scheduling and use of the time during these meetings which already is, as you know well, a lot of competition for time. But the interoperability testing is absolutely vital and, in a minute, I will show you some related kinds of results. So if we don't bring the testing to Mexico City to be done, we should at least, I would agree, bring the results of such testing and the advertisement that we're going to do that. There may be other forums that are more appropriate for that. I'm going to close with just a little bit of data on some other things. Let's see if I can control the slides here. Good. Okay. One of the things that happened when our colleagues in Sweden turned on the DNSsec in February last year was that it was awkwardly discovered that some of the devices, the routers and firewalls at a customer premises, small businesses and homes were not configured properly or had not been constructed properly and would not take signed responses and so some quick work was done by them to test a whole series of routers. We picked up that work and joined Nominet. We sponsored a study from Core Competence, as I say, which was done jointly with Nominet. In the summer this year, looked at a whole series of routers and firewalls. The purpose of this charge is not to have you examine each one of the entries but there is 24 different devices. They were chosen as pretty representative based upon use, but there is certainly not an exhaustive list. A very, very carefully designed set of tests was done in a coordinated fashion with -- in both the U.K. and the U.S. and coordinated closely with the previous work in Sweden. The main purpose of showing you this chart is that the results are a long way from positive all the way up and down and so this indicates that there is some set of issues. Let me boil all this data down into something much more compact. 24 devices were tested. The devices operate principally in one of two modes. They all answered DHCP requests for end users on LANs. And some of them operated what we in route mode, which is they don't provide their own DNS service. They simply take DNS queries and pass them upward to some other DNS server or they operate in proxy mode where they act as their own recursive resolver and the device hands out its own address as the DNS server. Some of them can be switched from proxy mode, as we called it, to route mode either automatically once the outward link to the wide area network is set up or can be switched manually by configuration. Of these 24 devices, one of the hard questions that we asked when we looked at all the data is for the customer who does not know anything and is not likely to be able -- or does not want to read the manual, if he takes it out of the box and plugs it in, will it work correctly with a DNSsec? And the answer turned out to be only a quarter, six out of the 24 devices, met that very stringent test. Another nine of the devices could be forcibly configured so that they would work properly for all of the users. And additional seven of the devices, an individual client could route his packets past the firewall or the map box or router and choose some other upstream DNS provider. Two of the boxes had some other problems, some of which were transitory. Some of the boxes could be made to work but there might be a customer service call involved, which is not what an ISP wants to hear when you talk about this. We have taken these tests and these results and shared them with ISPs and with vendors and are continuing that process. Comcast has picked up these tests and has put them into their own qualifying tests for their devices. My expectation is that although these results are some distance away from what we'd like, that by shining a light in this area we'll have a fairly rapid upgrade process and revision process for future devices. These devices don't typically have a shelf life of very long. So I would expect the next patch of devices that come out will fair much better. Another area that has -- is starting to come alive is the recursive resolvers. It is all very well for the zones to be signed and that's the right first things. But if nobody is checking the signatures, it won't do any good. So one of the chicken-and-egg problems involved in DNSsec deployment is getting the questions posed by the recursive resolvers and then, of course, the answers coming back from the signed zones. Telia in Sweden has been operating recursive resolvers that's DNSsec compliant since mid last year. And recently Comcast turned on -- let's see, what do I have here? Yep. Comcast just started and University of California-Berkeley has also turned this on. There is some others. Org turned on a recursive resolvers that's DNSsec compliant. I am expecting that this list will grow considerably. This is just beginning to take off. So those are sort of the main results that I wanted to share. Yep. And that brings us to the end of a quite packed program. I have to applaud everyone here for sticking with a pretty varied program. The exhortations, of course, go forth and cause DNSsec to flourish around the world, get your zone signed, get your ISPs to run recursive resolvers, get your top-level domain signed. As. You heard at the beginning, there is now an open dialogue with respect to getting the root signed. Jump right in on that. I think that the more people who participate in that the better. There is a variety of opinions. I certainly have my own very strong opinions, but I'll -- which I'm happy to share at least with anyone wants to share. For the purposes here, the main focus is raise the temperature level. Let's move this forward. As I have been saying during the day, sort of succumbing entirely to the mood at the moment, this is a long haul but there is no question about this, "yes, we can." Thank you. [ applause ]