 Good afternoon, everyone. My name is Mehmed and I work at ICANN, DNS Operations. We are going to talk about some DNS security today. We have some speakers. As I said, my name is Mehmed. I work for ICANN. Dr. Richard Lam works at ICANN as well. And we have Sandy from Nominum. We have Ken Silva of Verisign. And we have Dan Kaminsky from Recursion Ventures. Did I say that right? All right. So I'm going to actually have Dr. Richard Lam of ICANN start and talk a little bit about DNSSEC and the recent happenings. Okay. That works. Good. Hi. As Mehmed said, I'm Rick Lam. I'm the program manager for DNSSEC at ICANN. Well, first of all, I was told that this white shirt is just completely wrong, so I need to get rid of the white shirt. I did have a suit. I wasn't going to wear that at first. I think, actually, if the camera can zoom to show what he's wearing, it's the DS record for the DNSSEC route. That's the hash for the root key. That's for the signed route. That's of July 15 live. Anyway, well, back to the formal program. So, you know, ICANN, I don't know if you guys know what ICANN does, but ICANN is involved in coordinating the unique identifiers on the Internet. You know, make sure people don't pick the same domain name, the same IP address, stuff like that. You know, I think we do a pretty good job. But last July 15, one of the biggest changes as Vint Cerf, one of the fathers of the Internet, has actually confirmed his saying is that one of the biggest changes in the last 20 years happened. We actually signed the route of the DNSSEC just to get an idea, basically, of how many people here in the South don't waste your time. How many of you guys know about DNSSEC? If I say DNS, what? Wonderful. Oh, my God. Awesome. Okay, I can skip all this. All right. Anyway, you know, in our humble way, and this was a joint effort. And this was a joint effort I need to make clear with Verisign and Department of Commerce. But this is one of the times we've worked really well together in this and actually have created this signed route. It's kind of a humble thing. It's really just generating one key at the top of a PKI. But we involve people from all over the world to bring it into it because, well, of course, you know, who's going to say, trust me? So, you know, we made sure we had 21 people involved in this. And so far, we haven't seen any problems. And it's one of the things that's hard to convey about this humble event is that this has opened the door to a whole range of other applications and other things that people can do. Because now we have this single source of trust. Time will only tell if it really is a single source of trust, you know, if people start building their applications on it. But now we have this opportunity. So it is one of the biggest changes. And hopefully, I'm sure Dan will talk to this. But, you know, hopefully this will create the opportunity for people to create solutions for some of the things that have been plaguing the Internet forever. I mean, there was a great line Jeff Moss gave at the Black Hat Conference that said, you know, what security have we really done? What have we really solved? You know, what have we already created in the years of the Black Hat Conference? And not much, but here's one example. Here's a concrete example of something that they can be used in the future. And so we're hoping this will work out fine. And later on, the questions, the answers, please just ask me anything you want to know. And you'll remember about how the system was designed, how we generate the keys and that whole process. That was something I was involved with. Thanks. Yep. Thank you very much. Sandy? Sandy Woolborn from NAMOM. It is extremely interesting that, you know, we got the route signed. That's a huge thing. If people know anything about DNSSEC, it's been like, it's been kind of cynical in a way because it's been 15 years that people, you know, there were, I don't know, two or three designs of it that came out. And finally, some people have agreed on it. But we're just at the start. Like, this route thing is a big deal, but it's just the start. I mean, .com won't be signed until March of 11, right, Ken? And, you know, I think the cool thing about being here is I'd encourage people here to take a look at it because we'd rather find out the problems sooner rather than later. So break it now. Break it now. There you go. Ken? Thanks for that, Sandy. Hey, I'm out there on the... We have to actually break it. Yeah. It might be broken. Without the labor and the DNSSEC element too much, it is a pretty important milestone and we get asked a lot, you know, why did it take 15 years? And even at that, even after you decided on what the standard was going to be, why did it take so long to roll out? DNS is a pretty important part of the internet infrastructure and it's an absolutely critical part. And I don't think anyone who was involved wanted to just sort of roll things out without understanding the impact that it would have on various pieces of network hardware. Throughout the years, network vendors, security vendors, firewall vendors, et cetera have, you know, tried to add value to DNS packets as they come through the network. Load balancers, those sorts of things. That if something was on port 53 and it was purported to be DNS, then it could only be 512 bytes long. And that has changed. So we spent a lot of time really working with ISPs and working with various vendors, hardware and software vendors, to make sure that the subtle little things in home routers and consumer routers, et cetera, didn't try to block those elements. Now all of the pieces of DNSSEC are not actually in place yet. While we've signed the route and many top level domains are beginning to sign there, there's still much, much more work to do. And Dan has done some work in this area. There still isn't a good way for the end user to actually see the benefits of DNSSEC just yet because all of the bells and whistles haven't been fully deployed down at the client level. So as those start to change and those start to become more visible to the consumer and to the end user, I think you'll see the benefits of DNSSEC really start to take off and adoption will begin to take off. We don't expect every name in the comm zone or the net zone or any zone for all that matter to be signed or every delegation be signed. But we do expect that as the tools become more prevalent and as it becomes easier and easier to adopt, that people will adopt it as a normal course of events. Now that may take another 10 years or it may take 10 months for all we know, but we hope that it adopts quickly. We hope that the client side tools begin to take off and that DNSSEC becomes an integral part of the infrastructure for not just passing domain name information, IP addresses, but for also passing other things because now we have an infrastructure that is a trusted infrastructure from the top to the bottom. Is it going to solve all of the problems around the DNS system? Absolutely not. In fact, in some ways it may actually create some interesting things from an infrastructure standpoint. But there are many other elements other than just the resolution of DNS, which are part of the DNS system. And while the last two years I think we've focused a lot of attention on talking about the resolution piece or the DNS servers themselves, the other elements still need some work and that is the registration process, for example. You can make a change and then wind up signing that change. Someone could maliciously make a change and then sign that change and then push that out. And then we would have a bigger problem because we actually trust that. With over a thousand registrars that are registering .com domain names, there are a lot of points of failure there where the system could be compromised and we're going to spend probably the next two years focusing on how we can tighten that down with multi-factor authentication and some things that we can do to help protect against social engineering. Okay, so now that you didn't hear a single thing I said, I'm finished and I'll hand it over to Dan. Dan? I think I really understood what I was getting myself into. I'm Dan Kaminsky. You don't know me. I've been speaking here at DEF CON for quite some time. I had Chief Scientist at Recursion Ventures. And about 18 months ago, I think I was like most engineers when I looked at DNSSEC as way too much work for no obvious benefit. Yeah, it turned out I was wrong. This technology is awesome. For the last 18 months I basically said to anyone who's asked, wait, wait, wait, this route signing is going to change things. We're so used to all these technologies coming out and people hyping them and then being, you know, whatever. No, this one's actually pretty cool. So we're releasing a name server. We're releasing a name server and we're releasing a bunch of code. We're effectively here to do things like, how about we deploy DNSSEC in two minutes? How about we get DNSSEC support in every open SSL-based application by running a single command? What if you could get the browser lock immediately in Internet Explorer and Firefox and Chrome based on DNSSEC, making self-signed certificates work and work securely? What if you could actually recognize email as signed and actually easily validate that signature? What if getting PGP keys was not such an utter pain? Wait a second. All of this is not just in theory. All this is not just stuff we could do. It's stuff that we're able to do today. In security we have made a tremendous amount of promises about how we think the world could work safely. And you may have noticed or you may not have, but a lot of the code that's been supposed to work been supposed to be helping us defend our networks, been supposed to be helping us fulfill our promises. Yeah, that stuff doesn't work in the real world. It stops scaling real fast. This DNSSEC stuff, DNS has been scaling like nothing else for 25 years. We'd be lucky to have security working that well. And it looks like we got pretty lucky. Thank you, Dan. I would like to add something quick and then we will move on to the questions. If you have questions, please move on to the mic. That's located in that direction. This is, DNSSEC obviously is something that's been worked on by IETF, Internet Engineering Task Force for many years. So everybody over there deserves a big applaud and big acknowledgement about the fact that they have been volunteering and working on this project and they are the ones who made this technology come to the reality. This is one of those cool things that doesn't have an Apple logo, but still very cool, I believe. So it's a really cool technology. So I would like to move on to the questions. Any questions? Is it my understanding that the signing key was split up and given to individuals so that the event of a meltdown could be reconstructed? I will have Dr. Lam explain that more clearly. That's a great question. Thank you very much for asking that. Like anything like this that's high-profiling, sometimes it gets sensationalized. What is split across seven smart cards is the encryption key that is used to encrypt the private part of the root key. That encrypted private part of the root key is another smart card that ICANN controls and has, of course, duplicates of. And we back up copies of in various Class 5 GSA safes that we have. So the idea is that you need five of those cards to come together and the encrypted copy of the KSK that's sitting on a card to recreate the private key inside a crypto device, a hardware security module inside a crypto device. And this is something that's only going to happen if all four crypto boxes on both coasts completely obliterate themselves. I don't know. There's an earthquake on the west coast and a nuclear explosion in DC. Actually, it's not quite in DC. It's in Culpeper, Virginia. None of this is secret, by the way. It's all on the website. So that's what they are. Those cards do not have pieces of the root key, period. So no elaborate Hollywood scheme of, you know, intercepting them all and making the duplicates and anything like that. Well, I mean, you'd have to, that's why it's five of seven. You'd have to go across at least get five of these guys and make duplicates of them. But they still would not have the root key. It's still got no value. But, you know, on the flip side of that is also that who's going to trust ICANN, right? So what we have, this encrypted version of the private key, we have no value. I mean, this is the standard. And I know you guys are very expert at this. But this is, you know, where we've tried to gain some security in this by doing this M of N scheme. Does that answer your question? Yeah. Thank you. Okay. Yeah, the idea behind that I think is sound. And that is that early on there was a lot of discussion about, you know, who actually can generate the keys and who actually, you know, can decrypt the keys or encrypt the keys, etc. And it was decided pretty early on that no one entity would alone be able to do that. And it would have to involve a conspiracy of a large number of people in order to do that. And the key signing ceremony, I think, was pretty elaborate. And there were a number of people there for that. And there does have to be a certain number of people involved in order to actually produce those keys. So I think in general it was a good, well thought through plan in that no one entity would be able to control the whole thing from start to finish. So there's an interesting reason why a lot of authentication systems fail. Anyone here familiar with the phrase Federation in the technological sense? So the whole thing is, if you want everything to work, you need a single route. I'm just going to say that as an absolute statement because we've seen ten years of people arguing otherwise and failing miserably. So you need like one single source that everyone trusts. The problem is anyone who normally becomes that single source turns into a monster. This has happened time and time again and believe me there's industry after industry where I can show you it being true. They're like, look at all this power I can make a ton of money. But not in the DNS system that's never happened. The interesting thing about the DNS architecture is it has a property of what we're referring to as a silent overseer. Structurally there is a single route but that route is so constrained both by the technology which is the best delegation system that we have out there and by enormous amount of politics and political checks and balances. And some people think it's a bug. It is a feature. It is because of this ability to have a route that everyone can trust but it itself is constrained that we're able to build out these systems and actually have a very strong neutrality in how the system is operated. And so this splitting up of seven keys, it's less about, and I'm one of the people who has one of the keys by the way, it's less about a power that I have and more about a power that they don't. It's so the only way where that key material could be abused is if all of us came together in some kind of crazy international conspiracy. It does not happen. Thank you. Before moving to the other question I would like to add some... It's very hard. So I want to add that there were actually 21 trusted community representatives who took place in these key ceremonies. I was the ceremony administrator on behalf of ICANN and there were 18 countries represented in those events. So it wasn't only US base, it was people from China, Czech Republic. I don't remember exactly where everybody was from but there was a lot of countries, 18 countries represented. So one more thing I would like to remind. I believe most of you read a lot of news this week about a reboot key being, you know, available and all. There's no reboot key. I want to assure you that there is no such thing that I am aware of. So what people were trying to talk about was the RKSH, basically what Dr. Lam just explained. Next question. Dan, you said that today we can use DNSSEC to distribute self-signed SSL or at least authenticate self-signed SSL certificates and PGP keys. Did I hear that right? Yes. So I guess I was asleep on the ball the last couple of years looking at this. Can you just talk briefly about any new RR types or how that's done? So the fundamentally interesting question is DNSSEC allows you to release bootstrapping information. Normally this just comes from DNS. You want to connect to an IP address. You don't know what it is. You can bootstrap and find out what that IP is going to be. DNSSEC upgrades us from finding an IP to finding out other stuff, certificate records, anti-spam records and so on. The precise question you're asking is, so what does it actually look like on the wire? What are the actual formats? That is a raging debate, which I'm not getting myself particularly into. So the piece that I've worked on, the piece that we're actually releasing code for is we've got deliberately incorrect representations of the information. So we'll have, this is a very rough way of saying, oh, you want the SSL certificate, here's kind of what it looks like. This is the wrong way to do it, but it's okay. We're showing it's possible to get end-to-end trust of small bits of key information delivered from the delegated DNS into your desktop so that I can know whether to take trusted paths or not. So if I wanted to get in on the debate on this standard, now's a good time since it's not set. Now is a good time. That would be a good time. Yes. Thank you. Any question? Yeah, I was interested in the registration issue. I mean, when we come into basically any certificate or any signing scheme, you're really only as strong as your weakest link, and you have a lot of registrars out there. Can you talk about, I've worked with a lot of the registrars, and quite frankly, a lot of them are really stupid. I mean, phenomenally stupid. I had a tech support call a couple months ago where I talked a guy with root privileges, one of your domain registrars. I mean, we'll leave the name out of it to prevent a lawsuit. But basically, we're a talk to guy with root privileges into running a command. He had no idea what he was doing, running a shown minus R command for him with root privileges on a box. So I have to assume that the same kind of, and this isn't even social engineering. I just called up and told him, hey, I've got an account. I need you to do this for me. He said, okay, sure. No problem. And hey, what did that do again? So I guess my question really comes down to what protections are we putting in place to prevent the dumb register out there from starting to sign some of these certificates? Because I think at that point, I know we can talk about revocation, but I don't think that's, I mean, it is practical if we find out that they're signing bad certificates. But if they have bad practices in the first place, I think the model starts to fall apart. Has somebody talked about the protections put in place or the verification of the registrars? Yeah. So I'll start with that. I didn't have something to add to that and maybe break this as well. But so I agree with what you said with respect to, you know, there is a large number of registrars out there. Some are better than others. The opposite extreme of that is that there are some very, very, very good ones. As a matter of fact, probably the most well-known of them are very good and have good security practices. The registration process, unfortunately from a business model perspective, often tends to lean towards ease of registration more than anything else. So it's about volume more than it is about quality, if you will, particularly some of the smaller ones. Now, that doesn't mean that they deliberately don't want to have good security. It just means that, you know, in order to be competitive, it's all about, you know, one-click sign-up and moving through and adding things. As with any system, and the same applies to digital certificates as well, that there are some CAs that are better than others and some that do very rigorous checks and some that don't. And so I think we're going to wind up in the same sort of dilemma when it comes to signed delegations. And that's going to be how good is the registrar behind that. And I think over time, the reputations of the registration system will begin to come into play and become more important. Where today, literally everything is self-signed, if you will, once you get beyond, you know, COM, let's say, or EDU or any of the other signed top-level domains, although COM is not just yet. But then everything's pretty much self-signed. The trust system is that I trust you as a brand or I trust you as a business, and so therefore I'll trust your signature. But ultimately, it may become more and more important who additionally signed that than just the fact that you signed it. So this kind of blew my mind. There is a fundamental structural reason why DNSSEC ends up having better properties with bad web. DNSSEC can deal with bad web interfaces far better than X509 can. If you have the best CA in the world and they issue you a certificate, LEND certificate shack down the street can also issue someone else's certificate, and their cert is just as good as your cert, even though you spent all that time, money, and energy getting the really good and strongly validated certificate. This means, unfortunately, X509 as a structure ends up being erased to the bottom. When certificates first came on the scene, everyone did strong validation, and then one guy did it a little weaker, and the next guy did it a little weaker, and the next guy did it a little weaker, and it went down pretty far. And that's just something that has to happen when everyone is able to operate in the exact same space at the same time. What's interesting about DNS, and this is fascinating because you know it was not intentional, but what's fascinating about DNS is you have this entire network of registrars, and they handle the web interface, they handle the SQL code, they handle all the stuff that is empirically in the field been what's been getting attacked, honestly way more than cash poisoning has been. If you have one company like a mark monitor or a CSC or something, and they are your registrar, these guys are massively professional operations, and they watch out for what's going on. Importantly, as long as your name is registered through a particular registrar, no other registrar can impact your name. They just don't have the ability because the actual registry, the Verisign Com, only accepts updates from the one trusted registrar. So because you have what we call the exclusionary property, you have a thousand registrars, this one's a little more secure, this one's a little more secure, this one's a little more secure, it becomes a race to the top. That is how you structurally create a secure system. Thanks. Which is not, I believe, only going to make sure that the users are getting the best value, but also at the same time the best service. We want to be able to reward the registrars that do the work that protects users, and that is fantastic. Yep, next question. Building on the exclusive property, you talked about this a bit at your black cat talk, Dan. If you go one level higher in the stack, it's sort of not the one machine trusting another machine, you got the name in there correctly, there's no questions, but once in a person looking at that from address in an email, looking at a website URL, not one of us, one of those other people, there's a lot of attacks. Let's say if you look at technologies like SPF, the reason why SPF doesn't block all spam is not due to rampant DNS cash poisoning, it's because people say, oh, bank-secure.com, I work with, I go to the bank, so that must be my bank. What, are there specific, I think, you know, we talked about EV certs, brand protection companies sort of going out, taking out these sites, are there specific proposals, are there specific standards for getting EV cert technology into DNS sec, are there ways you can do this in a really secure way where it's not just going to be more whack-a-mole going out looking for all these cousin domains, IDN names proofing, all of that kind of stuff? So, a lot of people think now with DNS sec we don't need the certificate authorities. And it's not true. DNS sec protects domains. The certificate authorities identify brands. Domains and brands are not the same thing. With DNS sec we can say the only certificate in the world that is valid for this domain is the one with this particular hash. Now, if it turns out that that particular certificate is an EV certificate, what we now have is a combination of two good things. We have extended validation identifying the brand of the website, and we have DNS sec making sure no other CA, no other certificate, no other code can actually interfere with that one extended validation cert. Last year, Mike Suspin and Alexander Sodorov actually demonstrated tremendous attacks against extended validation sites if you could do something as simple as getting a non-extended validation certificate for the same name. DNS sec stops that. Extended validation is interesting technology. Right now it's in the browser. Eventually we want to see it in email as well. Why shouldn't you be able to know from an extended validation standpoint that you got an email from your bank? I think what's incumbent upon the people in the industry that sort of create the processes and create the security mechanisms no matter what part of the infrastructure it is, I think we have to realize that if it's too hard for most people to implement, they will find an easier way or something easier to implement that is less secure. It is our responsibility to come up with good security that's easy to implement, and I think Dan demonstrated some of that a couple of days ago with his talk at Black Hat where all of the talk was about, including from me, by the way, was about DNS sec is hard. It's going to be really hard to implement without the right tools and seamless and easy for the end user. The feedback is good because I can tell you that if the end user has to go look up which registrar registered this name, it's never going to happen. It's never going to happen at all. The real estate in a browser is so expensive. The little padlock was hard enough to get in there. Turning the bar green was a lot of pixels that we got. But I think that it has been a mistake that people who have been involved in computer security have made from the very beginning and that perfect has always stood in the way of good. And a lot of good technologies were never implemented or good ideas were never achieved because it was just too doggone hard to do. And I think if we have learned nothing over the last 25 years, we should have learned that if we don't make security seamless to the user and that the user doesn't have to think about it, it just happens. And that's the best part of the DNS aspect of this. Is it so much if it happens in the background and it's done automatically that the user doesn't have to engage with. And I think we need to build on that and do as much as we can securing the infrastructure and securing the transactions that the user never has to interact with. They just know when it's not working and it's going to work and it's going to work well most of the time. And that's where the challenge, I think, to the industry is, yeah, we've got a lot of crypto algorithms that are good and easy to come up with. But I tell you, if you ask every user to start generating keys and stuff like that to do SSL transactions, it would never have happened. And we'd still be, I mean, user names and passwords are at least 15 years out of date, okay, 10 for sure. But somehow end users have never wanted to adopt a tougher technology because we haven't made it easy enough for them to do that. Anybody else want to answer this? We are... Change is out of the bottle, let's do it. Let's build it, that's great, perfect. We certainly are looking forward to demo versions of dense software. Very exciting. Next question. So the root key is obviously physically protected. What protections do we have against crypto attacks when our attackers can have a botnet of 100,000 computers or more or anyone with a financial incentive, say governments, that have the kind of power, the massive server stacks to try and generate a collision against your hash or just a crypto attack against your root key will it be changed every so often? Or is it just a very long key length? What do we have going on here? It's both. It's all of those. You could do an answer. Yeah, Dr. Alam, could you start? It's an RSA 2048 bit key. We have plans, no specific plans, but plans to roll it somewhere between two to five years. Currently, a lot of the crypto experts, I would hope that it was around here or maybe some of his pals were around here, but that's considered a pretty reasonable time for 2048 bit keys. So we do have a rollover mechanism that we hope we don't have to ever, ever use. But again, if there's some report in the crypto world that says that we should, we can roll the key and do that hopefully seamlessly over the next, in a few years. Right now it's a very manual process, but there are automated mechanisms that the IETF, you know, who developed the DNS like protocol is also trying to press forward. A quick follow up. Do we have a key revocation protocol? If it is compromised, can that key be invalidated immediately? Yes, we do. We have a process for that. There was a fair amount of discussion about what key sizes would be used based on what devices and what compute horsepower would be available to the systems that we're querying in. So the key link is sufficiently strong to survive good attacks and thus far that key link has not been cracked. But we expect people will try. We fully expect that they will try and that's why we've used tried and true algorithms which have been under attack for a number of years. Specifically, we used the latest hashing algorithms so that those are sufficiently secure today. But there is a protocol in place that should the key ever become compromised, there is a process in place for revoking it and replacing that key. Thank you. Maybe he wants to speak. Yes? Well, I think it's not only the root key that is in that situation. It's the keys for everybody. I mean, there are established rollover scenarios and there's also established protocol or at least conventions for trying to minimize the amount of communication that you have with your parent zones in order to update the signatures on your individual records say that if people are coming after you and, for example, you want to use a shorter key link. Just as a note, in X-509 we talk about revocation. We think we have revocation. We look at everything that's supposed to implement revocation and it always turns it off because the performance is terrible. In DNSSEC, yeah, you're looking stuff up anyway. That's kind of the point. Here's the deal. In X-509, no one wants to say my website goes down if Verisign servers go down. Sorry, but that's the truth. And so we end up with everything turns off revocation checking except for EV where it's contractually obligated. In DNSSEC, if your name server goes down in your operation center, you know what? That's on you. You're kind of okay with your web server going down too. And so we have this really interesting situation where in DNSSEC you can have revocation. You actually kind of get it for free because you're always refreshing your key material. And so revocation becomes as simple as the next time you refresh your key material, there's a new key there. It's effectively for free. I don't know that I agree that everything turns off revocation. We're getting currently two billion revocation checks a day just for our certificate. So I think that's a pretty substantial number, but I don't disagree that some systems do turn it off because it does hurt the performance. At the point where there's two billion, okay, not everything turns it off, that is correct. One follow-up just to the last question. Would you like to address it? Is that there are actually two keys in DNSSEC. There's this top root key, that's 2048 bit, that signs another 1024 bit key that gets rolled four times a year. So that gets changed very frequently. Just thought I'd throw that in there. Next question, please. Now that you've fixed DNS, what's the next fundamental part of the internet that you're going to fix? Netware. Well, since we are running out of IP spaces, perhaps we will fix the IPv6. Not that we will fix, but we will all move on to IPv6, I guess. Well, there's also the whole routing structure. All we've done is taking this one small little phone book part here and trying to secure that. There's this whole set of IP addresses and routing tables, and that's something called RPKI, and there are a number of people working on it. There are always some policy issues with things like this. The technology is there, people have developed a lot of protocols on it, and I recommend you talk to see some of the IETF things under their CIDR group, S-I-D-R. But I think with the routing infrastructure and BGP in particular, it presents an interesting challenge because the entire internet has relied upon that infrastructure being operating in exactly the way that it operates today. To begin to add security to that, every router on the internet has to implement it or it doesn't work. And so the challenge that we have today is that it's not difficult for someone in Pakistan to redirect YouTube.com to Pakistan because today it relies on a really a handshake and a slap on the back that says, okay, only this AS can announce this address block, it's only if the ISPs actually enforce it and not all of them actually enforce it and validate that that AS is authorized to announce that space. So until we have some security around that, whether that's a signed BGP announcement or whatever it is, and there are a number of standards that are being worked, it's going to involve the entire internet community and the ISP community to implement that change. So that's not going to happen suddenly, but thankfully the work is being done today that's laying the foundation for that. Perhaps not the example you gave, but the web forwarding kind of issues which similar things has happened in China with one of the root servers and made news, you probably heard, like forwarding the IP address or forwarding the resolver to a different IP address. What exactly happened in China was that iRoot was suddenly resolving to facebook.com which was very interesting within China, within some more region and it was actually detected by some community in Chile in South America and this made a big news and these kind of things obviously will be avoided when DNSSEC is implemented because it will just not work, it will just not resolve. So you were talking about before how part of the beauty of DNSSEC is that it can be doing the validation in the background, the user doesn't need to worry about it, but aren't we quite a ways off from that? Until everybody starts signing their DNS records I don't see a lot of pressure to kind of move people to start doing that because it's sort of like it works right now as far as most people are concerned. So don't we have to have like client support for doing things like similar things like the padlock so that those people who do start implementing this it'll show up and we can start distinguishing oh this is more secure than this, push people to implement it Have you seen that in any clients as of now? Is there any movement in that area? I think there's three things that have to happen, right? You have to get the domain signed and that's one of the reasons why signing the route is sort of important because it's kind of a chicken and egg problem. If you don't have signing happening then there's not going to be any incentive for clients or ISPs to actually turn on the validation in their infrastructures so they have to believe that it's become important and I think and that process is ongoing because you know if you go to the average ISP and tell them hey turn on the NSSEC validation today they're going to go like why should I do that that's just going to cost me in terms of infrastructure and what do I get economically out of that so that's been one of the historic issues, problems, et cetera beyond just getting the signing infrastructure going so getting the signing infrastructures first the resolving of the structure second I think the point of Dan's talk two days ago was basically well it'll be great if we can get it across all of these large infrastructures but let's start looking at applications that can actually do things on the client sooner rather than later trying to you know with the various prototypes and so forth that he showed where maybe not everything is figured out but hey it's not as hard you know I think the point he's trying to make is it's not as hard as it might be so let's get some applications going and that will convince the rest of the resolving community to go ahead and deploy the NSSEC Thank you Are there any bright spots in that right now like Firefox extensions or anything yes there are some add-ons that you can download for Firefox that would validate against the NSSEC and that would actually show a green light if the NSSEC validation is correct And does that require your DNS infrastructure to be handling that or is that handled from the plug-in well obviously end or go home what's that end to end secure or you're not doing enough that is the bar that we have as a community and though DNSSEC has a lot of support for looking at your resolver making sure the resolver has it there's tremendous value to DNS resolution itself making sure the resolvers are not cash poisoned that's what the technology was originally designed to do what we deployed two years ago was a Band-Aid and correct cryptographic data for just normal records DNSSEC fixes that same roller for a bug the value comes from being able to get all these certificates for recognizing websites for recognizing emails for being able to log into SSH servers this is where this stuff gets particularly valuable and like seriously the we're going to show just how easy it is to patch DNS support DNSSEC support into applications at the end of the day I've probably spent ten times as much time making the rest of the app realize they can actually trust DNS than actually doing any sort of hard DNS work it's kind of cool thank you I am going to close the mic and answers should be limited to two minutes so last question then Dan you were talking about how passwords, username passwords been obsolete ten, fifteen years is there any thought to maybe getting Microsoft, Apple the other OS companies on board having some sort of public key infrastructure for the users maybe smart card with every laptop something like that and authenticating the users via DNSSEC so we refer to this as the domain key infrastructure one of the things that actually we haven't implemented yet so we have a preload library for open SSL that takes every open SSL application it makes it just immediately work with DNSSEC no code modifications whatsoever where this is cool is you can run this against a patchy and suddenly a patchy client certificate checking inherits DNSSEC now the challenge is of course the browser UIs for SSL certificates aren't necessarily beautiful so there's some work to be done thank you next question this will make it a lot easier for sites to use SSL I think once everyone's using SSL how are hotel networks going to man in the middle of me and show me a captive portal and make me agree to terms of service before I can check my email that's an absolutely great question you'll have to come up with more creative ways of getting your credit card information I think but it is kind of interesting because as we've been delving into this over the last several years looking at DNSSEC as the deeper you dive into it and the deeper you're into it you travel around at different conferences and you see the way that they sort of redirect you from one page to another or when you travel to another country and perhaps there's sites that they prefer that you not go to and how they direct things it's amazing how much DNS is used for that and so you start to wonder how are they going to be able to do this following all this stuff and I think that they're just going to have to come up with more creative ways of doing that and rather than play man in the middle it's just going to have to be an overt redirect rather than that some of the solutions I personally seen being developed are using multiple VLANs and using one VLAN where you actually redirect the user to get the credit card payment and then once that is completed you actually move user to a production VLAN where the production VLAN has name servers validating against DNS enabled servers I guess you could also have a sign telling people which site to go to and have that site use HTTPS I think we're going to have to give people I think the browsers are going to end up having to have a first class feature for this is an URL to go to to pay whatever needs to be paid because lacking that feature the hotel community has just been like well we'll just take every website how you doing so let's give them an actual first class way to do it because we do what you got to get connectivity Skype's law and I think this is probably going to have a rather interesting effect is in areas of the world that choose to censor the internet in certain ways using DNS to do that I think are going to be challenged in specific ways because those answers are not going to be properly signed so maybe you want to wait for China to sign an answer saying China has blocked this or maybe not maybe not next question and if you guys have more questions we will be in the track one track one Q&A room I forget the room number but it's 11 11 apologies, thanks for reminding that we will be able to receive more questions if you have any more questions and we would like to get into more details on some subjects tell me a DNS new but what are we actually signing the DNS server itself or the IP address and the middle men men in the middle attack you're sitting that hash over the wire what makes a hacked router and you're sitting in the same hash with a different IP address so look toward that it's a chain of trust so the signature is created using the private the digital signature made over the IP address record is made using the private key of that domain so if you change the IP address there's no way you're going to be able to validate that signature with the public half of the key associated with that domain name I'm happy to work this out with you so that's how you if someone changed the IP address and gave you the same hash well it's not going to work they'd have to re-compute the hash and the only way to re-compute the hash would be to have that private key which no one has except that domain name owner it's going to be interesting to see when you have DNS hosting companies like GoDaddy and a lot of DNS and a lot of IPs how are they going to handle that when you're changing an IP once an hour or DNS fall over and there's other and content delivery networks for example they're continually changing these IP addresses I think that's something that Dan also has an example piece of software for as well but you can just do signatures on the fly or do something else creative but that's a really good point to me that I've had these systems in place that have dynamically changing things and now they have to implement DNSSEC government agencies for example hard to government agencies and they desperately are looking for solutions that would allow them to you know make this I think that's going to be a big problem with changing IPs thank you if you guys have more questions we'll be in the room 111 I would like to thank everyone for attending and thank you very much for coming and have fun