DNSsec in the Field Wednesday, 4 March 2009 ICANN Meeting Mexico City >>STEVE CROCKER: Welcome, everybody. My name is Steve Crocker, along with my co-chair, Russ Mundy, we chair something called the DNSsec deployment initiative that operates partly as a ICANN-sponsored activity under SSAC, and partly as a sponsored work under Department of Homeland Security out of the U.S. government, and more broadly, embraces a worldwide working group that has both practitioners and consumers of DNSsec around the world. We have made it a practice, as I suspect most of the people here know, of having an extended session, a workshop, although probably that's probably not the most accurate term, set of presentations, on DNSsec and its state of development, opportunity to interact with -- amongst ourselves and also with the people who are making it happen. This session today is in the lingo that is now being developed for the format of ICANN meetings, is a double session, that is, it will run from now until 10:30, we'll take a break, and then we'll continue from 11:00 to 12:30. We may not need quite all that time. But we do have a quite solid agenda, which I'll go over with you in just a second, quite a lot of material. It's become a very exciting time for DNSsec, a lot of different activities. We're now at the stage, I would say, where more than one thing is happening at a time. So instead of a single announcement or a single point of focus, multiple announcements, different -- vendor community, from the TLD community. We, of course, have the extended focus on whether the root will be signed, when it will be signed, how it will be signed, and so forth. But that's just one small portion of the total DNSsec space. Our agenda today is on two slides here, first half and second half. The first half will cover what we'll do before the break. DNSsec Industry Coalition was formed in August last year, and it's been enormously active. Lance Wolak, from Public Interest Registry, will be here, is sitting next to me to talk about it. And related but quite distinct is the status of implementing DNSsec in the dot org domain. We will then have a short update on the IANA's interim Trust Anchor Repository from Kim Davies. And a separate discussion from Joe Abley on other DNSsec activities within ICANN. It says here I'm going to do another introduction in the second half, probably give people time to get back in the room. William Dee from the European Commission will talk about a meeting, and presumably a process that that's part of within the European Commission. There was a meeting on the 5th of February I was privileged to be at. And then I'll give some very brief updates on the experience that Comcast has with its validating resolver, I don't really want to speak so much on their behalf, but they're not here and I think it's important to get that out. And on broadband router compatibility. And -- oops. That's all part of part 1. Second half, part 1. Oh, I see. I'm sorry. Jim did a great job putting this together. I did a less than great job of preparing before I read this to you. So that's all after the break. And then continuing, Michael Young talking on some of the needs for simplifying DNSsec, and Lutz Donnerhacke on more -- essentially along the same lines about making DNSsec more accessible, the logo program. And I will close with a brief update on work that we did in the confines of the Security and Stability Advisory Committee, taking a look at where DNSsec is. And we've got a report on that subject, which I will summarize. So, with that, let me -- I think that's all in here, right? So with that, let me rotate back to Lance and turn the floor over to him. And it's now yours. >>LANCE WOLAK: Okay. There we go. Good morning, everyone. Thanks for having us back. I went through a quick review of the coalition at the last meeting in Cairo. Going to review some of the same notes and follow that with an update of some things that have happened since then. First of all, the coalition was formed by us in August of last year. We had a goal to accelerate the adoption of DNSsec and provide a uniform rollout among registries, and, really, to streamline how that gets rolled out to the registrars. That was our primary focus. This is an informal industry coalition. It's a group of many of you here in the room today who are working together, sharing the above goal and developing documentation, tools, and so forth to streamline the rollout. One thing that we made clear right from the beginning, this is not just another group where we continue to have just discussions. We want to actually be doing a lot of work here and have regular output from this coalition. Another important principle we have is to -- for all of the members to check their political agendas at the door so we can all focus on DNSsec and the adoption. And as the coalition grew in terms of members, you can imagine in any given meeting you'd be sitting across the table from some of your competitors. So it's very important that we stuck to getting the work done with DNSsec and setting aside any differences. So the goal of the group in our regular meetings is to talk less and do more. Founding members of the coalition were us, dot org, the Public Interest Registry, Afilias, Nominet, dot SE, NeuStar, and Shinkuro. Our current participants, it's a long list here of a number of domain name registries, service providers, as well as educational experts, all pitching in quite a bit of effort. We've separated -- with so many members, we decided to separate the coalition into a number of working groups that could work independently and focus on different types of output. So we formed a registry implementation working group. Their first output was to produce the registrar implementation manual. So as a registrar, you might imagine if you were to implement DNSsec, and you'd be working with several registries and doing so, you would want -- you would hope to see a similar flavor of DNSsec coming from each of the registries. So the goal of jointly producing a registrar implementation manual is that the registries could share all or most of the content among each other. So, then, when the registrar does receive this manual, it looks the same coming across from all of the registries. We also formed an education working group. They've created an initial set of DNSsec FAQs, and also looking at other documents to educate the market on DNSsec. And also very important was a document that we could all agree to, which provided a high-level explanation of DNSsec, how it works throughout the chain of trust. There's lots of documentation available on this, lengthy documentation. Sometimes it's harder to agree on the abbreviated and short description of the roles and responsibilities of these various members throughout the chain of trust. That's one output we're looking forward to completing. Also formed an outreach working group. This group works with various trade groups, online payment, banking, and so forth, those who would potentially be early adopters of DNSsec. So they're reaching out to those organizations, providing some educational material, and having some ongoing discussions with them. And then, finally, we formed a tools and applications working group to look at the tools required to implement DNSsec across the chain of trust. So some things that we've accomplished since ICANN Cairo meeting, when I last provided an update, is, we launched a Web site. It's a public-facing Web site to give you an update on the coalition. That can be found at DNSseccoalition.org. We have many of the coalition members conducting press interviews about the rollout and their involvement in DNSsec. The coalition members are also participating in our dot org blog in what we call our DNSsec FUD-buster series. Really, to clarify the fear, uncertainty, and doubt regarding DNSsec, which may come across as true challenges, technical challenges, we have coalition members participating in the blogging to bring clarity to these issues. Also members of the coalition are attending global events to speak about the coalition activities and objectives. So we have excellent representation within the coalition, within the meetings, and also at external events, which I'm very pleased. Okay. So we're looking for additional help here with the coalition. With registrars, we'd like registrars to participate in the coalition, to be part of the registrar review team. If the registrars are going to be receiving materials, tools, documentation to implement DNSsec, we want registrar involvement early, prior to any launch, to review the material that's being developed. When they do receive it, when it is launched, it's our intent that it'll be excellent material. And so, again, it's very important that we have the registrars involved early. Registries, any registries that are not currently in the coalition, we openly invite you to join the coalition and share in a lot of the great effort that's going on right now. I think you'd benefit greatly from meeting with your peers in the industry and discussing all the issues of rolling out DNSsec and the challenges to streamlining the rollout and the adoption as well. Service providers that are involved with the DNSsec in DNS are also very welcome. We're looking for additional participation there. If you'd like to join and would like more information, again, look to the DNSsec coalition Web site. Also, the chair of the DNSsec Industry Coalition is Lauren Price. Her contact information is on this slide. It's lprice@PIR.org. That's my update. Thank you, Steve. >>STEVE CROCKER: Thank you very much. I carefully positioned this talk first in here, because my estimation, this is an extremely important and welcome effort in the community. This is a clear measure that things have moved from a few funders, like government pushing on it with a particular strategy in mind, to industry initiative. And my -- from what I've seen -- and I've been privileged to watch this -- is that it has -- it's gathering momentum and is well organized and is completely neutral with respect to -- it's not pushing one agenda versus another or one vendor or one TLD. So it's an open, inviting forum. So with that, let me take a pause here and open this up for any questions and so forth. I should pull your leg a little bit. You have a booth outside for -- no, no booth outside for people to sign up. But I really think that this is a quite good effort. And although I'm listed as, you know, one of the founding members and supporters, I really have to have -- give my thanks to you, to the Nominet folks, dot SE folks, and so forth, for taking the initiative on all of this. Any questions? Any discussion? People want to probe into this at all? Sweet. Silence here. All right. I'll take the hint. All right. Thank you. Let's move on to the next. >>LANCE WOLAK: Thanks, Steve. Okay. I have a quick update on our activity at dot org with rolling out DNSsec. A little bit of information since I provided this input at ICANN Cairo. As far as operational readiness, we've opened a beta test phase for interested registrars. This is not a formal test phase yet, and we have welcomed any registrar who would be interested in getting a preview of some of the work to come as we get more heavily involved in the formal beta test period. We've drafted and submitted a DNSsec manual to the coalition. I spoke earlier of the registrar implementation guide. That was something that we worked on with our partner, Afilias, to develop. And we're pleased to offer that up to the coalition as part of the shared effort. The majority of the original technology-related work has been completed at this point. The zone signing in beta tests of domain names is still on track for early this year. At ICANN Cairo, we indicated the first half of 2009. That's still on track. So you'll be hearing from us at some point during the first half of the year on our zone signing. You'll find us also at several events and panels as we reach out to the market within the industry here to discuss our rollout. We'll be at GOVSEC 2009, continuing to participate in Black Hat Security conferences, CENTR, Barcelona, APWG meeting as well. Also, I had mentioned this in the coalition update. We're very assertive with our blog posting in terms of getting information out to the general public on a regular basis and addressing any of the fear, uncertainty, and doubt, directly involving industry experts to participate in the blog posting. Again, very pleased with the level of participation we've had on the blog posting with regard to DNSsec. We've also been working closely with Dan Kaminsky on DNSsec. I know he has a number of activities he's now doing focused on DNSsec, even more than in the last six months. Very pleased to have these experts and participate with them in our go-to-market information. If any of you would like to participate in the blog posting, come in as a guest blogger, just give me a shout, I'd be happy to discuss that with you. Also, again, if you're a registrar and want to participate in the early beta test period, would love to have you. And, again, watch for announcements within the first half of 2009 about our formal beta test period beginning. >>STEVE CROCKER: Thanks very much. First half of this year announcement. >>LANCE WOLAK: We're not picking a specific date right now. As you know, with rolling out DNSsec, we want to be careful. We want to do it at the appropriate time. And we'll still remain with the first half of 2009 as our target time frame. >>STEVE CROCKER: And would you like to say just a bit more about what would be involved there versus what subsequent steps are? So if I say, so I have a dot org domain, when can I look forward to, if I sign it, getting it into the -- where in your process would that fit for one of the registrants to be able to put a signed domain up into dot org? >>LANCE WOLAK: Sure. Our beta test period will run for anywhere from six months to a year. So I would say for any general dot org domains, it would be in 2010. We will be doing beta testing on test domains in 2009. But, again, for the general public, it would be 2010, earliest. >>STEVE CROCKER: Thank you. Any questions? >>DAVE PISCITELLO: (off microphone). Are you looking for beta customers or -- >>LANCE WOLAK: Sure, would love to talk to you about that if you have a test domain for the beta test period. We'd be interested in talking to you. Where are you from? >>DAVE PISCITELLO: Dave Piscitello, ICANN. So -- >>LANCE WOLAK: Oh, I'm sorry. Yeah, I think we're already working with you guys. >>STEVE CROCKER: Any other questions? Thank you very much. Appreciate it. And we will sort of watch this space for future developments. >>LANCE WOLAK: Thanks very much, Steve. I appreciate the opportunity to provide the overview. >>STEVE CROCKER: Great. Hi. >>KIM DAVIES: Hi. >>STEVE CROCKER: There's a seat here. We are pleased to have Kim Davies from the IANA group at ICANN talking on the IANA interim Trust Anchor Repository. >>KIM DAVIES: Okay. Thanks very much, Steve. I'd love to give you a really long, detailed, in-depth presentation on the interim Trust Anchor Repository. However, I've only been given ten minutes. And, in fact, it's really dead simple. So I think this'll be really quite a short presentation. For those that aren't aware, the interim Trust Anchor Repository is a mechanism to publish the keying material from top-level domains that sign their zones. If the root zone was signed, we'd have a very simple scenario. End users that wished to deploy DNSsec would simply install the Trust Anchors for the root. However, as we know, we don't have that situation right now. But we do have top-level domains that are signing their zones. And the Trust Anchor Repository is designed to be a way of distributing those Trust Anchors in a fairly simple way. To be clear, we consider this to be a stopgap measure to be decommissioned once the root zone is signed. It's not an ideal scenario, but it's kind of one of the best things we can do right now to (inaudible) DNSsec. Just give a little illustration of how the Trust Anchor Repository works. Here's a classical hierarchical view of the domain name system. Ideally, we would have a situation where the root zone is signed. And I've just highlighted here in green hypothetically some signed root zones. Sorry, some signed zones. If a computer wishes to validate a domain in the DNS hierarchy, what it would do is, it would follow chain of certificates up to the root and it would just need a root zone Trust Anchor in order to validate. That's the ideal scenario. But that's not what we have today. Right now, we have a root zone that's not signed. So in order to do that validation, we need to have a list of Trust Anchors. And they don't need to all be at the top level. They can obviously be further down the tree. But right now, there's no root zone signed. So the theoretical maximum apex of any chain is at a top-level domain. In order to do this validation, the interim Trust Anchor Repository is a way of populating Trust Anchors into validating resolvers. The benefits of the Trust Anchor Repository. Firstly, one of the biggest champions of us deploying this service has been the RIPE community within Europe. They actually devised a set of recommendations on how it should be deployed. We followed those recommendations. We believe we've implemented everything they recommended. Another benefit is, it's very simple to use, both for top-level domain operators and for end users. As a top-level domain operator, to submit your Trust Anchors, you go to an online Web form. It's a straightforward submission. One of the benefits of us deploying this is, we have the trust relationships with the top-level domain registries, so we can very easily ensure that it comes from the right parties. But at the same time, this isn't tied to the root zone and it's a separate service. We don't have a lot of the legacy requirements associated with root zone changes. So there's fairly straightforward processing, relatively quick, very straightforward. For end users, we've provided instructions on how to install Trust Anchors. It works with different DNS software. It works with different protocols. It's not a proprietary service. For some DNS software, they don't natively service DNS records as trust records, so we've provided an additional tool that will convert DS records to DNS key records. It's almost fully automated. There's just one step of manual review before publishing Trust Anchors. But otherwise, every step of the process is automated, including coming whether a Trust Anchor should be listed, checking DNS keys are in the DNS, expiration, and so forth. And most importantly, the benefit is, it should help DNSsec deployment. For those that wish to collect top-level domain Trust Anchors, this is a much easier way to do it than to contact all the top- level domain registries directly, to monitor their mailing lists and so forth. It aggregates those publication mechanisms into one place. This is what it looks like. In fact, I'm going to flip across to my Web browser to give you a correct look. unfortunately, the resolution on the projector is low, so I have to scroll. You can see there are quite a number of top-level domains listed in the Trust Anchor Repository, including all the test IDNs, but also a number of ccTLDs as well. And I understand the last remaining top- level domains that haven't listed their Trust Anchors will be in there soon. Like I said, it's really quite a straightforward service. I think it's relatively easy to use. And if you can think of a way to make it even easier, we're certainly all ears. One other minor thing. It's the first site we've deployed that uses this so-called green bar, this extended validation SSL certificate. So I think it just adds one extra little bit of assurance that we're trustworthy. I can't tell you how hard it was to get a green bar for IANA, because IANA isn't actually a legal entity. So it says up there that it's ICANN. And it took us about three or four months to get that. But that's there as well. It's at ITAR.IANA.org. And please use it. And please provide feedback. Thank you. >>STEVE CROCKER: Super. Don't go away. I know I have a bunch of questions. But I'll -- Let's ask if anybody else wants to probe or ask any questions about this at this time. All right. Well, then I'll plunge right in. Oh, I'm sorry. Is there a question down there that I missed? You were pointing at somebody? >>LUTZ DONNERHACKE: Do we know what the current state of the Greek top-level domain is? >>KIM DAVIES: Of the which? >>LUTZ DONNERHACKE: The Greek one. They published a DNSsec key but do not sign zone. >>KIM DAVIES: I was not aware that the Greek one is not being signed. Is Richard Lamb here. Probably comment. The test top-level domains are being signed by my colleague, Richard, who maintains that DNSsec signing infrastructure. >>RICHARD LAMB: Hello. Okay. I'd be happy to talk to you afterwards about T I've been looking at dot GR as well as some of the other domains. I wasn't aware that they actually signed. So.... >>KIM DAVIES: Sorry. My mistake. I thought you were referring to the Greek test IDN, not dot GR. If dot GR is signing, I would certainly like to have a conversation with them and encourage them to use the service. >>ANNE-MARIE EKLUND LĂ–WINDER: This is not a question, rather, a statement. I was going to -- since we are putting our case in the ITAR, I was going to congratulate you on your simple and very straightforward service, which we like it very much. >>KIM DAVIES: Thank you. >>STEVE CROCKER: Thank you, Anne-Marie. That relates to one of the questions I have. In your experience, Kim, is there any hesitation that any of the TLDs have had about putting their keys in? And the other side of the same question, is it your policy to only do it if they ask, or if -- if you see a top-level domain, are you likely to gather that up independently? >>KIM DAVIES: One thing it's very clear is we're not going to proactively add Trust Anchor that is we happen to notice. It needs to be the operators of these top-level domains need to contact us to expressly list their Trust Anchors. For all the top-level domains we're aware of that are signed, we contacted them all several months ago, giving them early access to the service. We encouraged them to list their Trust Anchors. As I said earlier, I think most have. And we encourage the remainder to -- I don't think there's really been any hesitation to using the service. Certainly we had a lot of questions. In particular, I think most that listed their keys were curious about the revocation procedure. Obviously, they're not in a position to revoke a key right now. But they wanted to know in the event that that needed to happen how that would work and how that would be facilitated. But, generally, it's just been questions about how the system works, and they've been very quickly answered. And I haven't heard of any real hesitation about using the service. >>STEVE CROCKER: Jim says there's a question in the chat room. >>JIM GALVIN: Yes. Question from Yvonne MUNOZ, legal adviser for ALAPSI. She says I think DNSsec is not only relevant for registrars, registries, and service providers, but the info sec community has an interest in it. And I don't see a mechanism to get involved with them. Is there any proposal for that? >>STEVE CROCKER: Let me take that. 'Cause I think that's more a broader question than just for the ITAR, the top level. I'm not sure I entirely understand what's desired. But we definitely want as much involvement as possible. So let me turn this into an invitation to have an offline conversation and then we'll take it from there. Other questions? Okay. Excuse me. Could you identify yourselves for the transcribers. >> My name is (saying name) from (saying name), China. My question is, if I am the dot tester TLD manager, I submitted the dot tester DS key to ITAR, ITAR will use its private key to produce some DS record for dot test and publish in the Web site. Then if someone wants to use DNSsec or maybe get ITAR's public key to verify the DS key is required. >>STEVE CROCKER: Thank you. I think I get the basics of that question. In the publication process, after you've got that, what is the assurance mechanism around that process that you're using, since you obviously can't be using a root key to sign it? >>KIM DAVIES: Right now, we publish the DS keys in a number of formats. We PGP-sign those formats. The PGP signature's available. For reasons I'll briefly explain, the PGP key hasn't been widely signed. And that's purely because we just originally anticipated this would be a temporary key, that once the service is properly launched, we would be rolling it into a new key. However, I think that our kind of soft launch sort of overtook our expectations, and within about two days, it went from no one knowing about it to everyone using it. So the PGP key that we're using now has now been signed by several people. I've sent it in to PGP repositories, and it's now published. We're looking at improving some of our internal security mechanisms so we have fully offline signing of that, just to add an extra layer of security. But, generally speaking, PGP signing is the way you can be sure that the copy of the ITAR that you have is genuine and comes from us. >>STEVE CROCKER: Boy, that's pretty interesting. I had another question, which I will ask. But this is generating questions as we go here. The -- one of the questions that's been very active in the technical community discussion about Trust Anchors is update process and how long -- what are the lifetimes of these keys and so forth. Within the regular DNSsec protocol, there's lifetimes on the signatures and a regular process for updating and so forth. But with Trust Anchor Repositories of any kind and particularly with an offline one as opposed to something like DLV, there's a natural question as to how often does somebody have to go back and retrieve the keys. Do you -- is there a mechanism in your process, have you got a regular procedure for noting how long those keys are valid? This is separate from a revocation question. This is kind of a natural expiration and replacement cycle. >>KIM DAVIES: Right. It's actually a very interesting question. And it's something that was posed to me recently by ISC, who are trying to set up a syncing mechanism between the DLV registry and ITAR. We don't provide any guidance on how frequently you should update your list of Trust Anchors from our service. Obviously, we would hope people would update it on a reasonable schedule that's not too often lest they bring down our infrastructure. But, I don't know, I think this is something that would be useful to hear from the community. I think one thing, my personal concern, is if we did provide machine-readable views of expiry dates and that was somehow integrated into the logic of how often you upgrade the Trust Anchor Repository, that you exactly run into this revocation issue, that if you look at the expiry dates and say, hey, all the keys that I have don't expire until the end of 2009 and the logic in your software somehow waits until December to get the next version, what happens if any of those are revoked in the interim? So I think that an implementer would want to, on a routine basis, update the trust anchor list. On what schedule, I don't exactly know and don't really have any guidance for. >>STEVE CROCKER: Are you thinking about making up a policy or being -- or having one suggested to you by individuals or having a coordinated policy suggested by sort of a community consortium of some sort? >>KIM DAVIES: I think any of those is a good idea. I mean, if the community wanted us to come up with a straw man proposal to tear apart, then we could certainly do that. And even better if the community wished to devise recommendations on how to use this. That would be even better. That said, I would like to re-emphasize that we definitely see this as an interim solution. And our main focus within ICANN as ICANN staff is to get the root signed. So whilst the enthusiasm about developing more and more stuff around the ITAR is great to see, I'm overly optimistic but quietly hopeful that the DNSsec signed root will be in our lifetimes and we can shut this thing down. >>STEVE CROCKER: That's a great home. But we're in the practical period here where you've got this. In your description of the PGP signing process, I began to get an image that this has got a bit more complexity than the straightforward description of you bring these keys, you but them up on a Web site, and they're available might suggest. Can you paint a picture of the -- sort of the difference in the complexity of running even this very small Trust Anchor Repository compared to what it would be if the root were signed and you were taking in keys from top-level domains that way and publishing them in an ordinary DNSsec process. >>KIM DAVIES: I guess it's a little hard to give an answer because I think when we sign the root zone fundamentally it needs to be part of our root zone management work flow which is entirely separate from the ITAR so we kind of had a clean sheet when it came to the ITAR and we were able to engineer it quite detached from everything else. Just because -- just on a practical level, we would need to do it rather differently once we collect trust anchors and put them into the root zone itself, assuming it's integrated into the other systems that we have. I think the process can be very similar. It might be so-called Layer 9 issues where we're obligated to do additional processing that we don't need to do with the ITAR. That's out of our control. But we would certainly encourage, for security reasons, that top-level domain managers can add and remove keys as swiftly as possible because there's a security imperative there that if a revocation needs to be done, for example, that it gets issued as soon as possible. And there's a little more complexity to the ITAR than what might be initially visible and fundamentally we obviously try to have the public- facing aspect of the service and the privately facing aspect of the service, and we obviously consider the security of it fairly important, and we don't want someone to be able to introduce keys into the system that haven't been properly vetted. You know, it's a security application, and we want to make sure that everything has been properly validated. >>STEVE CROCKER: Thanks. Let me -- I hope I'm not boring everybody, but there are some fascinating aspects here. Let me move the attention over to the consuming side as opposed to the publishing side, as it were. So these keys are available on your Web site and they're available in a single method, a single method of access or in multiple methods? And what is the experience to the extent that you know it, on the use of these, how -- what processes are people implementing and using and what's the feedback on that? >>KIM DAVIES: So far, apart from the ISC effort to integrate it to the DLV and apart from people using the instructions that we've been provided, I'm not aware of anyone developing new tools around the ITAR just yet, but that said, it's only a few weeks old, so I'm not too surprised. As terms of file formats, we -- XML is our base format. We generate a view of the registry in XML. We derive a so-called master file format which is the format you'd normally insert into BIND and so forth from that XML. We publish it via HDTP, FTP, the R-synch protocol. If people wish to mirror it, they're free to do so. And then, additionally, because, I mentioned earlier, those DNSKEYs aren't natively supported in some software applications, we provide additional tools to help with that as well. That's really what we're providing baseline. And I think that covers almost all users of DNSsec today. But if there's other formats that we can provide or other publication mechanisms that would be useful we're very willing to hear that. And if there's other tools that people develop that are useful with the ITAR we'd be happen to publicize that. But I think it's a little too early to see any action on that front. >>STEVE CROCKER: Thank you. Astonishingly, I think I've run out of questions. Is there any -- anybody else wants to probe? I think this is a quite important development, stopgap as it may be, we have no idea how long we are going to be stopping this gap. So we're -- this is the mechanism of the moment. And maybe not -- maybe more than the moment, mechanism of the day, mechanism of the year? So we'll have to see. Anything that you'd like to add? >>KIM DAVIES: I'd just like to say, unlike most of the somewhat political things we deal with at IANA, everyone's been very supportive, very constructive, no one's been negative about the idea, you know, even myself, I have some reservations about deploying a temporary service like this because I fear that in 30 years it will still be around. But, you know, it's just been a pleasure working on this with everyone in the community. So -- >>STEVE CROCKER: Thank you very much. Okay. Joe? I'm sure you have a title for your talk, but I think the natural title is on the other side of the stopgap, yes? >>JOE ABLEY: Is this on? It is on. That's good. So my name is Joe Abley. I now work for ICANN. I've only very recently joined. And the reason I've joined is because ICANN has formed a DNS group. It's not a policy group. Currently we have three people in that group, there's me and there's two others that those with an operational exposure might have seen before, Mehmet and Eric. Our current projects are basically L root and building the DNSsec infrastructure. The group as a whole will eventually grow to take on all the DNS responsibilities at least as many as make sense within ICANN but at the moment we -- the three of us have plenty of work to get along with just those two projects. I should mention as well as Kim did, this is a very brief presentation. There's not an awful lot of detail here. But certainly we can do questions afterwards or I'm here for the rest of the day. We can talk in the corridors. So at a very high level, what the purpose of this -- this group, what this DNSsec project is, what we have today is shown on the diagram to the left. We have -- the text is a little small -- we have TLD managers feeding requests into the IANA. The IANA is properly vetting those requests and confirming that they're authentic and that they ought to proceed, they're performing technical checks and making sure that all the checks and balances are reasonable. Once they're reasonable and the other various processes involved in updating the root zone have been taken care of, the zone, the root zone is then sent for distribution. It's sent from there to the root server operators, and the root server operators serve it. So this is what we have today. So what we're talking about is inserting this extra block into the work flow. Well, instead of unsigned data from the top all the way coming down with those checks and balances, we have an opportunity in the middle to apply some signatures to sign the zone and to produce a signed copy of the zone for distribution. So what our group is doing is basically building this box on the right. So as many of you may have heard before, Rick has been presenting in many places about his efforts building a DNSsec test bed which has been live for a year, two years? >> RICK LAMB: Almost two years. >> JOE ABLEY: Almost two years. You can see the status of that at the URL shown here. And really, the experience grown in terms of the architecture of the signing, the signing boxes themselves is what's driving the design exercise for the production infrastructure. So my focus right now is on the operational design of the signer. And what this really means is -- it's fairly easy in principle to create something which is ultimately secure and which, you know, you could install once. It would run and everyone would be happy. However, the reality with operational systems is that things need to be upgraded, things fail, things need to be replaced. So we need to try and find a solution that on the one hand has a very high level of security and transparency, but, on the other hand, is also something that can be operated by real people. So when things fail, we don't suddenly have a problem where we need to fly people around the planet, we have systems and procedures set up so that we have a high level of security, we have the transparency, we have the community oversight, but we also have the ability to keep things running sensibly. I'll go into a couple details here. So in terms of physical security, the elements which we are most concerned about physical tampering will be located within two secure containers, NSA-certified, the certification numbers are here on this slide. And that's safe, each of those safes in different locations, will be located within a hierarchy of different access cages within which biometric security would be required to enter. We are -- this is, again, very high-level and the details have not been fully fleshed out. We expect people who have access to the outer levels of cages to have the authority to escort people into the central facility, and those escorted people will have access to actually open the safe. There will be people monitoring exactly what happens within the safe. There will be procedures written ahead of time. There will be informed, technically aware people, monitoring the operational work that goes on inside the safe and confirming, through a lockbox and such things, that the work that was done was done properly. So another aspect to this is ease of audit. We could build all this stuff from scratch, we could write our own code, we could do all kinds of things like that, but at the end of the day that may not be the best answer. In terms of being able to ask -- well, answer people's natural questions as to why can we trust these things, why can we trust these boxes, this infrastructure. We're looking for the simplest possible solution. Because a simple solution allows us to very easily answer what are the risks involved in running this thing. So we're using open source tool chains. We expect to document all the operational procedures. We may wind up publishing those, for example, as informational RFCs through the ATF process in order to try and provide guidance to other people who are trying to build similar infrastructure. We're planning to build multiple geographically separated sites, multiple, actually, is two, in the current thinking, again, this is not quite finalized. Multiple signing boxes within each secure container. The secured containers themselves have redundant cooling and power, they're within facilities that have extremely redundant cooling and power, we'll have redundant network access. And really, our goal, here, is to try and limit -- reduce the amount of occurrences in which we need to open the safes. We want things to keep running for as long as possible without us having to open these boxes. Because every time we open the box, we have to make sure that everybody is satisfied that the things that are going on are things that should go on. So not opening the box is an easy way of making sure that certainty is higher. As far as key management goes, the design work for that has started. We're being assisted by our friends in Sweden and we're talking to, of course, many other people in the DNSsec community who are involved in similar exercises, trying to make sure that the direction we're heading in is the right direction. So here's the status, again, high level. We have -- two secure containers have been ordered. These containers are built to order, so they're actually being built right now in steel fabrication plants. We have two geographically separated facilities close to being finalized. I didn't put the locations up here because the contracts are not yet signed, so it seems more appropriate to delay that announcement. However, they are on different continents. As I mentioned, the key management design is in progress. The operational procedures for exactly how we run the infrastructure, those are being -- have been drafted and are being refined. And the construction of a lab version of the production infrastructure is currently under way. We have a location for that lab, we have equipment ordered. Some of the equipment's been installed. So we're fairly close to having the lab infrastructure up and running. And that will be the point at which we can start testing these operational procedures and start refining them based on the real-world experience. And that's what I have. >>STEVE CROCKER: Thank you very much. That's a pretty substantial amount of progress. Let me open the floor for some questions. I've got a couple of questions. Maybe that will stimulate some additional things. Are there any questions for Joe on what he's presented, either from people here in the room or in the chatroom, Jim? Not yet. Any questions directly? Okay, well, let me start off with a question. How long before the construction and rest of the process that you're engaged in will be ready to go? That is, we know that putting all of this into operation depends upon answers outside of your control. But the -- but nothing can happen until you're ready so what is your estimated sort of ready- go-live for this? >>JOE ABLEY: Slightly hesitant to give you a date. There are certain aspects of this where the time lines are well-known. There's 120-day lead time, for example, on constructing the secure containers. So we expect within the next 120 days -- well, it's less than 120, let's say 120 days, the cabinets were ordered a short while ago, the cabinets will be ready, the sites in which those cabinets will be located are ready, the physical biometric security to enter the areas where the safes are installed will be done. And we expect by that time to have made substantial progress at building the lab infrastructure, which is a prerequisite for installing anything in production. So the unknowns here really revolve around our experience with testing and practicing the operational procedures in the lab environment and also getting feedback from others for the key management procedures and from getting feedback on the operational procedures. So depending on the cycles of feedback that we -- the iterations that we have to go through there, there's a kind of flexible gap in the schedule. I would be disappointed if we didn't have something to go towards the end of the year. That's fairly vague. But is that good enough for you? >>STEVE CROCKER: Well, that's a good answer. Let me just play it back for you. 120 days from now puts us into, say, early July. And then you're saying that a combination of testing and getting operational experience and feedback on all of that will take some more time, which you're saying you hope is well before or well within the end of the year. So a five-, six-month period as a nominally conservative, you know, not 100% absolute, but not a stretch goal, as they say in the HR business. >>JOE ABLEY: Yeah, I think that's right. I think a lot of the -- we could certainly build this a lot faster. But our focus here is trying to build things that the community is going to trust. Because we feel quite strongly that without trust in the infrastructure, no one is going to take much time to trust the signature on the zone. So we are going sort of somewhat deliberately slowly here and trying to make sure that whatever we build has the maximum amount of transparency. If it turns out that somewhere down the line people say, "Well, we'd actually really like to see a live webcam stream of the safes 24/7 available on the Internet so that the entire world can see exactly what's happening," things like that. Perhaps people would like to see direct telemetry streams showing environmental concerns from the safes and things like that. So we expect these things, the list to grow longer until people are sort of comfortable and we think we have reached a level of trust that people are happy with. >>STEVE CROCKER: That's exactly an area that I want to spend a little bit of time, developing the trust. Michael, Mike Palage. >>MICHAEL PALAGE: With the streaming webcams, that's actually the question I was going to ask. For those in the room, Louis Touton, who you may recall was ICANN's original sort of general counsel, everything, he originally had the webcams outside of ICANN's offices available on the Internet so anyone could see who was coming in and out of ICANN's offices. Unfortunately, the current administration ick-snayed that. There was a certain level of confidence anyone on the Internet community being able to see who was entering and leaving ICANN's office. So the streaming webcam, I think that's an excellent idea. >>STEVE CROCKER: I don't know if there's something to respond to that. But let me enlarge the question a bit. You put a lot of energy, obviously, into building it very securely. And you've said a lot about transparency and community feedback. What processes, mechanisms, procedures, plans are in place for developing that community sense of trust? Oh, Dmitri, I was about to call on you. Okay. All right. Good. The -- what kind of visibility is there and what kind of involvement from the community is scheduled or are you looking for? That is, it's one thing to have a presentation like this, and you appreciate that I'm asking as a matter of form rather than personal issue here. But the gap is, from a presentation like this to how to develop a worldwide trust in places where the base of personal experience and all of that has not yet been in place on these matters. >>JOE ABLEY: Well, our approach right now is to treat the design and the rollout of this as an ICANN internal exercise, which is to say that we're not trying to generate a committee -- a worldwide committee to try and build this and to design this, as you might do a protocol in the IETF. However, just because we are taking the lead on the design exercise doesn't mean we're not consulting widely. So the usual suspects in the DNSsec community, I think, will -- if they haven't already been contacted with details of exactly directions we're thinking about going, they will find themselves contacted in due course. And we expect to consult widely on this. So we expect the community to drive a lot of our design efforts, but we expect to do the design. >>STEVE CROCKER: So, DMITRY, let me draw you into this. This is not rehearsed, I can tell you, I apologize for putting you on the spot. But I know that you have represented some concerns about this process and so forth. And, you know, rather than have all this float around loose, let's bring it out a bit in the open. What are the elements that come to mind as you've listened to this presentation that are relevant from your perspective? And for the benefit of the transcribers, introduce yourself. >> DMITRY BURKOV: My comment about both presentations, first of all, in general, ITAR is a solution for us, but not interim. Maybe I will start from some conclusion at this moment, because I know what model can be preferable for us, because we have some restrictions in the real world. One of them is cryptography issue. Another is political. Imagine -- I don't believe that our TLD can be signed by anyone outside. Imagine, for example, dot mil will be signed by North Korean administration. Same for us. Sorry. In this situation, it seems that technical solutions for us can be based if ICANN will have TAR, because it's not a problem for us to have some kind of our national TAR. Second point, it's to support -- to solve another legal problem with cryptography export/import regulation and usage limitations. We can provide open source soft, which realize our encryption algorithms. And they can be implemented in software. Because, in principle, architecture of DNSsec allows you to use different algorithms. And this situation seems workable for us. Is it possible for you? >>STEVE CROCKER: Let me intercede a little bit here. The issue of different algorithms is, I think, slightly -- maybe you want to take this on, Joe. But it seems to me it's slightly different in the sense that the technical specification of the protocol certainly allows for different algorithms to be used at different levels, register the algorithms, implement your part of the zone, and so forth. So if you -- if dot RU or dot SU were signed with different cryptographic algorithms, that would be straightforward from a protocol sense. It might impose some issues in terms of whether the validation software was set up to recognize each of those algorithms and so forth. The -- to be very straightforward and candid about it, though, the top-level algorithm is only one -- a choice of algorithm, at least in the current conception, RSA, for the signature algorithm. And if you're suggesting that that's not acceptable, then there's a whole different class of issues. The place where I think it's useful at this point with -- you know, based on the discussion that we have here so far, is, it's one thing to say it does not matter what you do; we're not going to pay any attention to it. You can say that. I could understand that. But it doesn't -- the conversation kind of stops at about that point. The place where I want to try to draw you out is, given that a facility is being built, and even if, you know, to recognize that there's decisions yet to be made about who and what and whether it's this facility or some other facility, whether it's ICANN or VeriSign, or some other party, one form or another, this is -- let me put it in the best -- what's been presented here is comparable in many respects to any solution that's going to be put forward. So what I'd really like you to comment on is, rather than saying, "This is kind of unacceptable. We're not going to play," is, to the extent that you can, what are the constructive comments one would make that you could make about this kind of facility and this kind of set of processes to be as positive about making something like this work as possible? >> DMITRY BURKOV: Steve, may I add just a few comments. First of all, I don't want to give world guidance, but I want to find the common solutions which can satisfy different authorities, national authorities around the world. Because all design from the beginning ignore that vault is not one country. Because if you will deploy this way, as the second presentation showed, it means for us it will be provocation, because we have not other way, we have no chance to build alternative system. Whole independent. It's a problem. It will be another different Internet. I don't want to get this. And what I try to prove you for in a few months, in the summer (inaudible), that you should shift your mind to understand, to see on this problem from another side. There are some restrictions we can't change just technically. But we can find more flexible technical solutions to escape these political issues. As an example, why I proposed this multiple TAR, multiple TAR architecture. But, in principle, in reality, it could be based on ICANN TAR, which is really trusted. It's enough. Why we should have signed root? Because it's trusted source. And second point, because not -- it's not only Russian issue. It will be the same problem for China, because simply didn't investigate yet their legal issues regarding cryptography they have. They have no knowledge. We have. It's not so many TARs we will have in the result. Only some exceptions. Not only countries have cryptography school. Only we have. >>STEVE CROCKER: Barbara. Is there anyone else who wants to comment? Okay. Barbara. >>BARBARA ROSEMAN: This is really very helpful feedback. I think we've gone very far down this path already in ICANN. And so trying to accommodate these different considerations is actually going to be a little more difficult than just simply saying yes or no. So I think there's got to be more discussion about this. I think that you can't just look to Joe for an answer right now. He's not going to be able to provide that. But I do think that the discussion is really worthwhile, and we'll have to continue it. >>STEVE CROCKER: Good. Anybody else want to jump in? Thank you. And introduce yourself. >> Hi. Brenden Kuerbis, Internet Governance Project. So you're signing contracts, spending capital on this solution. Is there a possibility, since there appear to be issues, could this solution be redeployed to support a TAR? >>JOE ABLEY: Well, -- >>STEVE CROCKER: Just say "no." >>JOE ABLEY: That's the quick answer, for sure. In a sense, signing the root zone and publishing a root zone that is signed is, in effect, a repository of Trust Anchors for the delegations below that zone. So, in a sense, that's what we're building. So I'm not entirely sure what you mean by "deploying a TAR" with this infrastructure. If you mean could we eventually reuse the cabinets or something else if we decided not to use it for signing the root, I guess. >>STEVE CROCKER: Anything else? All right. Thank you very much. This is a -- a great deal more real than it has been in the past. And so one senses that we're quite pregnant at this point, as it were, and that something will happen, by and by. So, again, let me thank you. We are, quite surprisingly, and unrelated to anything else that's ever happened with DNSsec, running ahead of schedule. >>SUZANNE WOOLF: (off microphone). >>STEVE CROCKER: What I'm going to do is, I'm going to take a piece of the agenda from the second half and move it to this slot. Because we've got these orchestrated time periods. So this session goes to 10:30. And then, presumably, we have to be carefully synchronized with the refreshments that are available outside. Just a second. So there are a couple of short presentations that I was going to make in the second half, taken from -- oops. There we go. In the past, there has been reports of some difficulties with broadband routers and firewalls in the small office and home office environment. The first instance was noticed in -- when our friends in Sweden deployed DNSsec and detected some issues in these class of devices. There was follow-up work by two groups that were started independently, and then we merged the efforts. One at Nominet, and one done by Core Competence under our sponsorship. And I want to go back through the results that they found. The slides I'm using are ones that were prepared by Comcast, who took these results, actually duplicated them internally, and validated the results that came from the studies that had been done earlier, got the same results, and -- this is the important part -- brought the vendors of these devices across the industry together. Comcast, for those who are not familiar, is one of the very large ISPs, cable-based, in the United States. And they have, of course, through their market power, considerable leverage on saying what devices are appropriate for their customers to have in their homes. So they brought the vendors together, shared these results. And I don't want to speak too forcefully about -- on behalf of Comcast. But the implication is that this gets the attention of the industry. So as I said, this is a joint study between Nominet in the U.K., and Core Competence, expansion of dot SE's previous study. The devices that were tested were a combination of firewalls, dual- Ethernet gateways, ADSL routers. And the -- one of the methods of publishing this was through an SSAC report. And the details are all available on the ICANN Web site under the SSAC publications. We very deliberately and carefully tried to provide enough information so that others could duplicate the same tests. And if anybody were to try that and need other information, all the information available is carefully constructed and carefully documented test bed process. The bad news is that many of the devices truncate the packets coming back. Many of them don't set the TC flag. And the protocol for having extended packets to -- which is essentially necessary for handling DNSsec responses -- did not work so well. There's, nominally, in the DNSsec protocol a failover for TCP. And in many of these devices, that didn't happen. So that was -- this slide says "proxy behavior number one." Proxy behavior number two, devices that were dumb about DNS tended to do better than devices that were smart about DNS. I'll say more about that. But only so long as they did the UDP/IP correctly. Fragment reassembly was a big problem. So let me be clearer about what this dumb versus not so dumb is. When you have a device that is providing particularly DHCP services in a small enterprise, it has to not only respond with an I.P. address for -- like a laptop that we might have here, we connect it up, and we're told what the -- our machine is told what the address is of the gateway. It's also told what the address is of a DNS server. And so, then, subsequently, when our laptop makes a request, a DNS request, it will make it, typically, to that DNS server. That device is the kind that is what we're talking about here. It's a combination of a firewall or -- and gateway and router, typically all packaged into one. When it's acting as a DNS resolver, it has two choices, or it can be designed to operate in one of two ways, or, in many cases, it has both operating modes and can switch from one to the other. These two operating modes are the following: It can either act as a DNS resolver in its own right, having a cache, keeping track of previous responses, going out and making queries, assembling multiple responses into a single response and sending it back, or it can say, "This is a DNS query. I don't know how to do anything about, it but I know where a real DNS server is somewhere else outside," and it could pass the query upward. It's that latter mode that is being characterized here as "dumb." And it's that latter mode that tended in the testing processes to come out better than the devices that said, "I'm your DNS resolver. I'm here for you. And I will play the primary role at resolving your responses." So that's the -- So half the devices had poor source port randomization. This is sort of a second issue, which is related to some of the recent issues that Dan Kaminsky has done a great job of publicizing that talk about the vulnerabilities in these devices to be -- to have -- to be hijacked in a way. 15 devices put their own I.P. address into the DHCP server's response of saying, "I'm the DNS server." Nine of them had no way to change the response at all. A further six devices put the upstream address in, but only once -- but only after the connection to the upstream link is in. So if you are just turning on this device at the beginning of the day or whenever and it has not yet -- or if there's been a breach -- a break in external network service, there is a little bit of time before it syncs up with an upstream DNS resolver. And the question is, before it's connected up, what should it do if it receives a DNS query internally? And what's being said here is that some of these devices will act as a local DNS resolver until there is an upstream one available. And the last three don't proxy by default. So they're always looking for an upstream one and they would presumably just not give an answer if there's no upstream connection. Why do home gateways have DNS proxies in them at all? To establish stable DHCP offers and for other reasons not entirely clear. Are there better alternatives? One is to use a very short lease until the wide-area network is up. Or ensure that end users can configure DNS via the router's DHCP settings. That, I must say, is likely to be useful for those who are very knowledgeable. Not so useful for people who don't know how to do any of these settings, don't know what they mean, and basically buy these devices, plug them in, turn them on, and hope for the best. So this is -- sort of closes the advice from Nominet and Core Competence. If you have to proxy, do it properly. This is where the advice back to the industry is being given. So that's the short picture of that. There's some more elaborate graphs and so forth. But the picture at the moment is that a small but specific set of changes are needed in the general class of devices that are available off the shelf, and we're going to hopefully see an improvement in the population of those devices over a period of time. May I take questions now? >> Hi, Steve. Thank you. A couple questions. Number one, for the consumers that actually like the Plug N' Play, that's one of the things that's really important for DNSsec ultimately to take off. So that it is Plug N' Play at every point, particularly for the consumer. What are some of the recommendations from the study? That's question number one. Number two is, for the existing routers, I don't know how often people actually change their routers, whether it's, you know, a year and a half, two years, six months. I have no idea. But what are the solutions for the existing ones? >>STEVE CROCKER: So yeah, Dave, why don't you take this. >>DAVE PISCITELLO: So let me answer your second question first, 'cause it's fresh in my mind. You were asking about the frequency of change or -- in these routers. There are actually two aspects of that change. One is the -- the router itself. They're commodity products, they're well under $100. The reliability of the products, depending on the manufacturer, really dictates the changeover. I know many of us probably have a six- to nine-month lifetime on something like a wireless router. I know I seem to buy more of those than anything else that I use in my office. The second is -- so it's a short lifetime. The second is the firmware that's loaded on the devices before they're shrink-wrapped and shipped. And you can go into any store that sells networking equipment, and on the shelf, find the same device from a manufacturer, five boxes, you could possibly find five firmware sets. So they roll out the firmware sets, but that doesn't necessarily mean that what is on the shelf is taken off. So one of the difficulties that we saw during the course of this study was, there's a wide disparity of, you know, firmware, even if you have it. The problem with that is that most consumers have no idea that they need to upgrade firmware. So unless there's a Comcast or some other manufacturer that -- other provider who is bundling the CPE with broadband access and is remotely managing that CPE, and is willing to undertake, you know, the task of upgrading the firmware, there's a vast disparity of what's out there. And there really isn't a whole lot of control that we can exercise. We did point that out in the report as a potential issue. >>STEVE CROCKER: Thank you. Let me add, if I might, two quick things. It isn't quite as bad as this may sound because the vast majority of DNS resolutions take place outside of these kind of environments in -- at major ISPs l in the recursive resolvers that they run so one of the things that's very important is the kind of work that Comcast that Tele in Sweden and other things, other ISP are putting other recursive resolvers in place and I'll talk after the break briefly about some of that and we'll tee up to do a great deal more of that in subsequent meetings. The other that again is the role of vendors, service providers like Comcast and others can play and do intend to play for sure is to list which of these devices are appropriate and so the consumer will then have only to -- well, if they -- they may get the device from the service providers or they may be told this is a list of acceptable products. Alexa, you were -- >>ALEXA A.S. RAAD: I think you answered part of my question. The larger part was are there any specific recommendations or best practices we might be able to take back to the DNSsec coalition particularly to the ISPs or device manufacturers in terms of update of firmware and so forth? >>DAVE PISCITELLO: There are specific recommendations. As you saw from the results, the best -- the best scenario for most of the devices that were tested is when there's a passive pass-through in the device. One of the recommendations was that that be the default configuration because that is the configuration that most users typically adopt. As you said, the plug and play is the most desirable, they want to drop it in, they want it to learn addresses, they want their PCs to learn addresses, off we go, resolve DNS, please don't get in my way. A lot of the devices do come, you know, configured with proxy. I don't know the exact number off the -- off -- my head. We did contact each of these vendors and pointed out what the problem is. Behind the statistics was a great deal of interaction with the vendors because they realized that this is a very big market for them and they don't want to be the ones singled out in some trade rag as, you know, debilitating entire broadband access loops. So I think there's a fair amount of cooperation that we can expect. And the lag is going to be basically getting the shelves full of the -- you know, upgraded firmware and ridding the shelves of the older firmware. I think that's actually probably more of a gating factor than anything else in this whole scenario. >>STEVE CROCKER: Other questions along this line? Yes. >> I'm Jonne Soininen from Nokia Siemens Networks. Like Steve knows, I've been a little bit involved in another kind of project that has similar things basically working with IP version 6. And we found that we had a problem to kind of contact a part of the community that does those home routers so especially smaller vendors who don't come to meetings like this or who are not part of a bigger company that does and who might not actually even though the specifications and standards that well, but actually read those things out of books or download from the Internet. What is your experience that -- how much traction you have gotten from vendors, and doing home gateways, how difficult has it been actually to contact them? And do you have any good tip -- tricks up your sleeve that might be useful for other companies having similar problems as you have? >>STEVE CROCKER: And limit your answer to 90 seconds. >>DAVE PISCITELLO: You'd think I wrote this report. Just sort of a disclosure, I used to be the president of core competence, I no longer am the president of the company. My 20-year partner, Lisa Pfeiffer did all the work but I obviously stayed in very close collaboration with her and some of the things we have been doing for 20 years and doing vendor, you know, testing and evaluation played to our strength in this particular test. Part of what Lisa has become very skilled in is ferreting her way into the right engineering contact in many organizations. Having said that, you know, we had a Rolodex of people that we could start with. But there are some companies where the product is so commoditized that it's unbelievably difficult to find someone who, actually, knows something about the box, whom we could actually talk to about the firmware and in those cases you just do the best you can. So in the case of the broadband testing, one of the things that we ended up doing was buying, you know, the devices and then working our way back out. In prior situations it was possible and certainly in more expensive equipment like an enterprise fire wall, you really do want to get in touch with the vendor. And the real problem is that at the commodity level, it's very -- it's very time-intensive to get a contact. As you go up, you know, up the level into enterprise and there are many more zeros behind the significant digit it's always easier to get in touch with some engineer. But the IETF is a good resource, IETF mailing list, a lot of fire wall mailing lists are places where you can post and says I need a contact. "Even some -- and other security mailing lists. Generally the idea is just, you know, just try to find somebody who knows somebody. And I know that doesn't sound very simple but you'd be surprised at how much cooperation exists in that community because they're all interested in, you know, in either selling product or improving their product or both. >>STEVE CROCKER: Thanks very much. We're now -- consumed the extra time and we're now well into the break period. If there's urgent questions we'll take them, but otherwise I'd like to bring this half of the session to a close. We're going start up again at 11:00 with Bill Dee from the European Commission. Thank you. [ BREAK ] >>STEVE CROCKER: Thank you, everybody. We're going to start up here. I'm pleased to have Bill Dee from the European Commission. We're running -- so everybody -- so we can set expectations, we're running a bit ahead of schedule, as you know. And I do not anticipate that we're going to run until 12:30, I think we're going to be out of here considerably before that. So with that, excuse me, let me ask you, Bill, just to take off and it's yours. >>BILL DEE: Okay. So I hope you can hear me. Thank you very much, Steve. As Steve said, my name's William Dee, I'm from the European Commission. I'd say upfront I'm a policymaker, not a technical person, actually, so please take that into account. I'm also a GAC member. I work in the part of the European commission that deals with DNS issues I'm with Internet security issues as well. I'm here just to give you a brief report on a workshop we had in Brussels last month, beginning of last month, 5th of February on DNSsec which I understand is a subject close to your hearts. The purpose of that workshop was to follow up on DNSsec as an issue which had come up at a previous workshop we'd had about 18 months before which was on ccTLD contingency planning. And we realized there was quite a lot of interest in the subject then. And it had been a while since we discussed it at the European level. And in that time, some of our TLDs, some of our ccTLDs actually deployed DNSsec. So it seemed a good chance to -- good opportunity to take stock on what their experience had been. And also to ask for the opinions of other European stakeholders. In addition, as you all know, there have been U.S. notes of inquiry on DNSsec which provided us with further input. I say that because it wasn't the purpose of the workshop primarily, actually, to try to formulate a European input to the NOI, but it did raise some very interesting questions and gave us some rationale for some of the discussions. The logistics were there were about 70 participants. It was an invitation-only event. It was the governments from the European Union member states. Essentially most of them were the GAC representatives, people who come to these meetings. And our HLIG, I apologize, actually for the acronym, I should explain that it's high-level group on Internet governance which deals with Internet governance, preparations for IGF and also ICANN DNS type issues as well. We inviolated the European country code top-level domain managers who are members of CENTR the regional organization for ccTLDs and other invited guests, including Steve Crocker, here, on my left who was very kind in accepting the invitation and coming along. We invited Autonomica, which is a Swedish root server operator which we thought was a important part of the overall picture, we should have somebody there who was a root server. Afilias was asked to come, we were very happy to have them as a gTLD operator. We split the day into two sessions. We tried to separate the subject out a bit. Which I think, in retrospect, it was a useful idea, actually, it did help to structure the debate, to separate two areas where there's been fairly intense debate. One is just DNSsec itself, actually, you know, is it a good idea, what are the views of stakeholders. The question why is it still controversial was a question we put to a panel of ccTLD operators and it was intended to be controversial. Just to say why is it after this technology's been around for a while, actually, why is it we don't have a very high level of deployment among TLD managers in the European Union. And in the second session in the afternoon, actually, we looked more specifically at the issue of signing the root. And what view stakeholders might have on what position the European Union governments might take. So the whole day was organized as a kind of hearing. The main speakers were the invited guests, such as Steve and the ccTLDs and the commission and the member state governments of the European Union for their part were mainly there to listen, be educated a little bit and try to get some temperature from the room. Now, this is a basic overview of the impressions that we had on the European Union side. As I said we haven't reached formal conclusions. The purpose of the exercise was a listening exercise to allow stakeholders to tell us what they felt. But I think it's fair to say that those registries who have deployed DNSsec, I know two of them there, there's three in total in the European Union: Sweden, Czech Republic and Bulgaria. Sweden and the Czech Republic were there, and they were fairly adamant they'd done the right thing, they're convinced it's the right approach. And while they already have user demand and they feel that that user demand will strengthen in the future, particularly when the root's signed. Now, other registries who took part in our panel, Poland, Germany, and Austria, had fairly strong reservations, actually, there was quite a divergence of views and I think -- maybe it's because I'm not a technical person, but I think the argument that I thought was common there was in terms of their customer base which is actually registrars it's not end users, they felt there wasn't a business case that they could use to sell DNSsec to their registrars. They also referred to other security options that were easier to implement. But there wasn't a lot of discussion on that second point. I think it was mainly -- the impression I got, and I'd welcome any perspectives that Steve has on that, is -- was the business-case argument they had with registrars. On the second issue, signing the root, I'd just very simply say that those who believe that DNSsec is the right approach, the signing the root is a prerequisite for obtaining the core benefits of DNSsec. And that won't surprise anyone. I think that was very predictable. I think there was even a general acceptance among those who were unconvinced about deploying it themselves at their level, the top-level domain level, they seemed to accept the signing the root as a logical extension of deployment at the TLD level, for those who do it. From a policy perspective, from our perspective, I think we reached the conclusion from the room, actually, that there remains a divergence of views about which model for signing would be appropriate. There's obviously some reference made to the six different types of architecture outlined in the U.S. government NOI, I think there were also references to other possibilities for types of architecture. But there appeared to be some mixed opinions in the room about which might be the best. And I think certainly amongst the governments, even those that didn't speak, it was clear in that the -- at the coffee break and the lunch, actually, that there's still a significant amount of doubt about the political implications, particularly of a single entity signing the root. Not least because signing the root is viewed as an irreversible step. So that's partly why governments who perhaps aren't completely familiar with -- with the DNSsec subject as a whole are just getting slightly nervous about which way they should jump on this. But that won't surprise you either. And as a general conclusion I've said here that participants felt that the workshop had been extremely valuable. And that kind of surprised me. We were in quite a lot of workshops in Brussels and the participation isn't always high, and the people who do come don't always get too involved. But, actually, it was a fairly vigorous and interesting day that we had, actually, and that was reassuring. But it does suggest that we need to continue multistakeholder discussions at the European Union level and I guess at the global level to identify more clearly what the implications of DNSsec are and the related issue of what architecture for signing the root would be the most appropriate if indeed that's the direction that is taken. So I promised you a fairly short presentation, I think, and that's the end of it. But I'm happy -- I'm happy, in particular, to take any comments that Steve might have as somebody who was there at that event but also from anyone else in the room. Thank you. >>STEVE CROCKER: Thank you very much. I was there for most of the day, physically my body was there and I was -- I had just come in off of a red eye and was a little sleep-deprived so I apologize if I wasn't there 100% of the time. I thought it was a vigorous and quite good meeting. I have a couple of remarks to add but first I want to ask if anybody else wants to inquire, make a comment. Who else here was also there? You were there, yes. Ahh, good. Any -- anybody else want to chime in here and say anything? Careful silence. First, I want to thank you very much for inviting me. I was very pleased and honored, frankly, to be invited. And I hope it was helpful. As you said, there's multiple levels of discourse here, some technical and quite a lot on the political side. In my -- and I'll be quite clear my opinion about some of this is that the political questions ranged from reasonable ones that are tied to serious issues to other ones that are, from my perspective, not very well tied to any realistic issues and are kind of floating around disconnected. The difficulty is always in sorting out which of those is which and in connecting the dots. I want to pause for a minute because the next thing I want to say I don't want to make it exactly related to that comment, but one of the concerns that has been expressed from time to time about DNSsec is that it will remove or inhibit one of the controls -- one of the safety nets that is viewed in the -- that some people view about the whole root system. Namely that the root server system -- the root name operators which are a semi- independent set of operators, the ones who operate the 13 named, the lettered root servers, who are both independent from each other and as a group, independent from nearly everything else, provide a form of a safety net that if something were completely screwed up in the center so that the wrong content were coming out or someone was abruptly and inappropriately removed from the root have the capability of interceding and taking corrective action. That concept I have never seen carried further other than a kind of expression of hopefulness that is built into the -- some of the free- floating dialogue. And it struck me that we're now living in a world that takes various kinds of threats very seriously. And not only in my country but around the world, a considerable amount of attention to try and identify various risks and threats and prepare for those eventualities including testing and drilling, practicing responses to that. So the thought that occurred to me is, is that a realistic concern? Well, that may be hard to judge. And if it's a realistic concern, is the prospect that the root server operators could really do something about that. What was very interesting is that in the room we had a root server operator, and so we were able to take the question or that thought that had been expressed and turn immediately to Lars Liman from Autonomica, one of the operators of the I root and ask, "So, what you would do in this circumstance?" And let me turn the floor back over to you and ask if you have a sense of what the response was to that question. I have my own, of course, but I don't want to bias this whole thing in one direction. >>BILL DEE: Well, you're testing my powers of recollection, actually, it was a long day. >>STEVE CROCKER: It was, it was. >>BILL DEE: Well, I think Lars was quite resistant to the idea that this was fairly relevant. I think at the same time he conceded that -- in extremis, actually, a very theoretical level, actually, that the possibility existed that they could decide to do something else. But I think that discussion, from my perspective -- and maybe it's because I'm not technical -- that got very confused very quickly for me, actually. I'm not sure that that question was ever resolved. >>STEVE CROCKER: Good. That's -- that's very useful to hear, in fact. My recollection is that he said, "Oh, boy. Yep, we would probably publish what we got and we would say something about it, but it would be difficult to immediately take corrective action." I see out of the corner of my eye Suzanne switching over here as another root operator. Let me ask you to comment further. >>SUZANNE WOOLF: I'm not twitching over here, Steve, I'm smiling at you. [ Laughter ] >>SUZANNE WOOLF: With the usual disclaimers that, as a root server operator, I speak only for, you know, the operation I'm involve in, which is F-root, operated by ISC, a U.S. private company, and I wasn't there to hear what my colleague Lars Jan said. I think what you would find is that people view the operational responsibility of a root server operator as publishing the zone that they get. And that if they found something objectionable in the content of the zone that they were given, they might very well comment, protest, take a stand outside of the operational responsibility. You know, many of us wear multiple hats in the DNS operations and protocol and so on world. But I think you would also find that splitting the root, given that not everybody would do the same thing, I think you would find that people regard splitting the root as extremely grave. And I personally can't say I can imagine how that would come about. And, in addition, one of the independent, private-party root server operators, ISC, that operates F-root, has made a public statement, a joint agreement with ICANN, that says that. >>STEVE CROCKER: Thank you. Question down there. Identify yourself, please. >> My name is Bob Hutchinson, I'm with Dynamic Ventures. I had a question about whether the NOI and the design for the signing of the root, is that a completed -- is that an architecture that's been selected? I understand that the Russian fellow said they're not signing up for anything that we are currently thinking about doing. Is there a process that ICANN IANA is going to go through to determine what architecture they're going to use for actually implementing the signing of the root? >>STEVE CROCKER: What a good question. The other major party involved, of course -- a couple other major parties, NTIA and VeriSign, as well as, of course, the rest of the community, Rick or anybody else from ICANN want to comment? >>RICHARD LAMB: Well, in my humble technical capacity, I mean, we are at this point waiting for Department of Commerce to make a decision. But in the meantime, as Joe (inaudible) put -- explained earlier today, we continue to try to develop a system, with the help of the DNSsec deployment experts that are out there, the people who do work on this stuff. And (off microphone) comments you just made, Steve, about trust and -- maybe this control point, perceived control point that was out there as far as a root server. We very much welcome any kind of feedback, ideas. This is all useful stuff, because we are currently at the stage working with Keyray, the people who put together the Swedish signing system (off microphone) building out a few scenarios, coming up with a few final designs that would try to address everyone's concerns. And so it would be very helpful to hear. Thanks. >>STEVE CROCKER: Good. Any other questions, comments? Thank you. Thank you very much. Appreciate your coming. I think it's very helpful to have an exchange within this forum. And as I say, bridging these gaps is a big part of the process. >>BILL DEE: Thank you very much for inviting me. I hope we get other occasions to interact a bit more. Thank you very much, everyone. >>STEVE CROCKER: Thank you. I want Michael to go. So, continuing with this rearranged order, happy to have Michael Young talking about how to simplify DNSsec here. Take it away. >>MICHAEL YOUNG: Thank you, Stephen. A little bit about me. My name's, as Stephen said, Michael Young. I'm vice president of product development for Afilias. And so this presentation actually will step a little bit away from maybe the contentious discussion points and take a bit of a moment to focus on DNSsec as a product, because that's where my current focus is on the subject matter. So for the agenda, I'm going to talk briefly about DNSsec deployment and adoption. Obviously, for those of you that are not familiar with Afilias, we'll go over who Afilias is and what services we offer. I want to talk about forward momentum in DNSsec. I want to talk about the options that are available in the marketplace now, or, rather, lack of, and why we think that leads to a need for one-click DNSsec. Then we'll end off with a series of suggested next steps, and something that we believe is very interesting as a proof of concept. A little bit about Afilias. For those of you who don't know us, we are one of the oldest players -- oldest of the new players in the industry, if you will. We were born out of 2001 with the launch of dot info, and we provide a number of registry services, solutions to some very well-known players in the industry. You can see them listed up on the screen. And I think most of the people in this room are pretty familiar with us as an organization. Let me jump to something you might not be familiar with yet about us. In February, we launched a new product for Afilias, something we have deep and routine experience in but we were not offering as a direct service out to the marketplace, and that is managed DNS services. We have spent quite a great deal of time and commitment, energy, and investment, in building out a global DNS infrastructure. It's unique compared to other people's products in many senses. But some of the really interesting things is the focus we put on this system in diversity. We're using diverse DNS applications, diverse hardware providers, and even diversity in DNS providers. One of the key focus for us in that product is what we want to bring to DNSsec. And that is, we believe that infrastructure services products are sometimes very difficult for people to use and to understand and to operate. And so for managed DNS service, we've put an extensive amount of effort and research in providing an intuitive and easy-to-use interface. And that kind of focus leads directly into DNSsec, because this product is DNSsec-enabled. Really quickly, just a world map so you can see locations of some of our nodes. This is something that we're constantly growing over time and expanding. But as you can see, we have a very good -- from all the little white dots, we have a very good distribution of managed DNS nodes out there in the environment. Let's get on to DNSsec deployment and adoption. When we start to look at it from a product point of view, we look at momentum. We look at what stops products from coming out to the marketplace and we look at what makes people operate as early adopters and embrace new products. And on one side of this tipping point, you have costs, you have complexity, you have an unsigned root. These are all barriers to mounting up the product along this line. On the other hand, we have some momentum starting to show itself in the marketplace where we've seen a number of test bed deployments. We have announcements from significant players, such as org and gov. The TLDs will be signed, as well as those TLDs that have already been signed. And we have a number of marketplace providers out there that are starting to talk about software solutions related to the problem set as well as hardware. So are we at the tipping point? We believe we're just about there. So, just to talk for a second about that gulf. Most of you who have done any business studies will be very familiar with this type of a diagram. We start with R & D, which most of us have been moving through for years. You've had the pioneers already, and in some cases, you've already had the early adopters. Now, it's a bit of a problem with that early adopter, in that this is an end-to-end infrastructure solution, which means unless it's adopted throughout the infrastructure, you have to have the complete life cycle for the full early adopters in order to move across this gulf that you're seeing on here in the red and achieve mass adoption and mainstream use. Some of the problems with that, of course, the root's not signed. People are very worried about investing money up-front. And then what's the value proposition for the end customers? I don't think people actually question what the value proposition is of DNSsec. I think the biggest challenge with DNSsec for all of us is to express to the common Internet user why it's valuable. Because it's complex. And anything that's complex technically is hard to boil down to simple value statements. However, people buy car insurance. People buy house insurance, travel insurance. This is a type of insurance, at the end of the day. Okay. Some options in adopting DNSsec. You can do it yourself. And take all the risk and -- in the capital investment. There's complexities in how to derive a DNSsec-enabled environment, includes -- as heard in earlier presentations -- hardware and software challenges. Very unlikely you have somebody in-house in your organization, unless you are focused on the DNS provision marketplace, that actually understands DNSsec deeply so that you'll have to bring in that expertise. And if it's not done correctly, of course, you run the ultimate risk of interfering with Internet traffic to the end user. So if we select this route, here's a quick list of some of the things that people have to put on their shopping list in order to prepare. And you can see the list is significant and the cost is significant. It's also not a core business function for a lot of people who need to provide this service. So we go to the other option, which is outsourcing. Fixed cost. You're passing -- you're depending on the experience of others. And if they're a good provider, they'll help you create an end-to-end solution or enable you end-to-end. You're going to need somebody in the space that has a global infrastructure and deep experience in DNSsec, and, most importantly, you're going to have to have an interface that the average user can learn to operate. And we're not talking people that have to be deep, deep DNSsec experts. We have to boil this down to make it simpler. The person providing this has got to have familiarization and relationships with the Trust Anchors and the DNSsec leaders. Why? Because we don't have the root signed, and because there's still a lot of changing variables in this marketplace going forward. And, of course, they have to be able to provide service-level agreements in this type of a product. So having said that, I'd like to introduce the concept for Afilias that we've been working on for some time. And this is DNSsec Secured. This product is designed to simplify adoption of DNSsec and provide a usability solution. Okay, some details on that. No new customer hardware. You can throw away the key management, because we will do that. And it is integrated and add-on service to the existing Afilias managed DNS service that we've provided. You'll see that we've really focused on words like "automation," lack of effort on the person that's using this service. Why are you going to outsource? Why are you going to use a managed service? To make things simple and adoptable. That includes some areas people don't always look at, representation, participation, and decision-making groups around an area. Frequently in the marketplace, we all buy managed services and then find that things change in decision-making bodies, and we don't feel we have representation. We're kind of a victim to whatever those decisions are. And this type of service has to be represented on behalf of its constituents. So some of the basic elements: Distribution of public keys to parent zones is a level of expertise that really -- really requires good integration with the registry business as well, and understanding of Trust Anchors and DLV registries, at least until the root gets signed. Next steps with this is -- for Afilias and, hopefully, with some of you, is really to create an end-to-end test to validate this type of a concept as a product throughout the environment. Until it lives and breathes as a product, we're not going to see mass adoption. And so we feel that's where the focus needs to be now. People that we'd like to see participate in end-to-end test are, obviously, registries that have signed their zones, and key participation has to come from registrars. This is how we add the value and we enable the service. In some cases, DNS providers and registrars are the same entities. Sometimes they're separate. Obviously, where they're separate, they have the same challenges as the registrars. And, of course, because we do not have a signed root, we need full participation of the Trust Anchor options that are available and bodies that are supporting those right now. ISPs are a key part of the solution that, early on, not a lot of participants were talking heavily about. But the reality is, unless there's someone validating these lookups, then we really don't have that insurance active. And, of course, we really have to create a message to end users as to why they want to enable their zones, enable their domain names using DNSsec. And I think sometimes we do bury ourselves a little bit in the technical details and forget about describing this as a value proposition and what it means to people, end users. Okay. Some proof of concept phases that we have gone through to some degree and we will continue to encourage everyone to go through. And that is to test customers, produce an end-to-end test as I described in the previous slide. And not just produce an end-to-end test to validate our own ideas, but to actually take the results of those tests and improve our ideas with those results and a thorough analysis of those results. And hopefully what we come out with at the other end of that is a retail product that the business world has the opportunity to market and have an added product to give to their customers. We are looking for participants in this effort around 1-click DNSsec. Here's some criteria. We'd like to invite all of you who are interested to come talk to us about this. But here are some base criteria that we're looking for. We're really looking for players that are considering implementation in 2009, have more than 100,000 queries a month, are either using an outsourced or an in-house DNS solution that requires a firm SLA, and hold a dot info, org, or gov domain in their portfolio. So anyone that is interested in this, please feel free to come see me after the presentation. I'd love to talk to you. And I thank you for your time. >>STEVE CROCKER: This was great. Question from Dave. >>DAVE PISCITELLO: I'm curious about registration services and DNSsec, and, in particular, whether there's going to be a higher standard for verification of the registrant before you sign a subordinate zone. >>MICHAEL YOUNG: That's a really good question, Dave. And I think that's one that needs to be answered. I think this type of a test bed effort or this type of a product development effort really gives us some answers to that. At the end of the day, a lot of that needs to be discussed with the registrar, because they're going to actually have to handle a great deal of that obligation if it's decided that's what's needed. >>DAVE PISCITELLO: Can I continue for just one second. Aren't you uncomfortable with the notion that people can impersonate, use a stolen credit card and get a signed zone which has some additional credibility? I just -- I would hope that that would be part of the plan. >>MICHAEL YOUNG: Who isn't; right? I think -- I only have one answer to that. And it's absolutely one of the main considerations in it. I just want to be careful now not to define how that should happen. Because we're one participant in this. And I don't want to state how other people should live up to standards that we decide are appropriate as of yet. >>STEVE CROCKER: Yeah. Let me add a comment. Dave, you're raising one of the sort of fundamental questions that have been asked from the very beginning of the DNSsec design. The standard answer is that DNSsec is intended to protect the conveyance of the data. It's not intended to change one way or the other the quality of that data. That's a separate process. The standard reaction to that is, yeah, but if it arrives in a stronger package, doesn't that -- shouldn't I expect that it's better data? And conflate those two things, and not just you, of course, but the general public. So that's one of the tensions that is inherent in the deployment of DNSsec. Let me move on. Just a second, Thomas. Lutz, you wanted to get in first? >>LUTZ DONNERHACKE: First of all, I'd like to congratulate you that we have a major player in this game. We are not all the small ones anymore. That's fine. But, seriously, to make it convenient for the domain holder, for the registrant to get an altogether working DNSsec process, even in the image case, there is a lot of work to do, especially to the contracts registrars and registries have to -- we have a document produced on the at-large summit. And I encourage everybody here to read through these conclusions, especially to change the contracts. >>STEVE CROCKER: And you're going to be speaking right after this on yours. And I think there's some relationships, if I am guessing right, between your presentation and -- it's a matter of logos and so forth. >>LUTZ DONNERHACKE: No, no. I do not want to present -- at-large results here. >>STEVE CROCKER: Any other comments? Thomas, you backed away. Did we cover what you were saying? >>THOMAS ROESSLER: (off microphone). >>STEVE CROCKER: Yeah, thanks. Suzanne. >>SUZANNE WOOLF: Sure. On DLVs and how you plan to interact with them, I think it's been interesting to watch the progression from DLV as an outrageous idea to as sort of a fact of the current landscape. And everybody seems to hope that it won't be a fact of the current landscape forever, but no one knows for how long. And it's good to see that taken into account. My question for you, there are beginning to be lots of DLVs with different policies for what they include. And I guess the question is, are you planning on establishing relationships with those that vet the input or how do you plan to interact with the DLVs that are kind of a little bit more process-oriented? >>MICHAEL YOUNG: Absolutely we intend to have relationships with the different DLVs. I think how we define those relationships, Suzanne, is still under development. And we're looking for feedback, which is why we're asking for participants in this type of thing. We'd like to understand this from a product point of view. Do people participate in this? Do potential, you know, providers and customers ultimately want to see multiple DLV choices in a product? >>SUZANNE WOOLF: I do know one large DLV operator who would be happy to talk to you further about that. >>MICHAEL YOUNG: Absolutely. >>STEVE CROCKER: Others? Great. Did you cover availability, when this is running? And closely related, you could be running, but if parents -- if the parent zones aren't ready, then what do you do with the keys that you generate? >>MICHAEL YOUNG: Well, that's where -- really why we're focusing on the TLDs that we mentioned, which will be shortly signed, if they aren't already signed. And, of course, I focused on the need for DLVs and trust anchors, in general. Our timeline is really to ask participants -- we're prepared to begin work with participants immediately. So we would like people to approach us as soon as possible. We would like to go through this feedback loop and work through early adopters and, hopefully, have a ratified version of this product fully vetted with community feedback, you know, coming into the fall of this year. >>STEVE CROCKER: And as full disclosure, I think that we, my little company, Shinkuro, has a zone up and running in your system now. Measured something like in minutes to do it, so it was all very straightforward. No, we generate other kinds of noise. >>MICHAEL YOUNG: Yeah. He represented an early adopter. >>STEVE CROCKER: Okay. Thank you very much. Really appreciate it. This is another exciting development that fleshes out a major portion of the space that needs to be there. And on behalf of the rest of the community, if not you, I hope that there are comparable other providers as well so that we get a vigorous market. Thanks. Let me have the -- Good. Lutz Donnerhacke. Am I saying your name correctly? >>LUTZ DONNERHACKE: That's okay. >>STEVE CROCKER: Close enough? Get this.... >>LUTZ DONNERHACKE: Okay. Thank you for doing the slides for me. Let's go into the first slide, please. Everybody of you knows what happens if we are talking about DNSsec to nontechnical people. If you are working for a company, not for an institution, you are faced with the problem that sometimes the CEO comes and says, what are you doing here? And if you are going to the marketing department, you see a completely different issue. These are the main points I'm confronted with. I think everybody is clear, DNSsec is currently evolving, so the technical people are going to meetings, they're not available for customer products, that's the main problem. Second point, everything has to change. It took longer and longer and longer and nobody has a effect from. And if you're going to the marketing department and say, "Hey, we have a new product, go and sell it." They say, "We have a product?" We do not have a problem, but we do not -- a product, we have problems, a lot of problems. You remember the case with -- ooh, okay, next slide. A lot of points the marketing department require me or others to do. First, they want a change of the color of the browser line. They want to get it green using DNSsec. Of course it's not possible. Or it might be possible. It's the same way to get the line green as we get green in order to make more money from the X509 certificates, we have to modify the code. Other points which are important. They say, "Yeah, we can sell this if we have a logo on the Web site to put on and say we are doing good job." If the operators are behaving correctly, if someone appears to be correctly signed, correctly maintained, we must put it into the public. We have to bring it up to our Web site and to say "We are good people, we are doing a good job here." Of course, we like to have a lot of other things, like reducing spam, everybody talking about the security problem or security solutions, asks this question, but I think that we can do a lot of things in this area, but there are some points -- think about the sender-permitting framework or the DKIM operation, there are some really important points we can put into the marketing and say we are really helping with reducing spam. And then we have a major problem. How much will the customer pay for? Nothing, of course. Next slide. What we can do is, or what I propose to do is to set up a verification process for correct operationing a signed zone. I, for myself, run a survey on signed DNS zones, and if I look at my database, I can throw out a lot of information in order to testify that the operation of the zone was made correctly in the past. I'd like to put this information into certificate for Web sites and allow the people who run the signed zone to testify -- to have a seal on the Web site saying, "We are doing good operation here." Next slide, please. In order to match the different operational issues, I propose to have three levels of such a logo. A simple one, it's correctly maintained zone in the DNS as usual and assigned. Second one is correctly linked so it can be used to verify. And we have operational experience in key rollover. It's my opinion necessary for -- qualified for advanced level to have experience in rollovers in order to react in an emergency. And then we have the most complicated case, I want to separate out, that when a (inaudible) key rollover including all the changes in the parent DLV zones. Next slide, please. I set up a Web site in order to allow you to register your domain data for free. And you will obtain an e-mail several days later containing a link to the logo you can put on your Web site. This logo is valid for one month. But it will reflect your operational procedures and your operational stability. And I do not put it into work at the moment because I really want your feedback here, and I like to change every possible point on this program in order to make it more successful before I start issuing the first logo. So next slide, please? What do you think about it? >>STEVE CROCKER: Thomas. >>THOMAS ROESSLER: So, Lutz, first of all, good having you here. Second, I think you're asking an extremely important question and that's whether there is a nontechnical business case for DNSsec. One of the problems we are experiencing in the CA market as used for TLS is a race to the bottom, or has been a race to the bottom, because there was no technical-use case for -- there was no nontechnical-use case for good registration practices, for example. I think with DNSsec what we're going see is that technically clueful, highly security- sensitive companies are going to deploy it. People who get it as a default option by their managed DNS provider are going to deploy it. Everybody else is not going to bother. And that is an argument that makes me really concerned. So I'm glad that you are thinking about how to sell DNSsec to the marketing department. That said, I have been doing work elsewhere on things like security indicators and browsers, on things like usability of security indicators and the techniques used to persuade people of trust worthiness of sites and the solution that you suggest, while it's probably highly marketable is also highly dangerous. If you think of security indicators and browsers, you will find a lot of resistance to giving up any additional real estate. Which means that, in terms of realistic deployment perspectives, this thing can only turn into yet another trust seal. Trust seals are marketable and they're highly effective to persuade people that they're dealing with the good guys. But they don't actually have a positive impact on the security of the stuff that's going on. You need to police them. You build an incredible audit infrastructure on top. And suddenly, we realize that we are arriving at precisely the mix of concepts that we had in the discussion between Dave and Steve in the last -- in the end of the last discussion. Because there is no way that a user will distinguish that guy has the DNSsec gold seal from that -- that guy is trustworthy. So we're suddenly starting to overload business trustworthiness on the technical infrastructure. Yes, from a marketing perspective and from a business case perspective, that is wonderful. From a security perspective it is a nightmare. And from an enforcement perspective as well. So my reaction here is the question is a good one. I'm concerned that the proposed solution is likely to cause more damage than good. >>STEVE CROCKER: Dave. >>DAVE PISCITELLO: I guess there are two things that seem to be conflated in your procedure. One is marketing. And in a marketing world, you know, trying to raise the visibility of DNSsec, I, actually, wouldn't mind if 10,000 hacker sites had DNSsec because there's an imprint that lots of people who are going to the wrong place would see. That's not the message I would want to carry, however. So from a security standpoint, one question I'd have about the proposal that you have is: What effort have you made or what plans do you have to subject your proposal to -- to people who would be able to tell you the ways in which it could be abused or, yeah, misrepresented or defrauded? Because I think the key here is really still registration services. If we aren't stopping people from, you know, from today registering domains with false credentials and we're going to go give that, give that opportunity to people who are impersonating and frauding and scamming, then this is relatively a pointless effort. Because we've lost the battle from the start. >>STEVE CROCKER: Lutz? >>LUTZ DONNERHACKE: There's no silver bullet. And all I'm proposing here is to make some people happy in order to go out and tell other people or tell customers to sign their domains. I'm not here to propose a way to solve all the problems we have all over the world. It's not possible. >>DAVE PISCITELLO: I don't want to, you know, overdebate this but happy is not a useful goal when we're talking about a security protocol. What we want to do is, you know, I'd rather be quietly pleased that the security is there than publicly happy that the security is not there. >>STEVE CROCKER: So with respect, Dave, you know, you're touching on one of the core issues about how do we make the overall system, actually work better. And quality of the registration data and fraudulent registrations is unquestionably a very serious problem. It isn't the DNSsec problem. And so the larger question, then, is that, well, if DNSsec doesn't solve that problem then I'm not interested or maybe it's even worse than that in the sense that bringing that out takes the eye off the ball of getting the real problem solved. This is kind of a long-standing back-and-forth in this community. All of that is a useful discussion but it's not exactly within the scope of DNSsec per se. And so I don't know that there's more to say about that except to redouble the efforts to improve the registration process possibly with the additional emphasis that not doing so in the light of DNSsec creates the -- gives the bad guys a little bit extra credibility because they can wrap themselves in DNSsec and the registrars should be unhappy about that process, perhaps. But it's a dicey problem. Lutz? >>LUTZ DONNERHACKE: May I ask -- to shorten the time here. May I ask you to raise your hand if you're satisfied with the levels so I have an impression that I'm on the right way on the technical base, and on the political base. Nobody, okay, forget it. >>STEVE CROCKER: I'll raise my hand with the caveat that there's details but the general concept is interesting from my point of view. Time is short and I want -- I promised that we would get out of here earlier. Let me bring this part to a close. Thank you very much, Lutz. And I want to close with a little bit of the SSAC report on DNSsec and a comment about resolvers and option at Comcast but not very much on that. Need just a second to get organized here. (Pause). >>STEVE CROCKER: Here we go. Okay. Some time ago the security stability Advisory Committee which had originally, some years ago, put a lot of energy into DNSsec and then we split off the effort into run along a somewhat separate track, said, okay, it's time for us to take a look from SSAC's perspective on what the status is of DNSsec. We issued a preliminary report and then promised to come back and say a bit more and this is that work. In our report 26, we listed seven areas of attention, protocol completeness, key rollover process, trust anchor repositories, implementation and deployment testing, performance and error analysis establishing metrics for success, end user application development and availability of DNSsec on commonly used DNS server platforms. I want to very briefly walk you through what we have learned in each of these areas and where the open issues still seem to be. With respect to protocol completeness, we've had standards documents now for, my goodness, I think three full years for the base documents 4033 through 35. Additional documents on key rollover and on the development of NSEC 3, that's the DNSSec hashed authenticated denial of existence. We've had DNSSec in use in both test and production environments in a number of top-level domains. And that number is growing at a nice rate. We measure time in this environment in ICANN meetings and this is the first in calendar 2009. I would think that in each of the next two meetings we'll see interesting new developments. There is some ongoing standards activity around the edges to increase the information that comes out of an API for those in systems that want to know what the nature of the errors are, some work in developing framework for trust anchor repositories and conventions for transferring secured domains from run registrar to another. In the areas of key rollover and trust anchor repositories which in a way fit together, identified four different ways to deal with trust anchor rollover, manually via TAR, for example, the IANA's ITAR, or DNS look aside which is a real-time version of sort of in the loop during the process DLV or automatically via the 5011 -- RFC 5011 timers process. There's a report available that examines TARs in some detail. And although that work is -- the initial aspect is complete, there's further work-developing consensus within the community. Actually, what that slide says is further work and consensus within the community that further work is needed but I can also tell you that there's further work on developing consensus. So on implementation and deployment testing, the report I gave earlier at the end of the first part of the meeting on broadband routers, our report is on SSAC report 35 and the details of what I've reported are in there. The second big bullet, SSAC report stimulated additional registry testing refers to the Comcast work. And there's more along that line that will come. On performance and error analysis, these numbers, I should say, with a strong caveat are my numbers, not completely validated but I think they're nominally in the right range that the footprint inside of name servers, authoritative name servers increases somewhat on the order of five to 10 for a fully assigned zone and the answers are increased in the range of two to five times, very broadly. Those may seem like large numbers. They're, in fact, quite tolerable in almost all cases. Computation time inside of the name server doesn't increase very much at all because of all of the heavy-duty arithmetic, the signing process is done in advance, and there's a separate set of numbers associated with that but they're well under control. Less information is available about the validating resolvers and I think that I promised to say something separately about Comcast's experience, I'll just say it here. The -- they haven't yet published any numbers, but the basic experience is that having a validating recursive resolver in line operating all the time they have not experienced any serious issues at all. As far as I know, no real problems. We will be getting more data. And one of the things I'd like to do, I don't know if I can make sure to get it done but in my thinking about what we should do in this forum in Sydney is to try to bring more information along that line into visibility. For end user application support, no formal survey yet. There's open source DNSsec validation libraries, patches for Linux, BSD and so forth. Microsoft announced support for DNSsec some time ago and will be making additional announcements. They have not yet said anything about end systems but they've said about server software and it's quite he felt that the rest of the puzzle has to be -- the rest of the product line has to be fleshed out and I think the action will move toward browsers and mail systems by and by. In deployment scenarios -- and I know it's hard to see this slide from the distance -- the validation can take place in the first scenario at a validating recursive resolver, operating, say, at an ISP or at the edge of a large enterprise with a presumably secured or relatively safe pathway between the end system and that validating recursive resolver. This is sometimes called "the last mile problem." There's a couple other resolvers that move the validation process closer to the end user. I think what we're going to see is a very large preponderance of the first scenario. Quite a lot of attention to the latter scenarios for the technically more astute and early adopter community. With respect to availability of DNSsec name server platforms, there is a survey. Oh, Dave just disappeared? I was going to turn things back over to him. But he did the heavy lifting here. 11 of the 17 products now support DNSsec, three commercial manufacturers indicated they would support DNSsec, by the first quarter 2009 which is -- we're in the last part of this first quarter 2009. So -- this data was prepared some time ago. And it will be -- we'll update that. But things are moving along in this area. So the main open areas are that trust anchor distribution use is one of the frontier areas, the broadband firewalls and routers need to become a bit more mature and integrating DNSsec with recursive resolvers is another of the sort of active areas. The deployment experience is accumulating. And we're beginning to work with both registrars and operators of recursive resolvers and gain more experience there. That's the short sort of fast-paced survey of the open areas that we had been concerned about some time ago. Any questions? Any comments? Jonne? >>JONNE SOININEN: I have a very simple question. As you were looking at the support in different platforms, including windows and Linux and BSD, was there any indication from platforms like Linux and BSD if they're going to introduce validating resolvers on their platform as a client? >>STEVE CROCKER: I don't think I remember the answer specifically but my impression is that it will come along quite naturally. Anybody else want to comment on that? Any other questions? Okay. Let me bring this session to a close with two things: First of all, a Hardy, thank you for all of your participation. It's very important to have this amount of attention and I hope it's been helpful for you. And the second thing is, picking up on that last point is it would be very helpful to have feedback about the utility of these sessions and how to shape them to be useful in the future. I think we're doing a good job as we are, but I think it's also very important to take inputs and -- because a lot of work goes into putting a session like this together. We have a quite good team of people. And I want to make sure that the resources are applied in a way that's most useful to the people who are coming to spend their time here. So we have -- this is March. The next ICANN meeting will be in Sydney in the last part of June. And that's a relatively short distance between meetings. I can tell you that, although the -- they average four months a year they vary between three and five months and the difference between three and five months is enormous when you're trying to put meetings together. I got a rise out of Crystal here. So if you're so inclined, please provide feedback almost any way you want, buttonhole me in the -- or send me mail or send mail to anybody that you know, it will get back to us. And we'll -- say what it is what you want or what you don't want or format changes or anything like that. And particularly specific topics are most helpful because then we can arrange to try to bring that information and stimulate that kind of interaction. So with that, let me, again, thank you all for coming and I'll bring this session to a close. And we can enjoy the rest of our time here in Mexico City.