 So, my talk tonight is going to be about two entangled topics. One is about certificate authorities and the security of TLS and SSL and HTTPS. And the other is about protection against various kinds of attacks, including connection blocking and certain kinds of censorship attacks. These things turn out to be somewhat connected to one another. And hopefully this is a contribution. At the moment, this is a talk about a design document. We haven't built it yet. It's a vaporware talk. But we want feedback and criticism of the design before we go and build it, so that if we do build it, we don't break the internet in some unforeseen way when that happens. So I'm going to start with three and a half problems that we'd like to solve. Problem one is that although HTTPS and TLS and SSL produce lots of nice, tasty security, they're also kind of like Swiss cheats. There are holes in the security. And the holes are mostly around the authentication system, or at least the big structural hard to fix holes are in the authentication system. And I gave a talk with Jesse Burns last year here at CCC about some of those problems. That was a talk about the SSL observatory, where we scanned 443 of the public web, all of it, IPv4, every address, 4443, we found there were hundreds of certificate authorities that were capable of signing a certificate that would be good for any domain. So you could get a certificate for mail.google.com or addons.mazilla.org or ccc.de from any one of these hundreds of places, which means that an attacker would only need to break into the weakest one of these hundreds of places in order to get a certificate. It turns out that even if these hundreds of places do a really good job, they put their private keys inside hardware security modules that are super secure and they're very good implementers, they don't write bugs, they write perfect code, they defend themselves, there are other problems. What these certificate authorities do when they're getting it right, many of them is called domain validation. And the process there is that Alice wants a certificate for mail.google.com so she can be httpsmail.google.com. And so she goes to a certificate authority and says, hey, I'm mail.google.com. And they say, okay, let us check and they email root at mail.google.com or maybe the technical contact in the DNS entry. And they see, is Alice able to click a link or find a secret from that email that they sent her? And if she can, they'll issue a certificate for mail.google.com. So this creates an attack surface that's bigger than just the CAs themselves. It's their routers, their ISPs routers, DNS servers all over the place, the ISPs use, the ones that maybe exist on the other side at the server end. And so really, instead of looking at just this attack surface of hundreds of places, you could go to break into TLS, you're talking about all these routers that are scattered around as well. And we'll see in a moment how this has gone wrong in practice. But the attack surface is vast, it's not only these routers, we also saw from the survey that approximately 52 countries have these certificate authorities, so you can make this attack happen in lots of different places, whether by technical or political means. So that was problem one, problem two. What happens when the certificate is not right? You get this little warning message, different versions of it on particular platforms and browsers, but it all always looks something kind of like this. And when you see this, 99, maybe 99.9% of the time, it's an administrative error. Actually it's the right certificate. No matter how scary the warning looks, the correct user response is probably to find the way to get around, Microsoft has been clever here, they've tried to make green no and red yes, but you learn, actually red is what I want. I want to get through the warning to the site that I'm trying to go to. And 99.9% of the time, that's the right thing to do. What this means is that certificate warnings are totally useless. And these warnings are trained to get through them. Even experts really struggle to understand what the right certificate looks like, and then they learn to click through it. Problem three is widespread surveillance by governments of the internet and widespread censorship by governments of the internet, and these two subjects are intertwined. But what we're realizing is that X509, which is the system of certificates that TLS uses to do authentication, was not engineered, was not designed to be able to cope with attacks by governments or any other kind of resourceful adversary. Get five people at random out of the audience tonight, they'll be able to break this thing. And this is going wrong in practice, it's not just a theoretical attack. For instance, illustrating problems one and three, the DigiNotar hack by an apparently Iranian hacker, which was then turned into a weaponized deployment against Iranian Gmail users that got 300,000 Gmail usernames and passwords. And we don't know what happened to all the people whose accounts were compromised that way, how many of them, if any, suffered real world consequences. But the odds are not great if you've got a regime like Iran that's trying to surveil its citizens. And I take this kind of personally as well, because at some point I went on, I did an interview at EFF, sometimes do press, and an Iranian journalist for Voice of America called me up and said, can we do an interview? Can you tell people in Iran about how to use the web safely? How to communicate safely? I said, look, there's probably nothing that you can do that's really safe. But if you want something that's simple enough that you're not gonna get it immediately wrong if you're not technical, use Gmail and use HTTPS to talk to someone else who's also using Gmail over HTTPS. That's pretty hard for the Iranian government to break. And Google's kind of on your side. But when this kind of thing happens, I guess I take it personally. You worry about the advice you give people. Another example, this is illustrating problems two and three. So here we have the Syrian version of the same attack. The target this time is Facebook rather than Gmail. Unlike Iran, Syria wasn't sophisticated enough to break into one of the certificate authorities. So instead, what they did is they just made a fake certificate that was wrong. We didn't check out, it wasn't valid in your browser. But who the hell is able to read the details in these certificates? Maybe the people in this room, maybe. But not the average person in Syria who's been trained if they see this wanting to click through it. And so we can be sure that when this kind of attack happens, 30, 50, 60, 70, some percentage of people still turn over their usernames and passwords to a man in the middle attack like this. And they still have their lives in danger afterwards. And then some cases purely of, actually this should be problem three, I guess, not problem one. Censorship in general is becoming more pervasive on the internet. And the list of countries is getting longer and longer and it includes bizarre examples. I'm actually Australian, not American. So Australia for me is an alarming case with my home country that's usually pretty democratic and seeming open, is about to, or at least, getting close to passing a law that would sense a pornography, just randomly, by connection blocking or DNS. We don't know exactly. But, and then you have your usual kind of suspects of authoritarian regimes that we like to blame for censorship. And then the United States, which has in the last year, started seizing domain names that belong to law abiding websites. And so we have this mess. We have governments running around censoring things. Another interesting example was Kazakhstan in June this year, which made a demand to Google saying any Kazakh Google user, we have a right to have access to their data. We want to be able to see their Gmail, we want to be able to see their search terms. They're our citizens. We need to be able to see what they're doing. Google's response to this in Kazakhstan was to turn off Google.KZ. Like, we're not going to be in Kazakhstan. Goodbye. The same response, I guess, that they ultimately took with China. But here's the situation. When Google decides to do that, if Google turns off Google.KZ, the Kazakh government, which controls the .KZ top level domain, can control DNS responses and email for Google.KZ, which means they can get a certificate for a Google.KZ domain, which means that they can control HTTPS Google.KZ with the lock icon. It's perfect, it's secure, it's all done, but it's the Kazakh government and not Google. And Google, of course, can't do very much about this. They can't even stop using that domain name because users in Kazakhstan have learned that what they do is they type Google.KZ. And the fact that one day, control of that domain passes from Google to the Kazakh government and ceases to be a web service run by a US company, and suddenly there maybe does some abstract commercial surveillance that doesn't matter very much to them to serious political surveillance in their own country, this is a problem. Similar example, maybe a different example. This is a VB.ly. Those of you from San Francisco, Violet Blue is kind of a local character. She bought VB.ly and set up on that domain the world's first and only sex positive URL shortener. And she did this and got a splash of fame, and then more fame when she discovered that.ly is the Libyan top level domain name. And Libya didn't like the fact that their top level domain name was being used to host a sex positive service. That turned out to not hurt anyone, really. But who else uses .ly? About, as far as I can tell, if I'm just googling this bit.ly market share, the answer seems to be about two billion links a month are processed through bit.ly. And most of our government just went to war against the Libyan regime. And quite fortunately, we were lucky. The regime that we just went to war with didn't realize, didn't have the sophistication, wasn't able to use its control of the .ly domain name to launch a cyber, you know, like a finger printed malware payload to two billion URLs in the space of a month. Maybe they'd only have gotten a day, but they could have owned a lot of machines in a very short period of time with that. And they could have done it over HTTPS. If we'd been checking for that, it wouldn't have helped. Some people will say, well, you shouldn't be using .ly. You know, before you set up a website, you should think about who you want to be subject to in terms of the rules. Unfortunately, that ship has sailed. The amount of money that has been spent on setting up famous websites on huge scattered clouds of top-level domains is enormous. You can't pull them all down. Secondly, control of domain names changes. The regime in the country may change after you decided that under the old top-level domain, you are happy doing business there. Now you're not anymore, vice versa. Companies and countries actually sell control of these things, and ICANN is about to hand out an unbounded number of new top-level domain names to anyone who shows up and pays some money. So basically, the situation we're facing is you can't, as a sensible policy mechanism, say, look, we're just going to partition up the internet into countries and zones, and our security policies will be totally determined by what zone you happen to pick. Well, if we do that, we're exposing ourselves to enormous risks. So there's another half a problem that I'm just going to state for people who know a bit about TOR. TOR has these really great things called hidden services. These are probably the best, like, high-secure censorship-resistant methods we have to connect to our server somewhere. They use these URLs that look like this. This is a hash of a key in here. And the problem, they're great, but the problem is that there's no way to remember one of these URLs. If some service that you heard about six months ago suddenly becomes relevant to you now and you haven't kept this thing, how do you remember that? Also, these things are kind of slow. Maybe they're great if you're under attack right now, but they're slow to use all the time. So what would a good solution to these three and a half problems look like? First of all, we'd like something, a system where the user types in a name or they click a link, and they just automatically and transparently get a really secure and censorship-resistant connection to that name that they were trying to talk to. In a way that's safe against this huge collection of third parties that we currently know can be used to compromise a TLS connection. And it works out of the box for a name you haven't looked up before. So if you get a new machine and it opened it up, you're safe from day zero. Or if you walk into an internet cafe and you get lucky in the machine that you're sitting down at doesn't have malware on it, you then get a safe connection. Malware is maybe a separate harder problem. Enough hard problems for one talk. And there's no crazy UI. No moment when the UI just asks you a weird question and you don't know the answer to it. And this system should fall back to a secure routing mechanism when you're under attack or your connection is being blocked. Also kind of an addendum. Our domain name system, currently consensus-based, global, valuable and fragile. Whatever we do, let's try not to break it too much. So those are the requirements. And here is a design that perhaps gets close to meeting some of them. So the one-level statement of the idea is let's have a named key mapping. Let's put it in a semi-centralized, cryptographically appendedly data structure. So you can write to this data structure, but you can't change what's in it already. And that's enforced by some crypto. But to explain how this works, let's just start by imagining that somehow, magically, you're looking to a crystal ball and you know a sovereign key for the name that you're trying to look up. This thing called the sovereign key. What do you use them for? Use one. You're connecting to add-ons.mzilla.dog to install some code on your machine into your browser. And there's a certificate chain that's presented currently when you do TLS. And if you see there are signatures here from two different... These are the same key, but chaining up to two different root CAs. That's how things currently work. With the sovereign key, you add this extra magical little thing onto the end of the chain, which an old legacy browser ignores. It just looks at this stuff and works out if the set is valid or not. But if it knows to check, it goes over here and says, ah, there's an extension here that says sovereign key magic. And this signature has slightly different semantics to the normal X5-9 signatures. Most of you probably won't get this, but if you wrangle X5-9, you'll realize that here, in the normal case, this signature is bound to this key, so you can't cross-sign with a different key in ordinary X5-9. This is a kitchen sink file format that normally does everything. The one thing we need it to do, it doesn't do, which is two signatures onto the key you're actually using. So we use a hack to put it in there with a special extension. And Adam Langley has been implementing this for Chrome for their pinning stuff, so this bit's done. Okay, so that was used one. We have a nice way of verifying that you're talking to the website you really thought you were talking to, even when all the CAs in the world could one day get hacked. Assuming your crystal ball works. Used two. Suppose you know there's a sovereign key for example.ly. But you connect to example.ly, and you don't get the cross signature. It looks, the thing you see looks like this and not like that. Or you don't get any response at all. Then what you do, you fall back to a censorship circumvention path, which could be either a proxy or a VPN. Or if you're going to actually go all out, you just talk hidden services. And you can do this fairly safely because you know you have the sovereign key to verify that if you make this alternative connection, if you succeeded, you can tell. If you fail, you know you can tell. So the strongest case of this, we're going to do a tour hidden service, how do you get this weird magic string? You take the hash of the sovereign key that the crystal ball gave you. And you only use this when you're under attack and your direct connection is being blocked. So it's not super slow. So the thing you're probably wondering is, how does the crystal ball work? Okay, if you have a crystal ball you can get somewhere on this problem. How do you get one of these? Using this appendedly data structure, which is, I want you to imagine it's like a pile of books. If you've got a pile of books, you can put a new book on top and you can see what books are in the stack, but you can't change the books in the middle without causing the whole stack to fall over. Now it would be bad if a stack of important stuff for our internet security infrastructure fell over. So we're not going to just have one of these. We're going to have a bunch of stacks. And if someone, like, bumbling giant walks into the room and knocks one over or someone sneaky at a hacker conference knocks one over, you have some more. And as long as one of the stacks is still up, you're still okay. Of course, if someone knocks over five of your six or 19 of your 20, you have to put some more stacks up really quickly, but it gives you some time. And then the internet is large. There are a lot of devices connected to it. So if you want to get the data in the stack out to lots of people, you make lots of copies of the stack. But you have one master copy that these are all made from. Or one master set of 10 or 20 stacks that they're all made from. And so what security does this get you? Compared to the situation today where an attacker just needs to break into one of these hundreds or thousands of systems, here, they need to break into one of those systems and have a time machine to go back in time before you wrote into the appended data structure and put your sovereign key there. And so if the attacker moved first, they can do this, but if you decided you wanted a secure domain name and you set that up, too late, they can't attack you. Not in the authentication layer anyway. Okay, so that's a metaphor level description. How does this work? In detail, what's the actual data structure? So we have 10 to 20 of these things. We're going to call them timeline servers rather than stacks, because they serve as a timeline for the keys. They look a bit like this. They're very simple. Each entry has a serial number. The serial numbers go up by one. They have a timestamp. The timestamps need to be monotonically increasing, so each timestamp needs to be larger than the one before it. And then they have a signature for the timeline servers. So the timeline servers have public private key pairs. The clients will ship with the public keys of the timelines. And you can see you have a signature here for each of these array entries. And then anyone who's using this protocol can check that the appended property is correct. They do that by checking. When I see an entry, does it have different data to another entry I saw from this timeline server with the same serial number? Yes. Now I have signed proof that this particular timeline server failed to be appended only, and so it's broken, and I can publish that, and the whole world will stop trusting it. Did the monotonicity of these timestamps get violated? Did you have a higher serial number with a lower timestamp? If yes, that's evidence signed that this timeline was bad, so everyone stops trusting it. Did one of these entries contain semantically self-inconsistent data? Then again, that's evidence that the timeline was bad, and everyone stops trusting it. And then you have a little peer-to-peer protocol for the mirroring servers and the clients that rely on this stuff to spot these. Now, what's inside one of these particular entries? The most basic kind of entry is the creation of a new sovereign key. So I'm making one, and there are two parts to this. There's a key info and some evidence. The key info looks like this. If I click on one of these things, I say, okay. The domain is EFF.org. Here's my key. It should be like a 224 or 256-bit ECC key by default, but you could use something else. I'm saying it's going to support these protocols. Or you could say all protocols that ever have used sovereign keys if you wanted to. It'll expire, and here's an expiry date so depending on who your top-level domain is, you could make one of these things for 10 years or 20 years or 100 years if your TLD allows that. Wild card equals true. This just means it's the default case that I can make X.Y.Z.EFF.org, but if I make this false, then you can have a policy of special sovereign keys for different sub-domains. And then this last little mysterious thing that we'll talk about later in case of revocation and then some other names. Now, what's the second field in here? The evidence. How do I get to prove that I'm EFF.org? We'll use the existing standard. So I need to show up with a CA sign certificate chain that would be valid in a browser signed by one of the standard CAs. And then I sign from that key in there over this whole claim. So to get into the thing, I just use the existing standard. If DNSSEC ever works, we can use that instead of CAs. When DNSSEC works, we can use it instead of CAs. And then what I do, I make this thing, I write it to one of the timeline servers as a kind of master write and sort of any policy that's being applied to the writing in addition to this stuff that happens there. And then I also replicate my write to all of them. So if the channel 20 that I wrote to at first is still alive, my sovereign key is still there. How do the mirrors work? A mirror is an IP address and a public key. Or identified that way. It should have a two to three terabyte disk on it. In the design, we said this cost $100. I guess that's now $200. Hopefully it'll go back down to $100 when a flood stop happening. The expected amount of data from the sovereign key was made for every domain in existence right now. You have about 100 gigabytes of data. But you want a lot of headroom so this thing can just keep growing. Or you can get DOS attacks and survive them. And then if it gets really large right now you could just bootstrap using the protocol. But if it gets really large, the ultimate way to bootstrap one of these mirrors is by disk over snail mail. You go to Amazon, you say send me a disk, a three terabyte disk and now you have a mirror. And then the updates get synced. You can go to one of the... You can go to the set of masters and read from them. Or you can do peer to peer, ask in the mirror what does it have. But each mirror has a copy of everything on all of the timelines. And the updates are of the form... Give me all the entries since number N or number X. And then you also get this thing called a timeline freshness message. Which is a bit like one of the entries in the timeline. Except it has no data in it which makes it really small. And then it's produced pretty regularly like maybe once a minute or more often. How do the clients query the mirrors? They say I want to go to google.com. What do you have for that name? Or what do you have for that name since entry number and then you pick a number? The mirrors reply while I have these entries since Y. Y can be less than X for dust prevention reasons which you can figure out if you're worried about that. You put the freshness messages in there. So you're saying I have looked at all the timelines as of in a list of when you looked at them all and this is used to keep the mirrors honest. Mirrors could omit things but the fact that they sent you a response here that omitted something that their data was fresher than that and then they signed it means that you can catch them when they do this. So that's the basic protocol. And that's moderately complicated. Now it'll get a little bit more complicated when we add a whole bunch of real world things that you want like revocation. Self signed only which means you need to not lose your keys. It's fine if your keys get hacked there's a recovery for that so you need to make five copies of your key put them in vault somewhere or get someone else to do that for you and pay them for it. The way the revocation works I put a new entry on the timeline sometime later with a self signed revocation and then how do I recover? We go back to the original entry when I made the key for EFF.org I picked who in the world I would trust if I ever had been hacked and needed to recover. And so you can choose out of the whole wide world which organization or company or whatever to bail you out if you're in trouble or a few of them. So at EFF we might pick the ACLU CCC and bits of freedom and if we ever got so badly hacked that someone broke into our vault and stole our sovereign key we'd issue a self signed revocation and then come up over here to Berlin and say can we have the CCC that's a new key. And so then the CCC would put this thing on the timeline saying we're re-issuing EFF.org here's the new key for EFF.org signed and then they put their signature here. You can renew the things I said at the beginning you get it for a certain period of time they expire just to prevent pollution of the name space but you can renew yourself. So if you're still around still using the domain and you can write to one of the timelines if you want to transfer to someone else you just do this thing but instead of going to the CCC and saying help we've been hacked please make us a new key I come along and I bring the new person who's buying EFF.org and say hi CCC I'm transferring my domain can you please do the same operation and this time we'll make a new key for someone else. So that's the design we put it up a little a little while ago it started showing it to people there are a few attacks and problems that people pointed out with the design thus far they've all been fixable they make things a little bit more complicated each time but the design doesn't seem to have fallen over yet. Attack 1 denial of service we're going to get a portion of DNSSEC if that's in place some sub domain somewhere we're going to make A.domain.com B.domain.com we're going to make a sovereign key for each one of these things we're going to fill up all of those 2 and 3 terabyte hard drives and it's a very expensive attack not to be defending against because you have to keep the attackers records forever. Or you do this with a CA that will issue free certificates if you go and pay them a big check they write you an unlimited number of certificates you make keys with them. There's a hybrid fix that I think works for this which is we make a list of the portions of DNS space that you can't get for free so just portions of the namespace that we know you have to pay money to get a name in and for everything outside of that we demand a CA set from a non free CA and then all of this kind of works but an attacker may get around it they'll discover a place in the domain name system where there are free domains that we didn't know about so in order to survive for the day where they discovered that you use rate limiting and rate limiting to the real rate of creation of domain names gives you like a year of safety via rate limiting so you have like a few days to figure out who was attacking you what part of the name space of what CA they were using to attack you and then to remove the things they were using from your enumerated list so the defense seems to work next big problem next attack is that transition could be messy if we wanted to put this thing in a .key top level domain it would all work except we want to use this system for existing domain names we want Google.com to get this protection we want EFF.org to get this protection we want WikiLeaks.org to get this protection which means that conversely bad guys can break into TLS servers and then try to make a sovereign key for the victim domain and they're totally legit they own the TLS server they can make it do anything they want and so it's going to check out this is a slightly messy mitigation but maybe it'll work we have a two week pending period for a new registration of the sovereign key while you're waiting you get a bunch of warning emails that go out to the technical contacts and then you say hey are you really doing this if not click this link and we'll stop it and then you say the domain also when we hit it from a thousand different directions has to always redirect HTTPS and it has to set the HSTS header and what this is doing and it has to have this URL here that it responds to with a request for the sovereign key saying yes I promise I want a sovereign key is it's filtering this set of domains that can make one of these to domains that have very competent and obvious HTTPS deployments which reduces you from 2x10 to the 8 domain names down to less than a thousand domain names right now and for most domains the website admin is going to notice if 3 and 4 are true just their site is going to wake up and their site is going to behave differently and look differently so this is a protection that should reduce the number of domains that get hacked and then get down to 6 which is where you go man we really screwed up someone actually made a sovereign key for google.com against their wishes ok we'll put a line in the source code that says dig ourselves out this is hopefully not an attack vector for censoring people because if it's in your source code you can also remove it if you're the client and you don't like the line in the source code so the theory is very few attackers get to 6 but I want to see if people are persuaded by this number 3 this is not an attack so much as just a problem it's a problem that Adam Langley pointed out and it's a problem with hotel networks and airport networks and other captive portals so you all know these places they're really annoying you make these things and they block everything that you want to do all the side channels you want to use to ask about sovereign keys so you can't make a query for any domain to see if there's a sovereign key for it or what it is and then the captive portal wants you to do HTTPS to give them your credit card number and so you can't treat that safely in order to be safe with every domain out there on the web and there's a lot of information about sovereign keys before you talk to it but the captive portal wants you to do HTTPS with no side channels so how are you going to load the auth page safely another hackish work around we get a browser Firefox or Chrome or maybe just a popular extension we instrument it to detect captive portals they're pretty easy to detect they have the property that when you try to go to lots of different domains they all redirect you to one domain so you get the set of one domains that are the result of those redirections and you whitelist them all out of the sovereign keys system in the source code these domains can't have a sovereign key you don't need to look it up they don't have one and then this is not a security problem because if any of these domains ever does make a sovereign key you go back to the source code and you delete them from the whitelist so no one who wants the security benefit of a sovereign key ever accidentally gets put on the whitelist but all the hotel networks get put on there automatically and then maybe people are worried what about new or non-public captive portal networks we let these people figure it out themselves like day one we ship this thing we whitelist all the existing captive portals and then we say in future here's a spec for how to write a captive portal correctly here's how to let sovereign keys queries through and we make them deal with that so this is ambitious and it's currently a vaporware design that I'm just here to ask you guys about but I think it's at least possibly achievable we at least have a chance of building this if we want to if we think it's a good idea to make the web a lot more secure and a lot more censorship resistant than it currently is but you also get a sense of some of the kind of extra operational complexity we're going to get into if we decide to go down this road if we want to make domains and websites more secure they're more secure but you have more homework to do you have to back up your keys and put them in vaults so we have a mailing list we have a detailed design document if you want to go through it with a fine tooth comb attack it we'll have code appearing when it's good enough for people to look at and also of course I have to do this mandatory we're a non-profit organization we do this stuff for the community because we think it's important to do it if you like what we do it's a great time to donate to us because Sergei Brin and his partner are giving double matching donations for the next month or two so I think that's my spiel and I'd love some questions so I'm sure there will be a lot of questions I can see from now so I'll just start here in the front with the first question thank you do you have a sound? okay I have a problem with the privacy issues all the clients have to look up at your service for every website you visit so the clients have to pick one of the mirrors there's no policy saying which mirror they have to pick so if we go back to a diagram that has mirrors in it there are lots of these machines around and they have to query one of them so if you want to there are a lot of different ways you can approach the privacy issue you can have a client that tends to prefer a mirror run by their own ISP and that's kind of the equivalent of the existing DNS model or you could choose to have a client that picks a mirror that's run by someone they trust and they get to specify some people that they think are trustworthy from a privacy perspective or they can take a latency hit and use a VPN or a proxy or Tor which in this specification or proposal is built into the browser so it's always available you can take the latency hit and use Tor to do your lookups so there are a bunch of ways of answering the privacy question and I think it's no worse than our current situation and it's potentially better another bigger issue I see is the revocation I work for a TLD and we already have a lot of problems with revocation and adding another player into this field will make you vulnerable to ransom issues so it's certainly the case that revocation in this protocol is complicated it's more complicated than it is currently not for just having a web server compromise of course because if it's just your operational key that gets compromised that's fine you just go to your sovereign key and you make a new operational key you use the existing revocation mechanisms for the old key but if someone breaks into your backup systems which they can do and they get your sovereign key we need to do one of two things when people make a sovereign key the common case should be use a service provider that you trust for a sovereign key just one you pick one it could be CCC it could be VeriSign it could be whoever pick one service provider who you trust and choose to trust instead of a thousand third parties they look after it they deal with backups and if you're a corporation they write a contract with a very large dollar value if they lose your key they're going to pay you a million dollars the other model if you're a hacker or a sysadmin you want to do this yourself our command line tools for making a sovereign key need to make sure you made three to five backups before the key is registered so the UI you have to build here is something like this backup one give me a USB key or an SCP account I can copy to or a Gmail address I can send it to or a printer I'm not sure about printers being safe anymore I keep saying these talks about printers I don't know that I want to print my key to make a paper copy because I'm not sure the printer is going to delete the copy I sent it and the UI says okay that was backup one now backup two give me another USB key backup three backup four okay now maybe you can publish your sovereign key and so for people who want to run these things themselves I think the default code needs to simply walk you through that make it as hassle free as possible and then you are warned right if you made four backups and you lost them all okay we made domains a little bit like physical property it was like there was an actual object a key that was your domain you lost it like that's a question I'm asking you about it's a cost if we want to be censorship resistant to a strong degree this is an inconvenience we're going to have to to pay and I'm willing to hear people saying that price is too high that's one type of revocation but the other part is that you actually change owners with the main name and the TLD less than your owner just run it but it forgets to tell you that you have sovereign keys as well that you have to buy from somewhere else so probably in cases of transfers what you should do is as a DNS operator you should basically follow the advice of the sovereign key system so if you see a sovereign key revocation and reassurance you should go with that you should never kind of let someone else other than the current sovereign key holder control the DNS but you can still charge fees for DNS of course like the DNS can go away but if it's on it has to go to the person who has the sovereign key so you kind of move control over in that direction and of course DNS operators should do sovereign keys like they should be some of the people who offer these services to you if you trust them sorry I see there is a question in the back say that rather than make back copies of the sovereign lots of back copies of the sovereign key actually sign in where the vocation are made in copies of that so there is a low risk if those keys leak the signed revocations actually leak so you re-sign revocations put them with somebody you trust and the worst they could do is revoke your key that's right that trust will be somebody else than the person who is trusted to re-sign the key so the idea there is a trade off to making lots of backups and by making more backups you reduce the risk that an attacker will get the key but you reduce the risk that you'll lose all of your copies and that's the trade off you want to make with this kind of design because you know that if the attacker revokes or you revoke the fact that you picked at the beginning who was going to inherit the name for you gave you kind of the better of the situation if you revoke sorry okay we have a few questions from the internet does the EFFC themself issuing as keys for grant TLDs what was the last what adjective did you have for TLDs you said something TLDs I repeat the question does the EFFC themself issuing right as keys for grant TLDs grant TLDs current sorry oh current TLDs if you have well I don't think we will be doing the issuing if we do anything here we'd write the spec write some code help an experimental deployment where some people run some timeline servers so they'd be the ones making the sovereign keys and then if people if the thing ever gets deployed for real it starts to be the browsers who are probably running some of the timelines and existing internet government organizations that would run some of them the people who are really making the TLDs are those timeline servers who are receiving an X5I9 certificate chain and saying yes this is authority of control over this domain name and yes he's a signature from that authority saying I want a sovereign key I think EFF will be making the keys we're kind of helping set this kind of mechanism up okay another question could or will SOPA make this illegal that's an interesting question would SOPA make this illegal I think the answer is no but it would be we don't want SOPA to pass and we don't want to have to have that fight and there are a couple of people looking at Cori and Rachel's questions yeah there are a lot of questions in the room so let's take another question from here quickly then the first one is if your remedy to keys being leaked by someone who holds on to keys or keys being lost by someone hold on to keys is these million dollar penalties written into contracts isn't that fundamentally guaranteed that they'll never tell you when they lose or leak keys because as soon as they've lost 100 keys that's 100 million dollar liability and there's no reason for them not to lie because lie or not they'll just go out of business and the second part of this is if part of the answer is you should figure out who you should trust haven't we just reinvented trustee and every other failed system to ensure privacy and good practices on the internet um fortunately not well certainly compared to the one that we're currently living in with for TLS where the model is not you choose who to trust you actually are forced to trust hundreds of organizations and loads of other machines around them that you have no control over um it's also kind of a very different sort of trust you know trustee is in the business of running around to thousands of sites and saying their privacy practices are good it's okay to do business casually with them this is a different kind of model of it's not a casual I'm going to this site and getting some information there renting a hotel room for the night and hoping they're not going to track me it's I'm choosing to entrust my domain name to these people and to the extent that I valued my domain name which is sometimes not very much and sometimes enormously you know I should evaluate the business the one business not hundreds that I'm doing that I'm going to do this with and pick them um and of course you're not required to do this you can do it yourself it's just that especially for corporations that run loads of websites there needs to be a good default case answer for them and so designing something that's great for WikiLeaks or CCC or other hacker organizations but not good for the rest of the web is sort of unrealistic we need to have paths and options for the different operational philosophies you have um the other part of your question was how do you tell if they're if they've leaked the key um or if they have lost it I think you can tell in most cases but I'll think about there might be cases where your argument is interesting we'll take another question from the back okay it's actually two questions um the first is a problem where your sister admin of a large corporation handles the sovereign keys and he just walks away um and you get sacked or whatever he's the only one who had a sovereign key and he says well this is now not my problem anymore and you're left with a sovereign key not under your control and how do you recover in this case and who decides if you're the right owner if you actually get the key reissued and the other question was can I make domains worth less than a sovereign key which is expiring maybe in 200 years and then not just choosing not to pay for my domain name anymore will the next owner actually be able to do anything with it so answering the second question first you can only make a sovereign key that's initially valid for as long as you've registered the domain name for so only you can only make a sovereign key that lasts 100 years to register and pay them for registering a domain for 100 years which you can do for some TLPs you can do that today so you can't make the sovereign key last longer than your initial registration of the domain the first question about what do you do about a sysadmin who runs off with your keys I think organizations already have this problem with their sysadmins potentially you know and a sysadmin who runs off and then rm-rfs all of your your data servers can cause catastrophic damage to an organization and so managing that risk is a thing that every organization needs to do if they're large enough they need to have multiple copies of the crucial data that are outside of the control of one human and this does happen occasionally but mostly you can rely on human dispute resolution mechanisms to try and do something about it and say give us the key back or else the sysadmin is liable there's another question from here in the middle I have two questions actually the first one is is this scheme only valid for SSL server certificates or for clients and IPsec as well that's a good question I think you could use it for IPsec I'm not an IPsec expert so I think certainly DTLS or any other kind of similar model of what a connection looks like to TLS you could use the same certificate for for clients I guess the way we handle namespaces here is not really optimized for the client certificate case where you want to issue loads of usernames at some domain so the way you would probably do that is by bolting on an extra mechanism you'd say cross sign an operational key with your sovereign key and then sign the user's email keys with that operational key and you could build that globe but it's not part of the stuff we've been talking about thus far the second question is if somebody would have come up with this like 10 years ago a somebody smart guy and you would have a timeline with all of MD5 signatures inside would this as a protocol be vulnerable to algorithms going bad after 10, 15 years? So what you want to do you want to have probably one or two of these stacks that uses a different algorithm maybe something that's a bit more expensive and a bit more secure so that if you get a class break against what we thought was pretty good crypto you at least have one timeline still standing that lets you throw away the others and then start rebuilding new timelines if you break all of them at once you have a crazy day where you have to dig yourself out and then for the individual sovereign keys if you chose to make a sovereign key using an algorithm that's no longer secure you know at some point you need to revoke it reissue it and use a stronger key If we would have started with this like 10, 15 years ago which algorithms did we have which were common at that time which would stand valid today But I guess what I'm saying is you can rotate continuously in this design so you can put in a new timeline any time the clients want to ship an update they can add a new timeline to the algorithm and then so long as you haven't had all the existing ones destroyed beforehand you can import the entries from one timeline into the next one Can we take another question from the back? I would like to know I personally also use X539 certificates for email so there's not a binding between a domain name and a public key instead there's a binding between an email address and a public key So I think it's also to improve the security of my email certificates because then the enrollment or adding a key to your database would be a little bit more difficult because I don't have an HTTPS server running on my email address I think the answer is the same kind of yes as it was for client certificates So in principle there's no reason why you couldn't chain from the sovereign key for the domain to an operational email key or email issuing key for the domain and then down to individual users email keys but you'd need to write some code that we haven't talked about how to write to do the glue Do you want to ask the follow up? In this case I would also like to protect my Gmail address so there's no cryptography binding between me and Google So I would have to do that independently of the organization belonging to that email address email domain name So if you had a policy of helping you do that which I think you would need in this kind of hierarchical model of how domains function they'd need to accept that you know okay you send them your public key they sign it for you and now you have a public key for your email address So if Gmail is willing to cooperate you could do that Okay we have another question here in front I think you're offering a lot of technical details for a solution which is in-depth analysis a problem of trust So what if China or another malicious country insists of running such a server and insists of running all companies in this country of preserving with their own certificates So you simply transfer to the problem of trust into a higher level which cannot be solved that would be the same if you set up a wide list of certificate authorities where you say I can trust them and if I see anything others I refuse anything So this is just a lot of technical stuff around a simple problem of trust which is not really solved by this approach I think I think the thing that I would say about this is I don't care how malicious China is I'm still probably willing to let them run some of these timeline servers because the important functions that the timeline servers perform are remotely cryptographically verified and if the Chinese timeline server is malicious and tries to change history the protocol detects it instantly and you need to test that Not changing history but insisting of all services in this country have to trust my way of giving you a certificate So it's not about changing history it's about a law that says only we give you trust and anything else is forbidden this is the same with the DNS the DNS has a problem that every crappy country can give can act as an anchor of trust even if it's not trusted but now we have another anchor of trust but the government can insist of we want to be the only anchor of trust for our companies and then you have the same problem on a higher level So which part do you think which part which of the functions in here are you saying the Chinese government would take control of or insist upon They insist that they provide you with these certificates they want to be the authority which creates all these certificates on the server China is simply saying we want to create the certificates Do you mean these CA science certificate chains that uses evidence It's only located in this country and they by law forbid any company running a service in this country to accept anything from outside of this country Sir, let me try and make a version of this China insists that everyone who uses sovereign key in China uses CNNIC and then contrary to usual existing practices for CNNIC where you send them a certificate request and they make a certificate they actually demand your private key before they let you make a CNNIC certificate The only way they can enforce this is by the threat of physical force against Chinese companies and there's no amount of cryptography that will help you if you're an identifiable Chinese company the Chinese government is willing to walk in and use the power of their state against your physical presence if you're an identified actor inside their country So nothing we can do technically will ever give a Chinese corporation or any other overt human organization with flesh and blood in China the power to speak with complete impunity in a regime that doesn't legally allow that but if you're not a company in China if you're a blogger in China and you want to do this the Chinese government can't tell it to you you can post your Chinese blog and they have no way to know that it was me that was writing that blog this system gives you all the pieces you need to blog in China anonymously and have a chance of staying that way it's not guaranteed of course Okay there's another question from my colleague in the back Hi I wanted to go back to the first question and the comparative risk privacy and surveillance to DNS if one's worried about governments doing strategic surveillance on a very large scale wouldn't you need as many mirrors as currently there are DNS servers isn't one concentrating down the flows of interesting traffic about which websites people are checking out down to a very much smaller number of servers it would be much easier to surveil you probably want I mean I anticipate you would have lots of these I mean I expect for a small like experimental deployment you'd have dozens and then if this became big you'd have thousands or as many as DNS servers ultimately sure but if people want the privacy protective option using Tor to query a hostile mirror is not a bad way to go because sure the mirror sees that someone looked up a particular domain you know they can't tell that it was you so if you want the privacy of your DNS queries and you're willing to take the latency hit there's a way to get that okay there are some more questions from the internet okay how does one guarantee that the first key for the server in the timeline server is not the spoofed the first key for the sovereign timeline server is not spoofed when a when the client implementers choose to let someone set up a timeline server you know they go to that organization and they make a human effort okay humans in a country well you only have channel 20 of these things oh so how do you well there are two versions of the timeline servers get into the client source correctly and that's a problem that like we hypothetically browser vendors would have to deal with in talking to the timelines but if we got it wrong it wouldn't be too bad because having an evil timeline only lets them violate the timeline append only property and we detect it and it goes away so it's not too bad if it's the wrong key so you have some protection there then how do you get the right version of the client software well that's an existing problem we struggle with but you know chicken and egg you want the first operating system that shifts on your machine to be good and if it's bad okay you can be in trouble you want the first copy of the OS CD that you put into your CD-ROM drive to be good and if it's bad okay maybe you have a problem we can't solve the malware problem okay how do you convince users that you sorry that try to key do not go around if it's fail so I think the version of the question is if a country tries to like block the entire protocol from getting deployed I think that was the question and that's a reasonable question to ask so I'm Iran and I just try to block every single protocol request coming into and out of my country and we know from the tour talk some days they can do that some days they struggle to it's kind of an arms race if you turn this on in browsers by default on the day that they they block access to the protocol you basically start in the spec a clock ticking because clients will be willing to sort of operate with their existing cache of keys for a little while but if it gets to a certain amount of time and they can't find any mirrors that look good they go wait a minute I'm under attack I'm shutting down I won't query any domain at all and so on that day Iran blocked sovereign keys and all of the internet stops functioning in Iran so it fails safe which gives them the choice sure they can turn off the internet in their country but if they want the internet to work with modern browsers then either they let the sovereign key queries through or they block everything so I'm really really sorry but we're already over time and I see there are a lot of questions in the room and I'm sure there after talk there is a lot of time to ask questions but I have to cut here the official part of the talk and I thank you again for the interesting talk for the talk that raised many questions and I ask again for a warm round of applause for our speaker thank you very much