Whitfield Diffie and Moxie Marlinspike
Diffie, Whitfield
Marlinspike, Moxie
Come watch Whitfield Diffie and Moxie Marlinspike talk about certificate authorities, DNSSEC, SSL, dane, trust agility and whatever else they want to. Moderated by the Dark Tangent and with Q&A from the audience.
 What we're doing here this morning is sort of a spontaneous panel that popped up maybe a month or two ago. That's the best you can do for Spartan ideas. Spartan ideas a month or two ago. Well, you know, I was thinking like I knew you and I knew you and Moxie was doing some interesting stuff and Witt was doing some interesting stuff. And I forget what happened. It was like maybe Moxie was doing something about Dane, DNS Sack. Something came up and I thought that would be perfect to get him talking with Witt. And then I thought that would be perfect to get both of them on the stage because if I think it's cool maybe you guys will think it's cool. So who's looking forward to seeing them just have a conversation? Yeah. So there's not a whole lot of format here. I've got a couple of questions to kick it off. And what I'm really trying to do is kind of get new school and old school talking here. And I'm really curious about how... Sorry if you're still new school Witt. And because what we're seeing is there's a little bit of a different perspective. Moxie maybe is more of an end user perspective. He grew up as a user of some of this technology just like myself. And Witt was lucky enough to be around to be the creator of a lot of this technology and the designer. And Moxie was there for a lot of the important meetings that shaped the way the Internet is today. The way we do certain things online. The way we use certain math and certain cryptography. Witt was there for that. And so they just naturally see the world slightly differently just from where they came from. And then we definitely want to open it up to the audience because I think you'll probably get the most value asking questions. So does that sound like a plan? That's what we're doing. So first off, how many people saw Moxie's talk earlier? So you're pretty familiar with some of his opinions. And so one of my first questions I just want to get out of the way for... This is for Moxie is, why the digital jihad against certificate authorities? You know? Okay. I don't know if it's a jihad, but I did start some of this by looking at the recent Komodo attacks. People are familiar with this. Komodo got compromised. And the attacks could not have been more embarrassing. The information that has emerged from these attacks makes it pretty clear that Komodo does not necessarily warrant our trust. And the question is, what happened to Komodo after all of this? Could not have been more embarrassing. And nothing happened to Komodo. And so I started looking at that question. Well, why is it that nothing happened to Komodo? Will the U.S. fair as well after having its trade downgraded? Will the U.S. fair as well? I mean, it should encourage us that nothing happened to Komodo. Oh, I see. Yeah, right. Exactly. So, looking at this question, I realized that there's really nothing that anybody can do. The truth is that somewhere along the line, we made a decision to trust Komodo, and now we're locked into trusting them forever. And I feel like this is the essence of many of the problems that we've seen with Certificate Authorities over the years, that we're kind of locked into trusting them, whether they continue to warrant our trust or not, without really any incentives to continue behaving appropriately. And so... And then your options as an end user are very limited. And I think I could say your options as a client are limited. As an end user, there's nothing really you can do, and the browser vendors are in the same position. And Komodo knows it. Komodo knows that the browser vendors can't just remove them from their trust database because it would break somewhere between a quarter and a fifth of the internet for their users. So, I feel like we can reduce this to a single missing property that I call trust agility, and the idea behind trust agility is that it should be easy to trust and untrust somebody. It should be easy to make trust decisions at any point, and that those trust decisions should be initiated by the client. And I feel like with those two properties moving forward, we won't get into the same situation that we are in now. And so there's been a lot of talk about replacing the CA system with something else, and I just want to make sure that we don't end up in the same place again. And I think the way to do that is to come up with a replacement that provides trust agility. Any comments on that? Well, no comments that are different from what I had before he said that. Let me start out with a few procedural comments, which was I'm dressed for security theater at the airport. And it seems to me appropriate to change for allegedly intellectual theater here at the conference or something like that. Now, I was told when I was, I've never been to DEF CON before, and I was told that I was required to drink a glass of whiskey before I spoke. Was this... Well, Donner-Plaude's allowed. I haven't done it yet. I assume what that meant is I had visibly to drink my whiskey. You know, he's going for the 40-year-old LeFrog. To visibly drink my whiskey here in the presence of the witnesses. You know, just the way there were many people at court in the European court, so I had the right to witness the royal birth. Be sure that the baby was the right one. So I think my whiskey is being fetched. So the first few words I speak will be unauthentic, receiving the whiskey, but after that, you know, you can have more trust in what I have to say. I mean, basically I'm here like most things in my life by accident. Jeff sent me, incidentally, I really appreciate the name Moxie Marlin Spike. You know, it was hard growing up with the name Whitfield Diffie in a Jewish neighborhood in New York. And somebody wants to have the name Moxie Marlin Spike. That's courageous. But basically I read this article and my response was to think, my gosh, I mean, either, I can't quite figure out, either he's made the greatest observation about the way this needs to work in decades, or he's led me to the observation because I don't say things quite the same way. So let me just say what I learned from Moxie's article and it now seems to me obvious what should be done and it turns into a business problem of how to get it to work. And the simple thing I learned, and it started out with a point in which I disagreed with him. He said it wouldn't make any sense for DHS to be issuing certificates for Chinese websites. And I thought, well, no, that's wrong. It makes very good sense for DHS to issue web certificates for Chinese websites. It just doesn't seem likely that those are going to be particularly interesting to the Chinese, right? A Chinese doing business in China doesn't care what DHS thinks about Chinese websites, but an American business or an American government organization interacting with Chinese companies and organizations and so forth might even be bound, but rationally bound by regulation to only conduct certain communications using certificates supplied by the DHS website. That seems to me an entirely reasonable idea. And in general, what I learned is that basically CAs work for the wrong people. CAs should be working for the people who want to acquire keys, not for the people who are wanting to profit keys. And that's where the trial and work for, and here's the rub, largely means of course as always, paid by. So think about some other things that I think have about the same structure. That is to say, you're going to hire somebody, you're allowed to have that person investigated. You go make certain choices. You choose, you know, I know, Burns detective agency to investigate them, or some other detective agency. You go to Equifax or some other place to investigate the credit. But it's the people doing the people who want the answer, who are responsible for getting the investigators to find out what they want to know. Well, similarly, you know, if you are a business of some kind or other and you want to do business reliable, you don't really care about browsing every website on the web. Who cares? You want to be sure that when you're talking to IBM, you're talking to IBM. When you're talking to Microsoft, you're talking to Microsoft. When you're talking to NSA, you're talking to NSA. And so you want to go to what Moxie is calling a notary. And I think I don't have a better term. I'm not quite comfortable with that one, but I'll use it for the moment. You want to go to somebody in effect that you retain who issues certificates for people you want to talk to. Now, there are two things about this. In my mind, this organization need neither be friends of the people it's issuing certificates for, nor even be known to them. So it could do anything. I mean, the cheapest ones just parrot whatever the whatever certificate those websites issue for themselves. Things are picking up. Just keep going. Thank you. Fortunately, they drive me all around town. That's right. I see. Okay. I don't get whiskey at all. I get rye. I don't get scotch at all. I get rye. Okay. So are any like drinking rye? Who knows what's going to happen? Any last words before you have to be authentic? No. What was I saying? So you might have an investigatory organization that you retained that goes out, you know, flat foot around and does the kind of things accounting companies do and investigates the companies you want to communicate with. And by whatever means, it seems appropriate. It figures out what their keys are and then it issues your certificates for those keys. The other aspect of doing these things this way is, of course, there's going to be a new mode of failure that's going to appear. That is to say, the rules of my organization say I will never talk to your organization unless you present the rules. Unless you present the key that is in the certificate I got from my trusted notary. And so if you send me some other key, the communication just dies there, right? You're presumably not going to understand things that I encrypt in the key I was sent and I'm not willing to encrypt anything in the key you sent. But by and large, I'm going to expect this will work reasonably well. That's not going to happen that often. And of course, it triggers an investigation. And you may, certain sprinkling of these, you will have rekeyed or something like that and it will have to be updated. So that's, we've pretty much come to the end of my pre-Whiskey statement. So I think while I drink my whiskey, I'll turn things back over to my cohorts. So, Moxie, the idea of notary sort of reminds me of the concept of trust anchors in the early days of DNSSEC when they're still trying to get the root signed and the TLE signed, people still wanted stuff to work. So they came up with the trust anchor concept. And the notary seemed fairly similar. Or have you gotten some ideas from that? Sure. I think it's a similar concept and the difference as far as I can tell, and maybe I don't know enough about trust anchors, is that the trust anchors were still sort of predefined by someone that wasn't the user. Whereas with the notary concept, anybody really in the world right now can decide to run a notary. And if anybody trusts you, then they can use you as a notary. It's sort of like a popularity contest. I get half the room to trust me, you get half the room to trust you, the whole room can somehow reach where they want to go. Exactly, exactly. And maybe half of the room, and I think that's appropriate, maybe half of the room is in a situation where they trust you for whatever reason. And the other half of the room is in a situation where they don't trust you for whatever reason. And maybe they trust me instead or some other organization. And I think that that's how the world works. And there can be overlap too, right? Exactly. There can be overlap. And I think the important distinction there between this and the DNS Act Trust anchors is that I think we've gone to a point in time where it doesn't really make a lot of sense for one entity or one organization to be making a decision about how everybody in the world should engage with the authenticity of that website. And I think that's a good point because different people are in different contexts with different threats and different ideas of who they trust in the world. And it's really, it's our data. It's the user's data that's at risk, not the service's data that's at risk in most cases. And so I think it should be up to the clients, it should be up to the users to decide who they're going to trust to certify their data. So would you say looking back that users have made really well informed decisions over the last... Okay, this is a fair question, right? You know, if we're putting this on the user, our user isn't as too complex, right? And I think that really instead of user, we should be saying client. Okay. Because, you know, the way that I would imagine this is that you get your web browser, you know, Mozilla or Chrome or whatever web browser you choose. And embedded within it is a set of same defaults, you know, that the organization like Mozilla has chosen organizations that they think, you know, are sort of generally trustworthy. And maybe they have it localized, you know, maybe they have, you know, they already have localized versions of their browsers, maybe they have those notaries localized for different areas of the world. But then the... if a user, like an advanced user, wishes to modify that, it's very easy for them to do so. And if Mozilla needs or Chrome or whoever needs to make a different decision about how to distribute these things, they can really easily change it, unlike now. Yeah, so it gives them at least the initial level of flexibility that they didn't have. Exactly. And then hopefully that will trickle down then to the advanced users. Yeah. When he's talking about half of the people in the room, I suddenly came to what I think of as the Casanova model. Half of the people in the room trust him because there is a girlfriend. And the other half don't trust him because he stole their girlfriend. I think there is a, you know, I envision there's a certain possibility here for a graduation of trust that would be very useful. Namely, if we've gotten a certificate from our notary that indicates trust in this organization, then maybe we can connect to them, for example, without any firewall. We can get a much better performance and so forth. Whereas if we, you know, we have levels of trust and if we don't acquire keys for them that way, then we treat them as more hostile and we, you know, do a deep packet inspection on everything they send us, et cetera. So you can make a great graduated decision on trust. That's right. It's not either, yeah, all or nothing. Can I want to take a question from the audience? In the front row? Come have a microphone. We have an abundance. Yeah, I think there's, there used to be in one of the aisles, no I don't see it. Have this microphone. Here, we'll just give them this one. Alright, thanks. Just name and... Okay, my name is White Kesterson. I am also old school. As both of these guys know, I chaired the committee that invented X509. So... Alright, the interesting thing is when I draw back and I hear about these trust models, I'm reminded of PGP signing parties. Okay, that's exactly what I'm reminded of. And let me tell you where the problem comes from, from these kind of communities. They may work in certain ways. I hang with way too many lawyers. Okay, and the problem of this kind of distributed trust model is what kind of business liability are you assuming? So when you say, I want to open a CA, or when I, or your version of a CA, which is a notary, then the question is, what's the business model from them? And here's my problem. We actually, you know, put together a program that said, CAs were supposed to operate responsibly, right? They're supposed to do certain things. And when the first ones came out, they had a little bit more discipline. But when the other ones came out, they lowered their prices, they lowered their prices. And now, you know, you have GoDaddy, which does a really horrible job and a couple of other people that do that. But people want certificates and they go to it. And I just don't... And that's the economic model. That's what drives it, because we're laissez-faire. We don't really enforce these kind of things. So I just don't see how, when you put another model together, I do like, incidentally, the voting portion of it. I think perhaps we might be able to do that with actually having servers present multiple certificates from multiple providers. Hopefully you find what someone you trust. But I don't understand why you think that the same economic model won't happen. That there'll be there doing a reasonable job for a reasonable-saw community, then it gets bigger, then it gets more costly. Then I have lawyers telling me about the risk, I'm assuming. So I start charging money, more money, more money to do a decent job. And then someone uncuts me, undercuts me in terms of pricing to do a less decent job, and then we end up with Komodo. And so I basically see nothing there that stops the same iteration of the business process. That's it. Okay, so I'm not really sure I follow that in terms of the vision, the way I envision this. Why don't you leave the mic with him for a second. I mean, as I said, we have, it seems to me, a variety of things that work pretty much the same way. In which you choose a detective service, an accountant, or something like that that has to be trusted, and you pay them. And they bear, that is actually a case where if they have a contractual obligation, and so they will actually suffer for delivering you bad information. No, I agree with that. I don't mind with the flipping of the model, but what I'm arguing is that there, when we talk about the common person, the one who's already trying to figure out what's going on in that little bar in his browser, I personally think the client's got a little too thin here, right? Yeah, let me say for the record, I can't figure it out. So I think we've got a little too thin here in terms of people trying to make decisions and all the information that's up there. But my argument is exactly the same, that people are out buying, they're buying based on certain kinds of things, and they'll end up buying based on cost. Okay, that's what people do. They buy based on cost. And so my argument is that we end up with the same thing, low-cost cutting type things and same risk. I think they buy on cost versus perceived quality or something. I mean, lots of people buy Mercedes as opposed to buying much cheaper cars, right? Lots of expensive goods sell. It's just, the problem with the market is that you can't see the difference in what you're getting, so why spend more for it? I think that's because people who buy Mercedes probably have an innate understanding about cars and quality and so forth. They might be wrong about it, but they think they do. I just don't know if we're going to find this innate understanding in trust models. You don't need anything innate understanding. You put your foot on the gas and the whole ass through a turn and you feel the difference between that and that. You don't know the thermodynamics of what's going on. I'm imagining that some of these investigative agencies, they might be NGOs, it might be the EFF, it could be anybody, right? Yeah, I mean it could be anybody. So I've released some software called Convergence, which is an early stab at inverting this trust relationship and doing things a different way. And the way it works, Convergence, anybody can run a notary. And it actually requires very low resources. It's not an intensive process for somebody to run a notary. And already there's been some number of people in the past two days who have set up their own notaries. And I've received communication from security companies and NGOs who are interested in running notaries of their own. Maybe even one certificate authority was interested in running a notary. So I think that people are interested in running this even if it does not provide any immediate revenue because it looks good. It's just like security companies do a lot of things in this industry without taking any direct cash for it because they want to be seen as trusted entities. Sort of like the lost leader. Yes, yes. One thing may be necessary, you know, I had a remark in your paper about how Verisign could sign a certificate for somebody even if the person didn't want it. And that just strikes me as inevitable, of course. You can sign anything and get your hands on. But the critical, maybe we need a more expressive language to have to go into the browser for saying what you trust about certain sources. I'm going to call them notaries. You say, you know, we trust this notary to endorse that category of things and have explicit, you know, you might explicitly, well, we think they made a mistake in that case. We'll blacklist that one. I don't know precisely. All sounds very XML-ish. Oh, no, oh, no. Yeah. As long as it doesn't sound ASN one-ish. Since we're stuck using primarily low assurance to no assurance systems, do you see any sane approach to prevent subversion of the trusted list or the certificate authority list? I'm thinking of the example where about a year or two ago Microsoft released a security update that actually modified the CA list for Mozilla Firefox. So the question is, is there any mechanism to prevent subversion of these default lists themselves? Anything that you can see, particularly since you're working in an untrusted environment. Sure. Well, I mean, I think, you know, in the case of organizations like Microsoft or any of the browser vendors themselves, that they, you know, at heart are trying to actually provide secure communication for their users. Now, I think, you know, let me ask, does anybody in this room trust Komodo? One, two, three. Okay. Three people. People don't work for them. Yeah. Where do you guys work? Just trust them to do what? Just certify your secure communication. Trust them to do it. You know, I feel, you know, there's maybe a couple hundred people here, maybe one or two people trust Komodo. And I think that the browser vendors and the platforms actually feel the same way. And I think if they could, they would also make a decision to untrust Komodo. But they can't do it. And so, you know, this is the situation we're in. And I think that if we give, you know, these platforms the mechanism to make the appropriate decisions, that they will, in good faith, make the appropriate default decisions. Well, hypothetically, let's say you're a dissident in Iran. The Iranian government has a CA, which I noted was in my trusted CA list by default. I removed it. But how exactly would you expect a user to deal with that if it is subverbed and re-added? Because it's assumed to be trusted by your vendor. And you might have no warning that gets re-added to the list. You know, I think that that's maybe a different class of problems, right? But one thing you can imagine, right, is, you know, right now platforms like the web browser or your operating system are essentially delegating some trust decisions for you, right, that they're, you're almost subscribing to them for some information on who to trust. And you can imagine something similar to an ad block plus model, right, where you don't have to make, you know, very intricate decisions about all the entities in the world that you trust. And you can say, well, there's this other organization, this NGO, that's going to curate these kind of lists for you. So it's like a, you know, a meta notary or something like that. You know, maybe you have something like that. I'm not sure. But what I want to do is at least provide the kind of flexibility so that these decisions can actually be made however they're made. Okay. Now, I don't want to turn the track into nothing but, you know, rant against the CAs. But we're going to take a couple more questions in that thread, and we're going to try to shift maybe the focus a little bit. So let's, uh... Hello, Bill Manning. And I'm going to take both of those questions. Okay. The first one has to do with, you said notary. Notary reputation. Who does that? Number one. And the second, I will call it trust echoes. Trust what? Trust echoes. Echoes. How many people in the room have one device with one browser? Only one. I have a device that only has one browser. No, no, no, no, no, no, no. Right. How many people have multiple devices with multiple ways to get to the net? Everybody's hand should go up. Okay. So if I want to update Mozilla Firefox on my MacBook Pro 15, who's going to update my Android? Who's going to update my iPhone? Who's going to update the box that's been sitting on the desk or sitting on the shelf for the last three months? Right. I'm going to forget these things. So the idea of updating all of the trust on all of the devices simultaneously is problematic. And then there's also the problem of if I trust something and Wit decides that he trusts me for whatever reason. He's had too much whiskey or rye. Um, and I choose to say, well, I think that actually Jeff is, you know, pulling my chain. I withdraw my trust, but Wit doesn't see that in any time, any near real time. So he continues to trust Jeff based on my reputation. So this idea of cash store, the influence ripples of trust is a problem. And I don't know how you deal with that. I mean, this sounds similar to the revocation problem, right? You know, that if things change. The OSCP kind of? Yeah, exactly. That, you know, right now there's, you know, certificate authorities have the same problem. They issue these sign certificates. Maybe at some point they change their mind. And so there's supposed to be these revocation mechanisms that allow them to revoke their decision. Unfortunately, they don't actually work. And so that tends to break down. But I, you know, I think it's an ongoing question. And certainly we can, I think, all imagine revocation mechanisms that would work if they were just implemented correctly. Hi. First of all, I'd like to start with a comment on scoping so I can better place my question. I think that perhaps we speak of trust in a very, you know, one way that's true broad. And in my question, I was explicitly interested in terms of knowing that you got the correct public key for that particular website in context of SSL. I'm not talking about email encryption or other applications. And I wonder, and I would like to see both, we spoke earlier about this and I would like to hear with comment. If perhaps there is a simpler way. For instance, Tor puts a hash of the private key in the DNS name itself and the pseudo domain.onion. Why don't we do something like this natively in the browsers for so we could get away and get rid of these whole CA system? I think it would be a much simpler solution. Perhaps putting other layers over complicated things and complicated things have complicated modes of failure. They are hard to analyze. And simplicity, security and simplicity have a lot in common. But Dendo, aren't you shifting your trust to the DNS infrastructure? Sort of, which we already do when we are not. Why another layer? Yet another layer to create another failure. So that's sort of like the Dane or other proposals like that where you put your public key in DNS queries? Right. In the site name itself, say xlyz123 whatever big hash.com or.key or any TLD we choose for that. And I think that it's reuses what in a way or not we already trust what already works. And it doesn't add other layers of complexity to the whole system. And that's what I would like to hear their comments on this. Thank you. Well, I think when thinking about a lot of this stuff, one thing that we should be or one thing that I like about a simple pivot to something like convergence is that it doesn't require migrating the Internet. Right now the way that convergence works is the servers, people that are running services on the Internet don't have to do anything. They don't have to change anything. And I think it could be difficult to convince everybody that, okay, here's what we're going to do starting January 4th. Everyone's going to switch to domain names that are actually just long, incomprehensible hashes. And I think it would particularly be a hard sell if you go to somebody like Twitter and you're like, right, Twitter from now on instead of twitter.com you're going to be 732594, you know, some incredibly long string.twitter.com. Well, just notice how hard it's been to sell IPv6. Any other proposal of that kind for less than helling reasons? We can make this switch on the same day. Yes, so, Danily, in case I think IPv6 is, you know, its problems ought to be addressed at this moment by just stepping over it. I think we need IPv8, which has a good name and would have a 256-bit address space, and that it's time to, you know, often you give up on something that has opponents and you pick up a new thing that's substantively the same but better. I encourage everyone. It just seems to me like these trust organizations that you're talking about would tend to be, tend towards large organizations instead of small ones, I would think. And it seems like there's a lot of parallels to politics in this case in which if a politician has a lot of, you know, a large amount of power, they tend to have political terms of office and then they get, you know, they have to be re-elected in order, they have a specific delineation of time in which they have to be re-certified as trusted powers, right? I mean, doesn't it seem like we could enact a system like that where it's like, okay, well, in the year 2014, on January 1st, we have to decide whether we will continue with this large organization, Central Trust or go to a new one. I can give you my answer, which is perhaps unpopular, but the way that I wish that, you know, this term worked just like with all politicians is that that term expired every second. Where, you know, at any moment you can decide, well, you know, fuck these people. Well, yeah, but I mean, it's like users aren't going to want to decide every moment whether they trust anyone or decide on an individual basis. They want to set it and forget it. Well, you know, and again, I think maybe instead of saying users, we should say clients, because it doesn't have to actually be the end user. It can be whoever is providing the client, because, you know, that's their job to be making these kind of decisions. Does any of this remind you of the trusted users, trusted identities in Cyberspace initiative where you, no? The ticks, the proposal coming out of the US government to create the trusted online identities, you maybe have to give up more information, but in return you get a larger amount of trust in who you're connecting to, and they have a higher level of trust in you as a consumer. So the government is proposing this thing that sounds scary, and they called it tick? What, these people need a PR department, man. I think after you're very careful about this, I think it's, I've heard people say, you know, you're round for a while and get all these seminars about how we should have done the internet and this, that and the other. And I heard Kleinrock say, if we had to do over again, we'd build in strong authentication from the beginning. And I think no thing, nothing could be more profoundly mistaken, because if that had been done, and just incidentally, I don't think the tools were available to the area he's talking about, but that doesn't matter. The point is, suppose they succeeded, then they would have ended up with what Baron wrote about, what ARPANET was prototyped for, which is a national command and control system. They would not have ended up with the incredible cultural and economic force that the internet has become. So I think you have to worry in a lot of these things about doing anything that can tighten things up in such a way that you don't have the freedom to go out and explore, because everywhere you go, you will be well known and they will adjust what they tell you to fit who you are. So you're not probably a fan of Facebook's policy that everybody has to use their real name? Probably I'm not, but the fact is I'm fairly ignorant, I don't Facebook. I think there's a strong parallel between the trust problem with CAs and the trust problem we have with our bond rating services, but that's a side comment. Going to the model of the client driven trust, I can see a model where I don't sign your key unless you pass my vulnerability scan, for instance, but that creates a free rider problem and I was wondering if you have any comments on that. What is the free rider problem? I don't have to worry about scanning this because this other trust agency has already done it. Well, that sounds pretty much to me, lots of outsourcing decisions could be decided, could be described in the same way, right? If I've hired somebody to do this investigation, it seems if I do it again myself, there's some question, why did I throw away the money to hire those people to do it, or why do I bother to do it again, or can I explain why we did it from different perspectives and can expect different value from the work? You have notary A who has a strong vulnerability assessment, does it for X and X passes that vulnerability assessment, you have notary B who says, well, notary A trusts them, so I don't have to do a vulnerability assessment. They had to pay for it, these guys didn't, that's the free rider problem. I think that's handled in a lot of current things by the fact that your customer, your paying customer I think was X, gets things. Paying customers is the client who's paying either A or B. Yeah, and I think if you pay A you get information from A and if you don't pay them they don't send it to you or something, isn't that the way it usually works? Yeah, but if you pay B, B didn't have the overhead that A did. How did B learn what it told you? Because B subscribes to A as a client does. Oh, that sounds to me, okay, that has to be true of a whole lot of business relationships currently, so A sues B for, you know, the theft of intellectual property or something, I don't know. The answer is I don't know, maybe that's a problem. So quickly, on business incentives of running a notary, it occurs to me that I go home, I set up a notary and people start using it. I would have a significant amount of customer data which I could later resell. So is that a business incentive? Is that a legitimate thing? Is that something that you perceive is happening? Would they be removed from the trust chain at that point? Who are the customers in your model here? The customers would be some marketing firms or something. You're saying you have a large number of customer data? You said you have customer data. What is it you know other than what sites your customers would like to have some kind of form? IP address is linked to domain names of who they're looking for. And so you'd have correlation data of people that are going to a similar website. So it would be the same data that a name operator would collect? But then I would have it, though. So the way that convergence at least works right now is that by default your communication with the notaries is anonymized through another notary. So you turn, let's say you have ten notaries configured. For every request, you decide you're going to talk to nine of them. You turn one of them into a one-hot proxy, tunnel SSL through that one to the other nine. So now two notaries actually have to collude in order to reveal your browsing history. And also you only contact them on the first time you visit a site or win a certificate changes, which would be fairly rare. Excellent. Thank you. Okay. We've come to a fork in the road. I think you underestimate the audience. I count about 16 by 32, which is around 500. We've talked down 500 people. Gosh, we should feel pretty good. Okay. We've come to a fork in the road. Do we want to continue on this topic or shift? We've got about ten minutes left. We could just keep doing questions or we could talk about something else. You stirred this up. Why don't you think of a great new topic? I don't have a whole lot of great topics in my back pocket, but I'm always curious. And maybe you know why this happens. When I'm using my browser and I'm going through and I'm the same problem related to which ciphers do I trust? And the cipher suites or do I trust only TLS or only TLS V1.1 or V3 or SSL V2 or whatever. So I've been experimenting with some of my websites and I'll change on my web server what kind of certificates it hands out and then I'll pay attention to see what my browser crashes. And I've gotten it down out of my mobile devices and everything I have can support TLS 256 with Diffie Helman. But if I turn on AES 256 without Diffie Helman, the browsers prefer that over you. Why don't they like you? I think you're more secure. I think the Diffie Helman key exchange there is probably better for users. What's the alternative? You need some public key component, right? The alternatives are RSA? Yeah. And it seems to default to that. I don't know if that's a legacy of older browsers or not. Well, I'll give you a personalized answer since that's probably more fun than something else. One of the greatest mistakes I have made in my life is that RSA solves the public key problem in the way I formulated it. Diffie Helman solves the public key problem in the way Ralph Merkel formulated it. As a result, for years, I liked RSA better than I liked Diffie Helman. In retrospect, until we long time to understand that's a mistake for two reasons. One is deeper, both are important, one is deeper than the other. The deep one is that RSA has the problem that I hand you a modulus and say to you, hey, this is a good key, send me a secret. Well, I know there's some fancy protocols where I can prove to you that the modulus is good. They're not widely employed. But in the basic protocol, the whole thing that makes the system secure is that there's nothing much you can tell about the modulus from looking at it. And whereas in a Diffie Helman protocol, all the things that are secret are kind of uninteresting. You pick random numbers and you don't want them to be zero or one, and other than that, you don't much worry about them. So in terms of the truss structure, the Diffie Helman architecture, if less elegant about certain points of signature, I'm sorry, I probably should have said it's inadequate until you have El Gamal. Once you have Diffie Helman and El Gamal, then you have, what is now in, for example, Suite B, essentially, you have the two components. The other point is that RSA is a curious dead end. You can do it in quite a variety of rings, but none of them are better than the integers. Whereas with Diffie Helman, you can do it satisfactorily in quite a variety of number systems, and in particular, elliptic curve groups work a lot better than modular rings. And so, you know, why is RSA more popular? Well, in part, only one part, because I backed it rather than Diffie Helman. Oh, that's just nice. Is there a component between RSA and the Diffie Helman of sort of perfect forward secrecy? Well, I mean, Diffie Helman is the better thing for giving you forward secrecy, because it's very cheap in Diffie Helman to manufacture ephemeral keys. Manufacturing RSA keys, you can manufacture ephemeral ones, and some systems do, but it's expensive. So, on that topic, I'll shift it for a second. We'll take one or two more questions before we wrap up. On the concept of perfect forward secrecy, it seems like it would be a very good characteristic to have some of our communications, especially moving forward in sort of this perceived view of the world, where there's many organizations that might be monitoring you from your ISP who wants to better market to you to nefarious government organizations. So, if you could always be having the properties of PFS, that would be, that seems good. Then it really doesn't matter how much of my history they record. Like with PGP, they just get your key ten years later, and they get everything going back in time. Why don't we see more PFS in protocols? It was never really a consideration of the people who designed it. Just privacy doesn't enter their mind, and now we're trying to bolt it on into a system that was never really designed for. Or are there deeper reasons that I just haven't thought about? Well, I don't know deeper reasons. I mean, one, the phrase incidentally is misleading. I know it became a forward secrecy is an okay phrase. Shannon's term, perfect secrecy, referred to an information theoretic phenomenon that's not present here. This is not right. So, I just call it forward secrecy. NSA has a couple of terms, one of which is backpack protection, I can't think of the other one, that are sort of more operationally focused on what might happen. And if anybody doesn't know this stuff, it means, you know, if they get your key today, they can't use that to figure out what your key was yesterday. Because you've done something in between that really changes the two. And yes, I think it's a great idea. And it may be that there sort of was enough trouble just getting things to work without making them perfect. Any comments, Motsy? I mean, I think forward security is going to be something that's increasingly important, for the reasons you mentioned that today it's not unrealistic to think that there's some number of organizations that are just recording all of your ciphertext all the time. And maybe one day someone compromises your key and now all of that previous communication would be compromised as well. I used to work for a storage vendor. We really like that trend. And I mean, it is a little bit more expensive. And I think that that's probably why your web browser does not prefer the forward secure mode. Because, you know, there's a few extra operations in there. But, you know, also I feel like we've gotten to a point where that added cost is not significant. So how many people here, for example, defcon.org turned on only handing out Diffie helmet type keys and it's going to break some minor percentage. How many people think that's a valid trade off? Because see, then I as the operator, I'm making a decision to basically scare away a certain percentage. It can't do code sign. It can't get Diffie helmet's break. I love it. But it's a negotiation for a product. Yeah. Yeah, well, I presume, I don't actually know the product cause well. You don't, I mean, you don't support digital signature algorithm or something. Basically, my, I would be in a, I have to have a situation where I double a negotiation and purchase a section of the trade. Right. To read the document, read the code, something that's listening to it. So, it works, it works in a bunch of different cases, particularly the apparel part of it. It works in sign. Okay. Well, Diffie helmet as such doesn't sign, but El Gamal signatures are based on the same arithmetic and do sign. There's a second. Am I not? I'm sorry. Everything sounds so loud to me up here. It's talking about me. It's talking about you using the mic. Okay. Somebody came and put the mic closer to me. I didn't see why. No, just one point that there are as a secondary problem in signatures that sometimes you want it to sign fast and sometimes you want it to verify fast. And in particular, if you're signing code in the sense of a signed distribution of windows, you could take all week to sign it if you wanted to. What you wanted for it to verify in a fraction of a second when you want to load it and run it. And that's a more subtle problem. Yeah. I just wanted to make a comment that I think the most important point or the most important problem that we have with SSL or HTTPS now is websites are not using it or not using it enough. And as I work for Mozilla, and we are trying to make things faster, the speed is becoming one of the primary factors in this. So the idea of contacting a third party site, we're actually trying to do that less. So in the notary system, it would probably be a good idea to try and add in some mechanism so that the website you're contacting can proxy that data on the behalf of the notary so that you don't have to contact someone else. I would say that, so this is a good point, right? Speed is in speed important. I would say that actually with convergence, convergence is probably slightly faster than the existing CAVL edition because you only have to talk to the notary the first time you visit a website or for certificate changes. And then if the certificate hasn't changed, you have a local cache and it's a simple compare. You don't even have to do the cryptographic operations to check the signature. So it should be slightly faster in the common case, I would say. So the first time slower? Almost imperceptibly slower. You mentioned a point of information. You mentioned that I got the impression you wanted the Diffie Hellman chosen as a Cypher before RSA surface. Then you have two options. You can send him a patch or you can change browser to opera. And fill disclosure, I wrote that code. So can I ask you guys a question? Okay. All right, so it's my position that Dain, which is leveraging DNSSEC to replace the authenticity piece of SSL, is a bad idea because it doesn't provide trust agility and it will leave us in the exact same position. Now you guys work for ICANN. I agree with you. I think it's a bad idea. My fear is... I think DNSSEC is a good idea, incidentally. I just think pushing it to do other things is probably a mistake. My fear with DNSSEC is that people will say, now we have this new capability. We have sort of like a trusted directory and we ask it questions and it gives us stuff back and we can trust it. So wow, that's great. Maybe we should put some other stuff in there that I can trust, like a recipe or a picture of my cat. And businesses will come along and say, hey, that solves a whole bunch of stuff. We don't have to build a whole new protocol or anything. We'll just put it in DNS. Instead of maybe the traffic going over and being queried to HTTP, it will be queried over DNS. So maybe the traffic load equals out. So we're just shifting some packets from this service to that service. I fear that one day we're going to wake up and have these 200 meg zone files. Like what said, it wasn't really designed for that. But I don't really know how you prevent people from stuffing things in there. Well, I think as I can, you could say, this is a bad idea. IETF don't certify this protocol. Well, like for example, I was looking at the number of records you could put in DNS. There's, I don't know, 20 or 30 different things. It's okay to put your SSL certificates in there. It's okay to put your PGP certificates in there. Like how many, I don't know, how many Ruby resolver libraries actually know how to query a PGP key? I think they know how to do get host by name and that's it. They don't get PGP by name. And so even though we already have this functionality, nobody's really doing it yet. And so I don't know if I'm bringing up a point that's not going to be an issue. But that's one of my concerns. So I've been given this signal. Okay. Yeah, I was looking at dynamic phenomenon. There are both people getting up and people sitting down. So my question is, since I'm going to ask the question, is this, when does the Q&A start and where? So the Q&A will be in room one or A. What happened to the Q&A already? There's signs and what you can do is you can just follow agent X and myself and Moxie and we'll go into the Q&A room. But feeling if a lot of you follow us there, it'll probably get full. And that's just the way the rooms work. Okay, guys, I want to give you a round of applause for our two panelists.
 What we're doing here this morning is sort of a spontaneous panel that popped up maybe a month or two ago.  That's the best you can do for Spartan ideas.  Spartan ideas a month or two ago. Well, you know, I was thinking like I knew you and I knew you and Moxie was doing some interesting stuff and Witt was doing some interesting stuff.  And I forget what happened. It was like maybe Moxie was doing something about Dane, DNS Sack.  Something came up and I thought that would be perfect to get him talking with Witt.  And then I thought that would be perfect to get both of them on the stage because if I think it's cool maybe you guys will think it's cool.  So who's looking forward to seeing them just have a conversation?  Yeah.  So there's not a whole lot of format here. I've got a couple of questions to kick it off.  And what I'm really trying to do is kind of get new school and old school talking here.  And I'm really curious about how... Sorry if you're still new school Witt.  And because what we're seeing is there's a little bit of a different perspective.  Moxie maybe is more of an end user perspective. He grew up as a user of some of this technology just like myself.  And Witt was lucky enough to be around to be the creator of a lot of this technology and the designer.  And Moxie was there for a lot of the important meetings that shaped the way the Internet is today.  The way we do certain things online. The way we use certain math and certain cryptography.  Witt was there for that. And so they just naturally see the world slightly differently just from where they came from.  And then we definitely want to open it up to the audience because I think you'll probably get the most value asking questions.  So does that sound like a plan? That's what we're doing.  So first off, how many people saw Moxie's talk earlier?  So you're pretty familiar with some of his opinions.  And so one of my first questions I just want to get out of the way for... This is for Moxie is,  why the digital jihad against certificate authorities?  You know?  Okay. I don't know if it's a jihad, but I did start some of this by looking at the recent Komodo attacks.  People are familiar with this. Komodo got compromised.  And the attacks could not have been more embarrassing. The information that has emerged from these attacks makes it pretty clear that Komodo does not necessarily warrant our trust.  And the question is, what happened to Komodo after all of this? Could not have been more embarrassing. And nothing happened to Komodo.  And so I started looking at that question. Well, why is it that nothing happened to Komodo?  Will the U.S. fair as well after having its trade downgraded?  Will the U.S. fair as well?  I mean, it should encourage us that nothing happened to Komodo.  Oh, I see. Yeah, right.  Exactly.  So, looking at this question, I realized that there's really nothing that anybody can do.  The truth is that somewhere along the line, we made a decision to trust Komodo, and now we're locked into trusting them forever.  And I feel like this is the essence of many of the problems that we've seen with Certificate Authorities over the years, that we're kind of locked into trusting them, whether they continue to warrant our trust or not, without really any incentives to continue behaving appropriately.  And so...  And then your options as an end user are very limited.  And I think I could say your options as a client are limited.  As an end user, there's nothing really you can do, and the browser vendors are in the same position.  And Komodo knows it.  Komodo knows that the browser vendors can't just remove them from their trust database because it would break somewhere between a quarter and a fifth of the internet for their users.  So, I feel like we can reduce this to a single missing property that I call trust agility, and the idea behind trust agility is that it should be easy to trust and untrust somebody.  It should be easy to make trust decisions at any point, and that those trust decisions should be initiated by the client.  And I feel like with those two properties moving forward, we won't get into the same situation that we are in now.  And so there's been a lot of talk about replacing the CA system with something else, and I just want to make sure that we don't end up in the same place again.  And I think the way to do that is to come up with a replacement that provides trust agility.  Any comments on that?  Well, no comments that are different from what I had before he said that.  Let me start out with a few procedural comments, which was I'm dressed for security theater at the airport.  And it seems to me appropriate to change for allegedly intellectual theater here at the conference or something like that.  Now, I was told when I was, I've never been to DEF CON before, and I was told that I was required to drink a glass of whiskey before I spoke.  Was this...  Well, Donner-Plaude's allowed. I haven't done it yet.  I assume what that meant is I had visibly to drink my whiskey.  You know, he's going for the 40-year-old LeFrog.  To visibly drink my whiskey here in the presence of the witnesses.  You know, just the way there were many people at court in the European court, so I had the right to witness the royal birth.  Be sure that the baby was the right one.  So I think my whiskey is being fetched.  So the first few words I speak will be unauthentic,  receiving the whiskey, but after that, you know, you can have more trust in what I have to say.  I mean, basically I'm here like most things in my life by accident.  Jeff sent me, incidentally, I really appreciate the name Moxie Marlin Spike.  You know, it was hard growing up with the name Whitfield Diffie in a Jewish neighborhood in New York.  And somebody wants to have the name Moxie Marlin Spike.  That's courageous.  But basically I read this article and my response was to think, my gosh, I mean, either, I can't quite figure out,  either he's made the greatest observation about the way this needs to work in decades,  or he's led me to the observation because I don't say things quite the same way.  So let me just say what I learned from Moxie's article and it now seems to me obvious what should be done  and it turns into a business problem of how to get it to work.  And the simple thing I learned, and it started out with a point in which I disagreed with him.  He said it wouldn't make any sense for DHS to be issuing certificates for Chinese websites.  And I thought, well, no, that's wrong.  It makes very good sense for DHS to issue web certificates for Chinese websites.  It just doesn't seem likely that those are going to be particularly interesting to the Chinese, right?  A Chinese doing business in China doesn't care what DHS thinks about Chinese websites,  but an American business or an American government organization interacting with Chinese companies  and organizations and so forth might even be bound, but rationally bound by regulation  to only conduct certain communications using certificates supplied by the DHS website.  That seems to me an entirely reasonable idea.  And in general, what I learned is that basically CAs work for the wrong people.  CAs should be working for the people who want to acquire keys, not for the people who are wanting to profit keys.  And that's where the trial and work for, and here's the rub, largely means of course as always, paid by.  So think about some other things that I think have about the same structure.  That is to say, you're going to hire somebody, you're allowed to have that person investigated.  You go make certain choices.  You choose, you know, I know, Burns detective agency to investigate them, or some other detective agency.  You go to Equifax or some other place to investigate the credit.  But it's the people doing the people who want the answer, who are responsible for getting the investigators to find out what they want to know.  Well, similarly, you know, if you are a business of some kind or other and you want to do business reliable,  you don't really care about browsing every website on the web.  Who cares?  You want to be sure that when you're talking to IBM, you're talking to IBM.  When you're talking to Microsoft, you're talking to Microsoft.  When you're talking to NSA, you're talking to NSA.  And so you want to go to what Moxie is calling a notary.  And I think I don't have a better term.  I'm not quite comfortable with that one, but I'll use it for the moment.  You want to go to somebody in effect that you retain who issues certificates for people you want to talk to.  Now, there are two things about this.  In my mind, this organization need neither be friends of the people it's issuing certificates for,  nor even be known to them.  So it could do anything.  I mean, the cheapest ones just parrot whatever the whatever certificate those websites issue for themselves.  Things are picking up.  Just keep going.  Thank you.  Fortunately, they drive me all around town.  That's right.  I see.  Okay.  I don't get whiskey at all.  I get rye.  I don't get scotch at all.  I get rye.  Okay.  So are any like drinking rye?  Who knows what's going to happen?  Any last words before you have to be authentic?  No.  What was I saying?  So you might have an investigatory organization that you retained that goes out, you know,  flat foot around and does the kind of things accounting companies do and investigates the  companies you want to communicate with.  And by whatever means, it seems appropriate.  It figures out what their keys are and then it issues your certificates for those keys.  The other aspect of doing these things this way is, of course, there's going to be a new mode of failure that's going to appear.  That is to say, the rules of my organization say I will never talk to your organization unless you present the rules.  Unless you present the key that is in the certificate I got from my trusted notary.  And so if you send me some other key, the communication just dies there, right?  You're presumably not going to understand things that I encrypt in the key I was sent and I'm not willing to encrypt anything in the key you sent.  But by and large, I'm going to expect this will work reasonably well.  That's not going to happen that often.  And of course, it triggers an investigation.  And you may, certain sprinkling of these, you will have rekeyed or something like that and it will have to be updated.  So that's, we've pretty much come to the end of my pre-Whiskey statement.  So I think while I drink my whiskey, I'll turn things back over to my cohorts.  So, Moxie, the idea of notary sort of reminds me of the concept of trust anchors in the early days of DNSSEC when they're still trying to get the root  signed and the TLE signed, people still wanted stuff to work.  So they came up with the trust anchor concept.  And the notary seemed fairly similar.  Or have you gotten some ideas from that?  Sure.  I think it's a similar concept and the difference as far as I can tell, and maybe I don't know enough about trust anchors,  is that the trust anchors were still sort of predefined by someone that wasn't the user.  Whereas with the notary concept, anybody really in the world right now can decide to run a notary.  And if anybody trusts you, then they can use you as a notary.  It's sort of like a popularity contest.  I get half the room to trust me, you get half the room to trust you, the whole room can somehow reach where they want to go.  Exactly, exactly.  And maybe half of the room, and I think that's appropriate, maybe half of the room is in a situation where they trust you for whatever reason.  And the other half of the room is in a situation where they don't trust you for whatever reason.  And maybe they trust me instead or some other organization.  And I think that that's how the world works.  And there can be overlap too, right?  Exactly.  There can be overlap.  And I think the important distinction there between this and the DNS Act Trust anchors is that I think we've gone to a point in time where it doesn't really make a lot of sense for one entity or one organization to be making a decision about how everybody in the world should engage with the authenticity of that website.  And I think that's a good point because different people are in different contexts with different threats and different ideas of who they trust in the world.  And it's really, it's our data.  It's the user's data that's at risk, not the service's data that's at risk in most cases.  And so I think it should be up to the clients, it should be up to the users to decide who they're going to trust to certify their data.  So would you say looking back that users have made really well informed decisions over the last...  Okay, this is a fair question, right?  You know, if we're putting this on the user, our user isn't as too complex, right?  And I think that really instead of user, we should be saying client.  Okay.  Because, you know, the way that I would imagine this is that you get your web browser, you know, Mozilla or Chrome or whatever web browser you choose.  And embedded within it is a set of same defaults, you know, that the organization like Mozilla has chosen organizations that they think, you know, are sort of generally trustworthy.  And maybe they have it localized, you know, maybe they have, you know, they already have localized versions of their browsers, maybe they have those notaries localized for different areas of the world.  But then the... if a user, like an advanced user, wishes to modify that, it's very easy for them to do so.  And if Mozilla needs or Chrome or whoever needs to make a different decision about how to distribute these things, they can really easily change it, unlike now.  Yeah, so it gives them at least the initial level of flexibility that they didn't have.  Exactly.  And then hopefully that will trickle down then to the advanced users.  Yeah.  When he's talking about half of the people in the room, I suddenly came to what I think of as the Casanova model.  Half of the people in the room trust him because there is a girlfriend.  And the other half don't trust him because he stole their girlfriend.  I think there is a, you know, I envision there's a certain possibility here for a graduation of trust that would be very useful.  Namely, if we've gotten a certificate from our notary that indicates trust in this organization, then maybe we can connect to them, for example, without any firewall.  We can get a much better performance and so forth.  Whereas if we, you know, we have levels of trust and if we don't acquire keys for them that way, then we treat them as more hostile and we, you know, do a deep packet inspection on everything they send us, et cetera.  So you can make a great graduated decision on trust.  That's right.  It's not either, yeah, all or nothing.  Can I want to take a question from the audience?  In the front row?  Come have a microphone. We have an abundance.  Yeah, I think there's, there used to be in one of the aisles, no I don't see it.  Have this microphone.  Here, we'll just give them this one.  Alright, thanks.  Just name and...  Okay, my name is White Kesterson.  I am also old school.  As both of these guys know, I chaired the committee that invented X509.  So...  Alright, the interesting thing is when I draw back and I hear about these trust models, I'm reminded of PGP signing parties.  Okay, that's exactly what I'm reminded of.  And let me tell you where the problem comes from, from these kind of communities.  They may work in certain ways.  I hang with way too many lawyers.  Okay, and the problem of this kind of distributed trust model is what kind of business liability are you assuming?  So when you say, I want to open a CA, or when I, or your version of a CA, which is a notary, then the question is, what's the business model from them?  And here's my problem.  We actually, you know, put together a program that said, CAs were supposed to operate responsibly, right?  They're supposed to do certain things.  And when the first ones came out, they had a little bit more discipline.  But when the other ones came out, they lowered their prices, they lowered their prices.  And now, you know, you have GoDaddy, which does a really horrible job and a couple of other people that do that.  But people want certificates and they go to it.  And I just don't...  And that's the economic model.  That's what drives it, because we're laissez-faire.  We don't really enforce these kind of things.  So I just don't see how, when you put another model together, I do like, incidentally, the voting portion of it.  I think perhaps we might be able to do that with actually having servers present multiple certificates from multiple providers.  Hopefully you find what someone you trust.  But I don't understand why you think that the same economic model won't happen.  That there'll be there doing a reasonable job for a reasonable-saw community, then it gets bigger, then it gets more costly.  Then I have lawyers telling me about the risk, I'm assuming.  So I start charging money, more money, more money to do a decent job.  And then someone uncuts me, undercuts me in terms of pricing to do a less decent job, and then we end up with Komodo.  And so I basically see nothing there that stops the same iteration of the business process.  That's it.  Okay, so I'm not really sure I follow that in terms of the vision, the way I envision this.  Why don't you leave the mic with him for a second.  I mean, as I said, we have, it seems to me, a variety of things that work pretty much the same way.  In which you choose a detective service, an accountant, or something like that that has to be trusted, and you pay them.  And they bear, that is actually a case where if they have a contractual obligation, and so they will actually suffer for delivering you bad information.  No, I agree with that.  I don't mind with the flipping of the model, but what I'm arguing is that there, when we talk about the common person,  the one who's already trying to figure out what's going on in that little bar in his browser,  I personally think the client's got a little too thin here, right?  Yeah, let me say for the record, I can't figure it out.  So I think we've got a little too thin here in terms of people trying to make decisions and all the information that's up there.  But my argument is exactly the same, that people are out buying, they're buying based on certain kinds of things,  and they'll end up buying based on cost.  Okay, that's what people do.  They buy based on cost.  And so my argument is that we end up with the same thing, low-cost cutting type things and same risk.  I think they buy on cost versus perceived quality or something.  I mean, lots of people buy Mercedes as opposed to buying much cheaper cars, right?  Lots of expensive goods sell.  It's just, the problem with the market is that you can't see the difference in what you're getting, so why spend more for it?  I think that's because people who buy Mercedes probably have an innate understanding about cars and quality and so forth.  They might be wrong about it, but they think they do.  I just don't know if we're going to find this innate understanding in trust models.  You don't need anything innate understanding.  You put your foot on the gas and the whole ass through a turn and you feel the difference between that and that.  You don't know the thermodynamics of what's going on.  I'm imagining that some of these investigative agencies, they might be NGOs, it might be the EFF, it could be anybody, right?  Yeah, I mean it could be anybody.  So I've released some software called Convergence, which is an early stab at inverting this trust relationship and doing things a different way.  And the way it works, Convergence, anybody can run a notary.  And it actually requires very low resources.  It's not an intensive process for somebody to run a notary.  And already there's been some number of people in the past two days who have set up their own notaries.  And I've received communication from security companies and NGOs who are interested in running notaries of their own.  Maybe even one certificate authority was interested in running a notary.  So I think that people are interested in running this even if it does not provide any immediate revenue because it looks good.  It's just like security companies do a lot of things in this industry without taking any direct cash for it because they want to be seen as trusted entities.  Sort of like the lost leader.  Yes, yes.  One thing may be necessary, you know, I had a remark in your paper about how Verisign could sign a certificate for somebody even if the person didn't want it.  And that just strikes me as inevitable, of course. You can sign anything and get your hands on.  But the critical, maybe we need a more expressive language to have to go into the browser for saying what you trust about certain sources.  I'm going to call them notaries. You say, you know, we trust this notary to endorse that category of things and have explicit, you know,  you might explicitly, well, we think they made a mistake in that case.  We'll blacklist that one. I don't know precisely. All sounds very XML-ish.  Oh, no, oh, no.  Yeah.  As long as it doesn't sound ASN one-ish.  Since we're stuck using primarily low assurance to no assurance systems, do you see any sane approach to prevent subversion of the trusted list or the certificate authority list?  I'm thinking of the example where about a year or two ago Microsoft released a security update that actually modified the CA list for Mozilla Firefox.  So the question is, is there any mechanism to prevent subversion of these default lists themselves?  Anything that you can see, particularly since you're working in an untrusted environment.  Sure. Well, I mean, I think, you know, in the case of organizations like Microsoft or any of the browser vendors themselves,  that they, you know, at heart are trying to actually provide secure communication for their users.  Now, I think, you know, let me ask, does anybody in this room trust Komodo?  One, two, three. Okay. Three people.  People don't work for them.  Yeah. Where do you guys work?  Just trust them to do what?  Just certify your secure communication.  Trust them to do it.  You know, I feel, you know, there's maybe a couple hundred people here, maybe one or two people trust Komodo.  And I think that the browser vendors and the platforms actually feel the same way.  And I think if they could, they would also make a decision to untrust Komodo.  But they can't do it.  And so, you know, this is the situation we're in.  And I think that if we give, you know, these platforms the mechanism to make the appropriate decisions,  that they will, in good faith, make the appropriate default decisions.  Well, hypothetically, let's say you're a dissident in Iran.  The Iranian government has a CA, which I noted was in my trusted CA list by default.  I removed it. But how exactly would you expect a user to deal with that if it is subverbed and re-added?  Because it's assumed to be trusted by your vendor.  And you might have no warning that gets re-added to the list.  You know, I think that that's maybe a different class of problems, right?  But one thing you can imagine, right, is, you know, right now platforms like the web browser or your operating system  are essentially delegating some trust decisions for you, right, that they're, you're almost subscribing to them  for some information on who to trust.  And you can imagine something similar to an ad block plus model, right, where you don't have to make, you know,  very intricate decisions about all the entities in the world that you trust.  And you can say, well, there's this other organization, this NGO, that's going to curate these kind of lists for you.  So it's like a, you know, a meta notary or something like that.  You know, maybe you have something like that. I'm not sure.  But what I want to do is at least provide the kind of flexibility so that these decisions can actually be made however they're made.  Okay. Now, I don't want to turn the track into nothing but, you know, rant against the CAs.  But we're going to take a couple more questions in that thread, and we're going to try to shift maybe the focus a little bit.  So let's, uh...  Hello, Bill Manning. And I'm going to take both of those questions.  Okay.  The first one has to do with, you said notary. Notary reputation. Who does that? Number one.  And the second, I will call it trust echoes.  Trust what?  Trust echoes.  Echoes.  How many people in the room have one device with one browser? Only one.  I have a device that only has one browser.  No, no, no, no, no, no, no.  Right. How many people have multiple devices with multiple ways to get to the net?  Everybody's hand should go up.  Okay. So if I want to update Mozilla Firefox on my MacBook Pro 15, who's going to update my Android?  Who's going to update my iPhone? Who's going to update the box that's been sitting on the desk or sitting on the shelf for the last three months?  Right. I'm going to forget these things. So the idea of updating all of the trust on all of the devices simultaneously is problematic.  And then there's also the problem of if I trust something and Wit decides that he trusts me for whatever reason.  He's had too much whiskey or rye.  Um, and I choose to say, well, I think that actually Jeff is, you know, pulling my chain.  I withdraw my trust, but Wit doesn't see that in any time, any near real time.  So he continues to trust Jeff based on my reputation.  So this idea of cash store, the influence ripples of trust is a problem.  And I don't know how you deal with that.  I mean, this sounds similar to the revocation problem, right? You know, that if things change.  The OSCP kind of? Yeah, exactly.  That, you know, right now there's, you know, certificate authorities have the same problem.  They issue these sign certificates. Maybe at some point they change their mind.  And so there's supposed to be these revocation mechanisms that allow them to revoke their decision.  Unfortunately, they don't actually work.  And so that tends to break down.  But I, you know, I think it's an ongoing question.  And certainly we can, I think, all imagine revocation mechanisms that would work if they were just implemented correctly.  Hi. First of all, I'd like to start with a comment on scoping so I can better place my question.  I think that perhaps we speak of trust in a very, you know, one way that's true broad.  And in my question, I was explicitly interested in terms of knowing that you got the correct public key for that particular website in context of SSL.  I'm not talking about email encryption or other applications.  And I wonder, and I would like to see both, we spoke earlier about this and I would like to hear with comment.  If perhaps there is a simpler way.  For instance, Tor puts a hash of the private key in the DNS name itself and the pseudo domain.onion.  Why don't we do something like this natively in the browsers for so we could get away and get rid of these whole CA system?  I think it would be a much simpler solution.  Perhaps putting other layers over complicated things and complicated things have complicated modes of failure.  They are hard to analyze.  And simplicity, security and simplicity have a lot in common.  But Dendo, aren't you shifting your trust to the DNS infrastructure?  Sort of, which we already do when we are not.  Why another layer?  Yet another layer to create another failure.  So that's sort of like the Dane or other proposals like that where you put your public key in DNS queries?  Right. In the site name itself, say xlyz123 whatever big hash.com or.key or any TLD we choose for that.  And I think that it's reuses what in a way or not we already trust what already works.  And it doesn't add other layers of complexity to the whole system.  And that's what I would like to hear their comments on this. Thank you.  Well, I think when thinking about a lot of this stuff, one thing that we should be or one thing that I like about  a simple pivot to something like convergence is that it doesn't require migrating the Internet.  Right now the way that convergence works is the servers, people that are running services on the Internet  don't have to do anything. They don't have to change anything.  And I think it could be difficult to convince everybody that, okay, here's what we're going to do starting January 4th.  Everyone's going to switch to domain names that are actually just long, incomprehensible hashes.  And I think it would particularly be a hard sell if you go to somebody like Twitter and you're like, right, Twitter from now on  instead of twitter.com you're going to be 732594, you know, some incredibly long string.twitter.com.  Well, just notice how hard it's been to sell IPv6.  Any other proposal of that kind for less than helling reasons?  We can make this switch on the same day.  Yes, so, Danily, in case I think IPv6 is, you know, its problems ought to be addressed at this moment by just stepping over it.  I think we need IPv8, which has a good name and would have a 256-bit address space, and that it's time to, you know,  often you give up on something that has opponents and you pick up a new thing that's substantively the same but better.  I encourage everyone.  It just seems to me like these trust organizations that you're talking about would tend to be, tend towards large organizations instead of small ones, I would think.  And it seems like there's a lot of parallels to politics in this case in which if a politician has a lot of, you know, a large amount of power,  they tend to have political terms of office and then they get, you know, they have to be re-elected in order,  they have a specific delineation of time in which they have to be re-certified as trusted powers, right?  I mean, doesn't it seem like we could enact a system like that where it's like, okay, well, in the year 2014, on January 1st,  we have to decide whether we will continue with this large organization, Central Trust or go to a new one.  I can give you my answer, which is perhaps unpopular, but the way that I wish that, you know, this term worked just like with all politicians is that  that term expired every second.  Where, you know, at any moment you can decide, well, you know, fuck these people.  Well, yeah, but I mean, it's like users aren't going to want to decide every moment whether they trust anyone or decide on an individual basis.  They want to set it and forget it.  Well, you know, and again, I think maybe instead of saying users, we should say clients, because it doesn't have to actually be the end user.  It can be whoever is providing the client, because, you know, that's their job to be making these kind of decisions.  Does any of this remind you of the trusted users, trusted identities in Cyberspace initiative where you, no?  The ticks, the proposal coming out of the US government to create the trusted online identities, you maybe have to give up more information,  but in return you get a larger amount of trust in who you're connecting to, and they have a higher level of trust in you as a consumer.  So the government is proposing this thing that sounds scary, and they called it tick?  What, these people need a PR department, man.  I think after you're very careful about this, I think it's, I've heard people say, you know, you're round for a while and get all these seminars about how we should have done the internet and this, that and the other.  And I heard Kleinrock say, if we had to do over again, we'd build in strong authentication from the beginning.  And I think no thing, nothing could be more profoundly mistaken, because if that had been done, and just incidentally, I don't think the tools were available to the area he's talking about, but that doesn't matter.  The point is, suppose they succeeded, then they would have ended up with what Baron wrote about, what ARPANET was prototyped for, which is a national command and control system.  They would not have ended up with the incredible cultural and economic force that the internet has become.  So I think you have to worry in a lot of these things about doing anything that can tighten things up in such a way that you don't have the freedom to go out and explore, because everywhere you go, you will be well known and they will adjust what they tell you to fit who you are.  So you're not probably a fan of Facebook's policy that everybody has to use their real name?  Probably I'm not, but the fact is I'm fairly ignorant, I don't Facebook.  I think there's a strong parallel between the trust problem with CAs and the trust problem we have with our bond rating services, but that's a side comment.  Going to the model of the client driven trust, I can see a model where I don't sign your key unless you pass my vulnerability scan, for instance, but that creates a free rider problem and I was wondering if you have any comments on that.  What is the free rider problem?  I don't have to worry about scanning this because this other trust agency has already done it.  Well, that sounds pretty much to me, lots of outsourcing decisions could be decided, could be described in the same way, right?  If I've hired somebody to do this investigation, it seems if I do it again myself, there's some question, why did I throw away the money to hire those people to do it, or why do I bother to do it again, or can I explain why we did it from different perspectives and can expect different value from the work?  You have notary A who has a strong vulnerability assessment, does it for X and X passes that vulnerability assessment, you have notary B who says, well, notary A trusts them, so I don't have to do a vulnerability assessment.  They had to pay for it, these guys didn't, that's the free rider problem.  I think that's handled in a lot of current things by the fact that your customer, your paying customer I think was X, gets things.  Paying customers is the client who's paying either A or B.  Yeah, and I think if you pay A you get information from A and if you don't pay them they don't send it to you or something, isn't that the way it usually works?  Yeah, but if you pay B, B didn't have the overhead that A did.  How did B learn what it told you?  Because B subscribes to A as a client does.  Oh, that sounds to me, okay, that has to be true of a whole lot of business relationships currently, so A sues B for, you know, the theft of intellectual property or something, I don't know.  The answer is I don't know, maybe that's a problem.  So quickly, on business incentives of running a notary, it occurs to me that I go home, I set up a notary and people start using it.  I would have a significant amount of customer data which I could later resell.  So is that a business incentive? Is that a legitimate thing? Is that something that you perceive is happening?  Would they be removed from the trust chain at that point?  Who are the customers in your model here?  The customers would be some marketing firms or something.  You're saying you have a large number of customer data?  You said you have customer data. What is it you know other than what sites your customers would like to have some kind of form?  IP address is linked to domain names of who they're looking for.  And so you'd have correlation data of people that are going to a similar website.  So it would be the same data that a name operator would collect?  But then I would have it, though.  So the way that convergence at least works right now is that by default your communication with the notaries is anonymized through another notary.  So you turn, let's say you have ten notaries configured.  For every request, you decide you're going to talk to nine of them.  You turn one of them into a one-hot proxy, tunnel SSL through that one to the other nine.  So now two notaries actually have to collude in order to reveal your browsing history.  And also you only contact them on the first time you visit a site or win a certificate changes, which would be fairly rare.  Excellent. Thank you.  Okay. We've come to a fork in the road.  I think you underestimate the audience.  I count about 16 by 32, which is around 500.  We've talked down 500 people.  Gosh, we should feel pretty good.  Okay. We've come to a fork in the road.  Do we want to continue on this topic or shift?  We've got about ten minutes left.  We could just keep doing questions or we could talk about something else.  You stirred this up. Why don't you think of a great new topic?  I don't have a whole lot of great topics in my back pocket, but I'm always curious.  And maybe you know why this happens.  When I'm using my browser and I'm going through and I'm the same problem related to which ciphers do I trust?  And the cipher suites or do I trust only TLS or only TLS V1.1 or V3 or SSL V2 or whatever.  So I've been experimenting with some of my websites and I'll change on my web server what kind of certificates it hands out  and then I'll pay attention to see what my browser crashes.  And I've gotten it down out of my mobile devices and everything I have can support TLS 256 with Diffie Helman.  But if I turn on AES 256 without Diffie Helman, the browsers prefer that over you.  Why don't they like you?  I think you're more secure.  I think the Diffie Helman key exchange there is probably better for users.  What's the alternative? You need some public key component, right?  The alternatives are RSA?  Yeah.  And it seems to default to that.  I don't know if that's a legacy of older browsers or not.  Well, I'll give you a personalized answer since that's probably more fun than something else.  One of the greatest mistakes I have made in my life is that RSA solves the public key problem in the way I formulated it.  Diffie Helman solves the public key problem in the way Ralph Merkel formulated it.  As a result, for years, I liked RSA better than I liked Diffie Helman.  In retrospect, until we long time to understand that's a mistake for two reasons.  One is deeper, both are important, one is deeper than the other.  The deep one is that RSA has the problem that I hand you a modulus and say to you,  hey, this is a good key, send me a secret.  Well, I know there's some fancy protocols where I can prove to you that the modulus is good.  They're not widely employed.  But in the basic protocol, the whole thing that makes the system secure is that there's nothing much you can tell about the modulus from looking at it.  And whereas in a Diffie Helman protocol, all the things that are secret are kind of uninteresting.  You pick random numbers and you don't want them to be zero or one, and other than that, you don't much worry about them.  So in terms of the truss structure, the Diffie Helman architecture,  if less elegant about certain points of signature, I'm sorry, I probably should have said it's inadequate until you have El Gamal.  Once you have Diffie Helman and El Gamal, then you have, what is now in, for example, Suite B, essentially, you have the two components.  The other point is that RSA is a curious dead end.  You can do it in quite a variety of rings, but none of them are better than the integers.  Whereas with Diffie Helman, you can do it satisfactorily in quite a variety of number systems,  and in particular, elliptic curve groups work a lot better than modular rings.  And so, you know, why is RSA more popular?  Well, in part, only one part, because I backed it rather than Diffie Helman.  Oh, that's just nice.  Is there a component between RSA and the Diffie Helman of sort of perfect forward secrecy?  Well, I mean, Diffie Helman is the better thing for giving you forward secrecy,  because it's very cheap in Diffie Helman to manufacture ephemeral keys.  Manufacturing RSA keys, you can manufacture ephemeral ones, and some systems do, but it's expensive.  So, on that topic, I'll shift it for a second.  We'll take one or two more questions before we wrap up.  On the concept of perfect forward secrecy, it seems like it would be a very good characteristic to have  some of our communications, especially moving forward in sort of this perceived view of the world,  where there's many organizations that might be monitoring you from your ISP who wants to better market to you  to nefarious government organizations.  So, if you could always be having the properties of PFS, that would be, that seems good.  Then it really doesn't matter how much of my history they record.  Like with PGP, they just get your key ten years later, and they get everything going back in time.  Why don't we see more PFS in protocols?  It was never really a consideration of the people who designed it.  Just privacy doesn't enter their mind, and now we're trying to bolt it on into a system that was never really designed for.  Or are there deeper reasons that I just haven't thought about?  Well, I don't know deeper reasons.  I mean, one, the phrase incidentally is misleading.  I know it became a forward secrecy is an okay phrase.  Shannon's term, perfect secrecy, referred to an information theoretic phenomenon that's not present here.  This is not right.  So, I just call it forward secrecy.  NSA has a couple of terms, one of which is backpack protection, I can't think of the other one,  that are sort of more operationally focused on what might happen.  And if anybody doesn't know this stuff, it means, you know, if they get your key today,  they can't use that to figure out what your key was yesterday.  Because you've done something in between that really changes the two.  And yes, I think it's a great idea.  And it may be that there sort of was enough trouble just getting things to work without making them perfect.  Any comments, Motsy?  I mean, I think forward security is going to be something that's increasingly important,  for the reasons you mentioned that today it's not unrealistic to think that there's some number of organizations  that are just recording all of your ciphertext all the time.  And maybe one day someone compromises your key and now all of that previous communication would be compromised as well.  I used to work for a storage vendor.  We really like that trend.  And I mean, it is a little bit more expensive.  And I think that that's probably why your web browser does not prefer the forward secure mode.  Because, you know, there's a few extra operations in there.  But, you know, also I feel like we've gotten to a point where that added cost is not significant.  So how many people here, for example, defcon.org turned on only handing out Diffie helmet type keys  and it's going to break some minor percentage.  How many people think that's a valid trade off?  Because see, then I as the operator, I'm making a decision to basically scare away a certain percentage.  It can't do code sign. It can't get Diffie helmet's break. I love it.  But it's a negotiation for a product.  Yeah.  Yeah, well, I presume, I don't actually know the product cause well.  You don't, I mean, you don't support digital signature algorithm or something.  Basically, my, I would be in a, I have to have a situation where I double a negotiation  and purchase a section of the trade.  Right.  To read the document, read the code, something that's listening to it.  So, it works, it works in a bunch of different cases, particularly the apparel part of it.  It works in sign.  Okay.  Well, Diffie helmet as such doesn't sign, but El Gamal signatures are based on the same arithmetic  and do sign.  There's a second. Am I not? I'm sorry. Everything sounds so loud to me up here.  It's talking about me.  It's talking about you using the mic. Okay. Somebody came and put the mic closer to me.  I didn't see why.  No, just one point that there are as a secondary problem in signatures that sometimes you want  it to sign fast and sometimes you want it to verify fast.  And in particular, if you're signing code in the sense of a signed distribution of windows,  you could take all week to sign it if you wanted to.  What you wanted for it to verify in a fraction of a second when you want to load it and run it.  And that's a more subtle problem.  Yeah.  I just wanted to make a comment that I think the most important point or the most important  problem that we have with SSL or HTTPS now is websites are not using it or not using it  enough.  And as I work for Mozilla, and we are trying to make things faster, the speed is becoming  one of the primary factors in this.  So the idea of contacting a third party site, we're actually trying to do that less.  So in the notary system, it would probably be a good idea to try and add in some mechanism  so that the website you're contacting can proxy that data on the behalf of the notary  so that you don't have to contact someone else.  I would say that, so this is a good point, right?  Speed is in speed important.  I would say that actually with convergence, convergence is probably slightly faster than  the existing CAVL edition because you only have to talk to the notary the first time you visit  a website or for certificate changes.  And then if the certificate hasn't changed, you have a local cache and it's a simple  compare.  You don't even have to do the cryptographic operations to check the signature.  So it should be slightly faster in the common case, I would say.  So the first time slower?  Almost imperceptibly slower.  You mentioned a point of information.  You mentioned that I got the impression you wanted the Diffie Hellman chosen as a Cypher  before RSA surface.  Then you have two options.  You can send him a patch or you can change browser to opera.  And fill disclosure, I wrote that code.  So can I ask you guys a question?  Okay.  All right, so it's my position that Dain, which is leveraging DNSSEC to replace the  authenticity piece of SSL, is a bad idea because it doesn't provide trust agility and it will  leave us in the exact same position.  Now you guys work for ICANN.  I agree with you.  I think it's a bad idea.  My fear is...  I think DNSSEC is a good idea, incidentally.  I just think pushing it to do other things is probably a mistake.  My fear with DNSSEC is that people will say, now we have this new capability.  We have sort of like a trusted directory and we ask it questions and it gives us stuff  back and we can trust it.  So wow, that's great.  Maybe we should put some other stuff in there that I can trust, like a recipe or a picture  of my cat.  And businesses will come along and say, hey, that solves a whole bunch of stuff.  We don't have to build a whole new protocol or anything.  We'll just put it in DNS.  Instead of maybe the traffic going over and being queried to HTTP, it will be queried  over DNS.  So maybe the traffic load equals out.  So we're just shifting some packets from this service to that service.  I fear that one day we're going to wake up and have these 200 meg zone files.  Like what said, it wasn't really designed for that.  But I don't really know how you prevent people from stuffing things in there.  Well, I think as I can, you could say, this is a bad idea.  IETF don't certify this protocol.  Well, like for example, I was looking at the number of records you could put in DNS.  There's, I don't know, 20 or 30 different things.  It's okay to put your SSL certificates in there.  It's okay to put your PGP certificates in there.  Like how many, I don't know, how many Ruby resolver libraries actually know how to query a PGP key?  I think they know how to do get host by name and that's it.  They don't get PGP by name.  And so even though we already have this functionality, nobody's really doing it yet.  And so I don't know if I'm bringing up a point that's not going to be an issue.  But that's one of my concerns.  So I've been given this signal.  Okay.  Yeah, I was looking at dynamic phenomenon.  There are both people getting up and people sitting down.  So my question is, since I'm going to ask the question, is this, when does the Q&A start and where?  So the Q&A will be in room one or A.  What happened to the Q&A already?  There's signs and what you can do is you can just follow agent X and myself and Moxie and we'll go into the Q&A room.  But feeling if a lot of you follow us there, it'll probably get full.  And that's just the way the rooms work.  Okay, guys, I want to give you a round of applause for our two panelists.
DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_0_2963.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_2964_3119.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_3120_3179.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_3180_3239.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_3240_3287.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_3288_3539.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_3540_4703.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_4704_6707.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_6708_7607.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_7608_7655.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_7656_7775.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_7776_7823.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_7824_8075.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_8076_8135.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_8136_8267.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_8268_8339.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_8340_8399.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_8400_8447.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_8448_9563.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_9564_9611.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_9612_10943.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_10944_13175.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_13176_13835.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_13836_15899.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_15900_15983.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_15984_16511.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_16512_17351.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_17352_17723.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_17724_20411.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_20412_21863.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_21864_25331.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_25332_26951.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_26952_29111.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_29112_33719.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_33720_33827.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_33828_38879.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_38880_38987.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_38988_39803.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_39804_39863.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_39864_47063.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_47064_48071.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_48072_48983.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_48984_60911.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_60912_61907.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_61908_63443.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_63444_66707.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_66708_70199.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_70200_70295.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_70296_70343.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_70344_70679.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_70680_79907.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_79908_80423.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_80424_80759.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_80760_81287.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_81288_81335.png DEF_CON_19_-_Whitfield_Diffie_and_Moxie_Marlinspike_xSQtShc3wEI_81336_81401.png
What we're doing here this morning is sort of a spontaneous panel that popped up maybe a month or two ago. That's the best you can do for Spartan ideas. Spartan ideas a month or two ago. Well, you know, I was thinking like I knew you and I knew you and Moxie was doing some interesting stuff and Witt was doing some interesting stuff. And I forget what happened. It was like maybe Moxie was doing something about Dane, DNS Sack. Something came up and I thought that would be perfect to get him talking with Witt. And then I thought that would be perfect to get both of them on the stage because if I think it's cool maybe you guys will think it's cool. So who's looking forward to seeing them just have a conversation? Yeah. So there's not a whole lot of format here. I've got a couple of questions to kick it off. And what I'm really trying to do is kind of get new school and old school talking here. And I'm really curious about how... Sorry if you're still new school Witt. And because what we're seeing is there's a little bit of a different perspective. Moxie maybe is more of an end user perspective. He grew up as a user of some of this technology just like myself. And Witt was lucky enough to be around to be the creator of a lot of this technology and the designer. And Moxie was there for a lot of the important meetings that shaped the way the Internet is today. The way we do certain things online. The way we use certain math and certain cryptography. Witt was there for that. And so they just naturally see the world slightly differently just from where they came from. And then we definitely want to open it up to the audience because I think you'll probably get the most value asking questions. So does that sound like a plan? That's what we're doing. So first off, how many people saw Moxie's talk earlier? So you're pretty familiar with some of his opinions. And so one of my first questions I just want to get out of the way for... This is for Moxie is, why the digital jihad against certificate authorities? You know? Okay. I don't know if it's a jihad, but I did start some of this by looking at the recent Komodo attacks. People are familiar with this. Komodo got compromised. And the attacks could not have been more embarrassing. The information that has emerged from these attacks makes it pretty clear that Komodo does not necessarily warrant our trust. And the question is, what happened to Komodo after all of this? Could not have been more embarrassing. And nothing happened to Komodo. And so I started looking at that question. Well, why is it that nothing happened to Komodo? Will the U.S. fair as well after having its trade downgraded? Will the U.S. fair as well? I mean, it should encourage us that nothing happened to Komodo. Oh, I see. Yeah, right. Exactly. So, looking at this question, I realized that there's really nothing that anybody can do. The truth is that somewhere along the line, we made a decision to trust Komodo, and now we're locked into trusting them forever. And I feel like this is the essence of many of the problems that we've seen with Certificate Authorities over the years, that we're kind of locked into trusting them, whether they continue to warrant our trust or not, without really any incentives to continue behaving appropriately. And so... And then your options as an end user are very limited. And I think I could say your options as a client are limited. As an end user, there's nothing really you can do, and the browser vendors are in the same position. And Komodo knows it. Komodo knows that the browser vendors can't just remove them from their trust database because it would break somewhere between a quarter and a fifth of the internet for their users. So, I feel like we can reduce this to a single missing property that I call trust agility, and the idea behind trust agility is that it should be easy to trust and untrust somebody. It should be easy to make trust decisions at any point, and that those trust decisions should be initiated by the client. And I feel like with those two properties moving forward, we won't get into the same situation that we are in now. And so there's been a lot of talk about replacing the CA system with something else, and I just want to make sure that we don't end up in the same place again. And I think the way to do that is to come up with a replacement that provides trust agility. Any comments on that? Well, no comments that are different from what I had before he said that. Let me start out with a few procedural comments, which was I'm dressed for security theater at the airport. And it seems to me appropriate to change for allegedly intellectual theater here at the conference or something like that. Now, I was told when I was, I've never been to DEF CON before, and I was told that I was required to drink a glass of whiskey before I spoke. Was this... Well, Donner-Plaude's allowed. I haven't done it yet. I assume what that meant is I had visibly to drink my whiskey. You know, he's going for the 40-year-old LeFrog. To visibly drink my whiskey here in the presence of the witnesses. You know, just the way there were many people at court in the European court, so I had the right to witness the royal birth. Be sure that the baby was the right one. So I think my whiskey is being fetched. So the first few words I speak will be unauthentic, receiving the whiskey, but after that, you know, you can have more trust in what I have to say. I mean, basically I'm here like most things in my life by accident. Jeff sent me, incidentally, I really appreciate the name Moxie Marlin Spike. You know, it was hard growing up with the name Whitfield Diffie in a Jewish neighborhood in New York. And somebody wants to have the name Moxie Marlin Spike. That's courageous. But basically I read this article and my response was to think, my gosh, I mean, either, I can't quite figure out, either he's made the greatest observation about the way this needs to work in decades, or he's led me to the observation because I don't say things quite the same way. So let me just say what I learned from Moxie's article and it now seems to me obvious what should be done and it turns into a business problem of how to get it to work. And the simple thing I learned, and it started out with a point in which I disagreed with him. He said it wouldn't make any sense for DHS to be issuing certificates for Chinese websites. And I thought, well, no, that's wrong. It makes very good sense for DHS to issue web certificates for Chinese websites. It just doesn't seem likely that those are going to be particularly interesting to the Chinese, right? A Chinese doing business in China doesn't care what DHS thinks about Chinese websites, but an American business or an American government organization interacting with Chinese companies and organizations and so forth might even be bound, but rationally bound by regulation to only conduct certain communications using certificates supplied by the DHS website. That seems to me an entirely reasonable idea. And in general, what I learned is that basically CAs work for the wrong people. CAs should be working for the people who want to acquire keys, not for the people who are wanting to profit keys. And that's where the trial and work for, and here's the rub, largely means of course as always, paid by. So think about some other things that I think have about the same structure. That is to say, you're going to hire somebody, you're allowed to have that person investigated. You go make certain choices. You choose, you know, I know, Burns detective agency to investigate them, or some other detective agency. You go to Equifax or some other place to investigate the credit. But it's the people doing the people who want the answer, who are responsible for getting the investigators to find out what they want to know. Well, similarly, you know, if you are a business of some kind or other and you want to do business reliable, you don't really care about browsing every website on the web. Who cares? You want to be sure that when you're talking to IBM, you're talking to IBM. When you're talking to Microsoft, you're talking to Microsoft. When you're talking to NSA, you're talking to NSA. And so you want to go to what Moxie is calling a notary. And I think I don't have a better term. I'm not quite comfortable with that one, but I'll use it for the moment. You want to go to somebody in effect that you retain who issues certificates for people you want to talk to. Now, there are two things about this. In my mind, this organization need neither be friends of the people it's issuing certificates for, nor even be known to them. So it could do anything. I mean, the cheapest ones just parrot whatever the whatever certificate those websites issue for themselves. Things are picking up. Just keep going. Thank you. Fortunately, they drive me all around town. That's right. I see. Okay. I don't get whiskey at all. I get rye. I don't get scotch at all. I get rye. Okay. So are any like drinking rye? Who knows what's going to happen? Any last words before you have to be authentic? No. What was I saying? So you might have an investigatory organization that you retained that goes out, you know, flat foot around and does the kind of things accounting companies do and investigates the companies you want to communicate with. And by whatever means, it seems appropriate. It figures out what their keys are and then it issues your certificates for those keys. The other aspect of doing these things this way is, of course, there's going to be a new mode of failure that's going to appear. That is to say, the rules of my organization say I will never talk to your organization unless you present the rules. Unless you present the key that is in the certificate I got from my trusted notary. And so if you send me some other key, the communication just dies there, right? You're presumably not going to understand things that I encrypt in the key I was sent and I'm not willing to encrypt anything in the key you sent. But by and large, I'm going to expect this will work reasonably well. That's not going to happen that often. And of course, it triggers an investigation. And you may, certain sprinkling of these, you will have rekeyed or something like that and it will have to be updated. So that's, we've pretty much come to the end of my pre-Whiskey statement. So I think while I drink my whiskey, I'll turn things back over to my cohorts. So, Moxie, the idea of notary sort of reminds me of the concept of trust anchors in the early days of DNSSEC when they're still trying to get the root signed and the TLE signed, people still wanted stuff to work. So they came up with the trust anchor concept. And the notary seemed fairly similar. Or have you gotten some ideas from that? Sure. I think it's a similar concept and the difference as far as I can tell, and maybe I don't know enough about trust anchors, is that the trust anchors were still sort of predefined by someone that wasn't the user. Whereas with the notary concept, anybody really in the world right now can decide to run a notary. And if anybody trusts you, then they can use you as a notary. It's sort of like a popularity contest. I get half the room to trust me, you get half the room to trust you, the whole room can somehow reach where they want to go. Exactly, exactly. And maybe half of the room, and I think that's appropriate, maybe half of the room is in a situation where they trust you for whatever reason. And the other half of the room is in a situation where they don't trust you for whatever reason. And maybe they trust me instead or some other organization. And I think that that's how the world works. And there can be overlap too, right? Exactly. There can be overlap. And I think the important distinction there between this and the DNS Act Trust anchors is that I think we've gone to a point in time where it doesn't really make a lot of sense for one entity or one organization to be making a decision about how everybody in the world should engage with the authenticity of that website. And I think that's a good point because different people are in different contexts with different threats and different ideas of who they trust in the world. And it's really, it's our data. It's the user's data that's at risk, not the service's data that's at risk in most cases. And so I think it should be up to the clients, it should be up to the users to decide who they're going to trust to certify their data. So would you say looking back that users have made really well informed decisions over the last... Okay, this is a fair question, right? You know, if we're putting this on the user, our user isn't as too complex, right? And I think that really instead of user, we should be saying client. Okay. Because, you know, the way that I would imagine this is that you get your web browser, you know, Mozilla or Chrome or whatever web browser you choose. And embedded within it is a set of same defaults, you know, that the organization like Mozilla has chosen organizations that they think, you know, are sort of generally trustworthy. And maybe they have it localized, you know, maybe they have, you know, they already have localized versions of their browsers, maybe they have those notaries localized for different areas of the world. But then the... if a user, like an advanced user, wishes to modify that, it's very easy for them to do so. And if Mozilla needs or Chrome or whoever needs to make a different decision about how to distribute these things, they can really easily change it, unlike now. Yeah, so it gives them at least the initial level of flexibility that they didn't have. Exactly. And then hopefully that will trickle down then to the advanced users. Yeah. When he's talking about half of the people in the room, I suddenly came to what I think of as the Casanova model. Half of the people in the room trust him because there is a girlfriend. And the other half don't trust him because he stole their girlfriend. I think there is a, you know, I envision there's a certain possibility here for a graduation of trust that would be very useful. Namely, if we've gotten a certificate from our notary that indicates trust in this organization, then maybe we can connect to them, for example, without any firewall. We can get a much better performance and so forth. Whereas if we, you know, we have levels of trust and if we don't acquire keys for them that way, then we treat them as more hostile and we, you know, do a deep packet inspection on everything they send us, et cetera. So you can make a great graduated decision on trust. That's right. It's not either, yeah, all or nothing. Can I want to take a question from the audience? In the front row? Come have a microphone. We have an abundance. Yeah, I think there's, there used to be in one of the aisles, no I don't see it. Have this microphone. Here, we'll just give them this one. Alright, thanks. Just name and... Okay, my name is White Kesterson. I am also old school. As both of these guys know, I chaired the committee that invented X509. So... Alright, the interesting thing is when I draw back and I hear about these trust models, I'm reminded of PGP signing parties. Okay, that's exactly what I'm reminded of. And let me tell you where the problem comes from, from these kind of communities. They may work in certain ways. I hang with way too many lawyers. Okay, and the problem of this kind of distributed trust model is what kind of business liability are you assuming? So when you say, I want to open a CA, or when I, or your version of a CA, which is a notary, then the question is, what's the business model from them? And here's my problem. We actually, you know, put together a program that said, CAs were supposed to operate responsibly, right? They're supposed to do certain things. And when the first ones came out, they had a little bit more discipline. But when the other ones came out, they lowered their prices, they lowered their prices. And now, you know, you have GoDaddy, which does a really horrible job and a couple of other people that do that. But people want certificates and they go to it. And I just don't... And that's the economic model. That's what drives it, because we're laissez-faire. We don't really enforce these kind of things. So I just don't see how, when you put another model together, I do like, incidentally, the voting portion of it. I think perhaps we might be able to do that with actually having servers present multiple certificates from multiple providers. Hopefully you find what someone you trust. But I don't understand why you think that the same economic model won't happen. That there'll be there doing a reasonable job for a reasonable-saw community, then it gets bigger, then it gets more costly. Then I have lawyers telling me about the risk, I'm assuming. So I start charging money, more money, more money to do a decent job. And then someone uncuts me, undercuts me in terms of pricing to do a less decent job, and then we end up with Komodo. And so I basically see nothing there that stops the same iteration of the business process. That's it. Okay, so I'm not really sure I follow that in terms of the vision, the way I envision this. Why don't you leave the mic with him for a second. I mean, as I said, we have, it seems to me, a variety of things that work pretty much the same way. In which you choose a detective service, an accountant, or something like that that has to be trusted, and you pay them. And they bear, that is actually a case where if they have a contractual obligation, and so they will actually suffer for delivering you bad information. No, I agree with that. I don't mind with the flipping of the model, but what I'm arguing is that there, when we talk about the common person, the one who's already trying to figure out what's going on in that little bar in his browser, I personally think the client's got a little too thin here, right? Yeah, let me say for the record, I can't figure it out. So I think we've got a little too thin here in terms of people trying to make decisions and all the information that's up there. But my argument is exactly the same, that people are out buying, they're buying based on certain kinds of things, and they'll end up buying based on cost. Okay, that's what people do. They buy based on cost. And so my argument is that we end up with the same thing, low-cost cutting type things and same risk. I think they buy on cost versus perceived quality or something. I mean, lots of people buy Mercedes as opposed to buying much cheaper cars, right? Lots of expensive goods sell. It's just, the problem with the market is that you can't see the difference in what you're getting, so why spend more for it? I think that's because people who buy Mercedes probably have an innate understanding about cars and quality and so forth. They might be wrong about it, but they think they do. I just don't know if we're going to find this innate understanding in trust models. You don't need anything innate understanding. You put your foot on the gas and the whole ass through a turn and you feel the difference between that and that. You don't know the thermodynamics of what's going on. I'm imagining that some of these investigative agencies, they might be NGOs, it might be the EFF, it could be anybody, right? Yeah, I mean it could be anybody. So I've released some software called Convergence, which is an early stab at inverting this trust relationship and doing things a different way. And the way it works, Convergence, anybody can run a notary. And it actually requires very low resources. It's not an intensive process for somebody to run a notary. And already there's been some number of people in the past two days who have set up their own notaries. And I've received communication from security companies and NGOs who are interested in running notaries of their own. Maybe even one certificate authority was interested in running a notary. So I think that people are interested in running this even if it does not provide any immediate revenue because it looks good. It's just like security companies do a lot of things in this industry without taking any direct cash for it because they want to be seen as trusted entities. Sort of like the lost leader. Yes, yes. One thing may be necessary, you know, I had a remark in your paper about how Verisign could sign a certificate for somebody even if the person didn't want it. And that just strikes me as inevitable, of course. You can sign anything and get your hands on. But the critical, maybe we need a more expressive language to have to go into the browser for saying what you trust about certain sources. I'm going to call them notaries. You say, you know, we trust this notary to endorse that category of things and have explicit, you know, you might explicitly, well, we think they made a mistake in that case. We'll blacklist that one. I don't know precisely. All sounds very XML-ish. Oh, no, oh, no. Yeah. As long as it doesn't sound ASN one-ish. Since we're stuck using primarily low assurance to no assurance systems, do you see any sane approach to prevent subversion of the trusted list or the certificate authority list? I'm thinking of the example where about a year or two ago Microsoft released a security update that actually modified the CA list for Mozilla Firefox. So the question is, is there any mechanism to prevent subversion of these default lists themselves? Anything that you can see, particularly since you're working in an untrusted environment. Sure. Well, I mean, I think, you know, in the case of organizations like Microsoft or any of the browser vendors themselves, that they, you know, at heart are trying to actually provide secure communication for their users. Now, I think, you know, let me ask, does anybody in this room trust Komodo? One, two, three. Okay. Three people. People don't work for them. Yeah. Where do you guys work? Just trust them to do what? Just certify your secure communication. Trust them to do it. You know, I feel, you know, there's maybe a couple hundred people here, maybe one or two people trust Komodo. And I think that the browser vendors and the platforms actually feel the same way. And I think if they could, they would also make a decision to untrust Komodo. But they can't do it. And so, you know, this is the situation we're in. And I think that if we give, you know, these platforms the mechanism to make the appropriate decisions, that they will, in good faith, make the appropriate default decisions. Well, hypothetically, let's say you're a dissident in Iran. The Iranian government has a CA, which I noted was in my trusted CA list by default. I removed it. But how exactly would you expect a user to deal with that if it is subverbed and re-added? Because it's assumed to be trusted by your vendor. And you might have no warning that gets re-added to the list. You know, I think that that's maybe a different class of problems, right? But one thing you can imagine, right, is, you know, right now platforms like the web browser or your operating system are essentially delegating some trust decisions for you, right, that they're, you're almost subscribing to them for some information on who to trust. And you can imagine something similar to an ad block plus model, right, where you don't have to make, you know, very intricate decisions about all the entities in the world that you trust. And you can say, well, there's this other organization, this NGO, that's going to curate these kind of lists for you. So it's like a, you know, a meta notary or something like that. You know, maybe you have something like that. I'm not sure. But what I want to do is at least provide the kind of flexibility so that these decisions can actually be made however they're made. Okay. Now, I don't want to turn the track into nothing but, you know, rant against the CAs. But we're going to take a couple more questions in that thread, and we're going to try to shift maybe the focus a little bit. So let's, uh... Hello, Bill Manning. And I'm going to take both of those questions. Okay. The first one has to do with, you said notary. Notary reputation. Who does that? Number one. And the second, I will call it trust echoes. Trust what? Trust echoes. Echoes. How many people in the room have one device with one browser? Only one. I have a device that only has one browser. No, no, no, no, no, no, no. Right. How many people have multiple devices with multiple ways to get to the net? Everybody's hand should go up. Okay. So if I want to update Mozilla Firefox on my MacBook Pro 15, who's going to update my Android? Who's going to update my iPhone? Who's going to update the box that's been sitting on the desk or sitting on the shelf for the last three months? Right. I'm going to forget these things. So the idea of updating all of the trust on all of the devices simultaneously is problematic. And then there's also the problem of if I trust something and Wit decides that he trusts me for whatever reason. He's had too much whiskey or rye. Um, and I choose to say, well, I think that actually Jeff is, you know, pulling my chain. I withdraw my trust, but Wit doesn't see that in any time, any near real time. So he continues to trust Jeff based on my reputation. So this idea of cash store, the influence ripples of trust is a problem. And I don't know how you deal with that. I mean, this sounds similar to the revocation problem, right? You know, that if things change. The OSCP kind of? Yeah, exactly. That, you know, right now there's, you know, certificate authorities have the same problem. They issue these sign certificates. Maybe at some point they change their mind. And so there's supposed to be these revocation mechanisms that allow them to revoke their decision. Unfortunately, they don't actually work. And so that tends to break down. But I, you know, I think it's an ongoing question. And certainly we can, I think, all imagine revocation mechanisms that would work if they were just implemented correctly. Hi. First of all, I'd like to start with a comment on scoping so I can better place my question. I think that perhaps we speak of trust in a very, you know, one way that's true broad. And in my question, I was explicitly interested in terms of knowing that you got the correct public key for that particular website in context of SSL. I'm not talking about email encryption or other applications. And I wonder, and I would like to see both, we spoke earlier about this and I would like to hear with comment. If perhaps there is a simpler way. For instance, Tor puts a hash of the private key in the DNS name itself and the pseudo domain.onion. Why don't we do something like this natively in the browsers for so we could get away and get rid of these whole CA system? I think it would be a much simpler solution. Perhaps putting other layers over complicated things and complicated things have complicated modes of failure. They are hard to analyze. And simplicity, security and simplicity have a lot in common. But Dendo, aren't you shifting your trust to the DNS infrastructure? Sort of, which we already do when we are not. Why another layer? Yet another layer to create another failure. So that's sort of like the Dane or other proposals like that where you put your public key in DNS queries? Right. In the site name itself, say xlyz123 whatever big hash.com or.key or any TLD we choose for that. And I think that it's reuses what in a way or not we already trust what already works. And it doesn't add other layers of complexity to the whole system. And that's what I would like to hear their comments on this. Thank you. Well, I think when thinking about a lot of this stuff, one thing that we should be or one thing that I like about a simple pivot to something like convergence is that it doesn't require migrating the Internet. Right now the way that convergence works is the servers, people that are running services on the Internet don't have to do anything. They don't have to change anything. And I think it could be difficult to convince everybody that, okay, here's what we're going to do starting January 4th. Everyone's going to switch to domain names that are actually just long, incomprehensible hashes. And I think it would particularly be a hard sell if you go to somebody like Twitter and you're like, right, Twitter from now on instead of twitter.com you're going to be 732594, you know, some incredibly long string.twitter.com. Well, just notice how hard it's been to sell IPv6. Any other proposal of that kind for less than helling reasons? We can make this switch on the same day. Yes, so, Danily, in case I think IPv6 is, you know, its problems ought to be addressed at this moment by just stepping over it. I think we need IPv8, which has a good name and would have a 256-bit address space, and that it's time to, you know, often you give up on something that has opponents and you pick up a new thing that's substantively the same but better. I encourage everyone. It just seems to me like these trust organizations that you're talking about would tend to be, tend towards large organizations instead of small ones, I would think. And it seems like there's a lot of parallels to politics in this case in which if a politician has a lot of, you know, a large amount of power, they tend to have political terms of office and then they get, you know, they have to be re-elected in order, they have a specific delineation of time in which they have to be re-certified as trusted powers, right? I mean, doesn't it seem like we could enact a system like that where it's like, okay, well, in the year 2014, on January 1st, we have to decide whether we will continue with this large organization, Central Trust or go to a new one. I can give you my answer, which is perhaps unpopular, but the way that I wish that, you know, this term worked just like with all politicians is that that term expired every second. Where, you know, at any moment you can decide, well, you know, fuck these people. Well, yeah, but I mean, it's like users aren't going to want to decide every moment whether they trust anyone or decide on an individual basis. They want to set it and forget it. Well, you know, and again, I think maybe instead of saying users, we should say clients, because it doesn't have to actually be the end user. It can be whoever is providing the client, because, you know, that's their job to be making these kind of decisions. Does any of this remind you of the trusted users, trusted identities in Cyberspace initiative where you, no? The ticks, the proposal coming out of the US government to create the trusted online identities, you maybe have to give up more information, but in return you get a larger amount of trust in who you're connecting to, and they have a higher level of trust in you as a consumer. So the government is proposing this thing that sounds scary, and they called it tick? What, these people need a PR department, man. I think after you're very careful about this, I think it's, I've heard people say, you know, you're round for a while and get all these seminars about how we should have done the internet and this, that and the other. And I heard Kleinrock say, if we had to do over again, we'd build in strong authentication from the beginning. And I think no thing, nothing could be more profoundly mistaken, because if that had been done, and just incidentally, I don't think the tools were available to the area he's talking about, but that doesn't matter. The point is, suppose they succeeded, then they would have ended up with what Baron wrote about, what ARPANET was prototyped for, which is a national command and control system. They would not have ended up with the incredible cultural and economic force that the internet has become. So I think you have to worry in a lot of these things about doing anything that can tighten things up in such a way that you don't have the freedom to go out and explore, because everywhere you go, you will be well known and they will adjust what they tell you to fit who you are. So you're not probably a fan of Facebook's policy that everybody has to use their real name? Probably I'm not, but the fact is I'm fairly ignorant, I don't Facebook. I think there's a strong parallel between the trust problem with CAs and the trust problem we have with our bond rating services, but that's a side comment. Going to the model of the client driven trust, I can see a model where I don't sign your key unless you pass my vulnerability scan, for instance, but that creates a free rider problem and I was wondering if you have any comments on that. What is the free rider problem? I don't have to worry about scanning this because this other trust agency has already done it. Well, that sounds pretty much to me, lots of outsourcing decisions could be decided, could be described in the same way, right? If I've hired somebody to do this investigation, it seems if I do it again myself, there's some question, why did I throw away the money to hire those people to do it, or why do I bother to do it again, or can I explain why we did it from different perspectives and can expect different value from the work? You have notary A who has a strong vulnerability assessment, does it for X and X passes that vulnerability assessment, you have notary B who says, well, notary A trusts them, so I don't have to do a vulnerability assessment. They had to pay for it, these guys didn't, that's the free rider problem. I think that's handled in a lot of current things by the fact that your customer, your paying customer I think was X, gets things. Paying customers is the client who's paying either A or B. Yeah, and I think if you pay A you get information from A and if you don't pay them they don't send it to you or something, isn't that the way it usually works? Yeah, but if you pay B, B didn't have the overhead that A did. How did B learn what it told you? Because B subscribes to A as a client does. Oh, that sounds to me, okay, that has to be true of a whole lot of business relationships currently, so A sues B for, you know, the theft of intellectual property or something, I don't know. The answer is I don't know, maybe that's a problem. So quickly, on business incentives of running a notary, it occurs to me that I go home, I set up a notary and people start using it. I would have a significant amount of customer data which I could later resell. So is that a business incentive? Is that a legitimate thing? Is that something that you perceive is happening? Would they be removed from the trust chain at that point? Who are the customers in your model here? The customers would be some marketing firms or something. You're saying you have a large number of customer data? You said you have customer data. What is it you know other than what sites your customers would like to have some kind of form? IP address is linked to domain names of who they're looking for. And so you'd have correlation data of people that are going to a similar website. So it would be the same data that a name operator would collect? But then I would have it, though. So the way that convergence at least works right now is that by default your communication with the notaries is anonymized through another notary. So you turn, let's say you have ten notaries configured. For every request, you decide you're going to talk to nine of them. You turn one of them into a one-hot proxy, tunnel SSL through that one to the other nine. So now two notaries actually have to collude in order to reveal your browsing history. And also you only contact them on the first time you visit a site or win a certificate changes, which would be fairly rare. Excellent. Thank you. Okay. We've come to a fork in the road. I think you underestimate the audience. I count about 16 by 32, which is around 500. We've talked down 500 people. Gosh, we should feel pretty good. Okay. We've come to a fork in the road. Do we want to continue on this topic or shift? We've got about ten minutes left. We could just keep doing questions or we could talk about something else. You stirred this up. Why don't you think of a great new topic? I don't have a whole lot of great topics in my back pocket, but I'm always curious. And maybe you know why this happens. When I'm using my browser and I'm going through and I'm the same problem related to which ciphers do I trust? And the cipher suites or do I trust only TLS or only TLS V1.1 or V3 or SSL V2 or whatever. So I've been experimenting with some of my websites and I'll change on my web server what kind of certificates it hands out and then I'll pay attention to see what my browser crashes. And I've gotten it down out of my mobile devices and everything I have can support TLS 256 with Diffie Helman. But if I turn on AES 256 without Diffie Helman, the browsers prefer that over you. Why don't they like you? I think you're more secure. I think the Diffie Helman key exchange there is probably better for users. What's the alternative? You need some public key component, right? The alternatives are RSA? Yeah. And it seems to default to that. I don't know if that's a legacy of older browsers or not. Well, I'll give you a personalized answer since that's probably more fun than something else. One of the greatest mistakes I have made in my life is that RSA solves the public key problem in the way I formulated it. Diffie Helman solves the public key problem in the way Ralph Merkel formulated it. As a result, for years, I liked RSA better than I liked Diffie Helman. In retrospect, until we long time to understand that's a mistake for two reasons. One is deeper, both are important, one is deeper than the other. The deep one is that RSA has the problem that I hand you a modulus and say to you, hey, this is a good key, send me a secret. Well, I know there's some fancy protocols where I can prove to you that the modulus is good. They're not widely employed. But in the basic protocol, the whole thing that makes the system secure is that there's nothing much you can tell about the modulus from looking at it. And whereas in a Diffie Helman protocol, all the things that are secret are kind of uninteresting. You pick random numbers and you don't want them to be zero or one, and other than that, you don't much worry about them. So in terms of the truss structure, the Diffie Helman architecture, if less elegant about certain points of signature, I'm sorry, I probably should have said it's inadequate until you have El Gamal. Once you have Diffie Helman and El Gamal, then you have, what is now in, for example, Suite B, essentially, you have the two components. The other point is that RSA is a curious dead end. You can do it in quite a variety of rings, but none of them are better than the integers. Whereas with Diffie Helman, you can do it satisfactorily in quite a variety of number systems, and in particular, elliptic curve groups work a lot better than modular rings. And so, you know, why is RSA more popular? Well, in part, only one part, because I backed it rather than Diffie Helman. Oh, that's just nice. Is there a component between RSA and the Diffie Helman of sort of perfect forward secrecy? Well, I mean, Diffie Helman is the better thing for giving you forward secrecy, because it's very cheap in Diffie Helman to manufacture ephemeral keys. Manufacturing RSA keys, you can manufacture ephemeral ones, and some systems do, but it's expensive. So, on that topic, I'll shift it for a second. We'll take one or two more questions before we wrap up. On the concept of perfect forward secrecy, it seems like it would be a very good characteristic to have some of our communications, especially moving forward in sort of this perceived view of the world, where there's many organizations that might be monitoring you from your ISP who wants to better market to you to nefarious government organizations. So, if you could always be having the properties of PFS, that would be, that seems good. Then it really doesn't matter how much of my history they record. Like with PGP, they just get your key ten years later, and they get everything going back in time. Why don't we see more PFS in protocols? It was never really a consideration of the people who designed it. Just privacy doesn't enter their mind, and now we're trying to bolt it on into a system that was never really designed for. Or are there deeper reasons that I just haven't thought about? Well, I don't know deeper reasons. I mean, one, the phrase incidentally is misleading. I know it became a forward secrecy is an okay phrase. Shannon's term, perfect secrecy, referred to an information theoretic phenomenon that's not present here. This is not right. So, I just call it forward secrecy. NSA has a couple of terms, one of which is backpack protection, I can't think of the other one, that are sort of more operationally focused on what might happen. And if anybody doesn't know this stuff, it means, you know, if they get your key today, they can't use that to figure out what your key was yesterday. Because you've done something in between that really changes the two. And yes, I think it's a great idea. And it may be that there sort of was enough trouble just getting things to work without making them perfect. Any comments, Motsy? I mean, I think forward security is going to be something that's increasingly important, for the reasons you mentioned that today it's not unrealistic to think that there's some number of organizations that are just recording all of your ciphertext all the time. And maybe one day someone compromises your key and now all of that previous communication would be compromised as well. I used to work for a storage vendor. We really like that trend. And I mean, it is a little bit more expensive. And I think that that's probably why your web browser does not prefer the forward secure mode. Because, you know, there's a few extra operations in there. But, you know, also I feel like we've gotten to a point where that added cost is not significant. So how many people here, for example, defcon.org turned on only handing out Diffie helmet type keys and it's going to break some minor percentage. How many people think that's a valid trade off? Because see, then I as the operator, I'm making a decision to basically scare away a certain percentage. It can't do code sign. It can't get Diffie helmet's break. I love it. But it's a negotiation for a product. Yeah. Yeah, well, I presume, I don't actually know the product cause well. You don't, I mean, you don't support digital signature algorithm or something. Basically, my, I would be in a, I have to have a situation where I double a negotiation and purchase a section of the trade. Right. To read the document, read the code, something that's listening to it. So, it works, it works in a bunch of different cases, particularly the apparel part of it. It works in sign. Okay. Well, Diffie helmet as such doesn't sign, but El Gamal signatures are based on the same arithmetic and do sign. There's a second. Am I not? I'm sorry. Everything sounds so loud to me up here. It's talking about me. It's talking about you using the mic. Okay. Somebody came and put the mic closer to me. I didn't see why. No, just one point that there are as a secondary problem in signatures that sometimes you want it to sign fast and sometimes you want it to verify fast. And in particular, if you're signing code in the sense of a signed distribution of windows, you could take all week to sign it if you wanted to. What you wanted for it to verify in a fraction of a second when you want to load it and run it. And that's a more subtle problem. Yeah. I just wanted to make a comment that I think the most important point or the most important problem that we have with SSL or HTTPS now is websites are not using it or not using it enough. And as I work for Mozilla, and we are trying to make things faster, the speed is becoming one of the primary factors in this. So the idea of contacting a third party site, we're actually trying to do that less. So in the notary system, it would probably be a good idea to try and add in some mechanism so that the website you're contacting can proxy that data on the behalf of the notary so that you don't have to contact someone else. I would say that, so this is a good point, right? Speed is in speed important. I would say that actually with convergence, convergence is probably slightly faster than the existing CAVL edition because you only have to talk to the notary the first time you visit a website or for certificate changes. And then if the certificate hasn't changed, you have a local cache and it's a simple compare. You don't even have to do the cryptographic operations to check the signature. So it should be slightly faster in the common case, I would say. So the first time slower? Almost imperceptibly slower. You mentioned a point of information. You mentioned that I got the impression you wanted the Diffie Hellman chosen as a Cypher before RSA surface. Then you have two options. You can send him a patch or you can change browser to opera. And fill disclosure, I wrote that code. So can I ask you guys a question? Okay. All right, so it's my position that Dain, which is leveraging DNSSEC to replace the authenticity piece of SSL, is a bad idea because it doesn't provide trust agility and it will leave us in the exact same position. Now you guys work for ICANN. I agree with you. I think it's a bad idea. My fear is... I think DNSSEC is a good idea, incidentally. I just think pushing it to do other things is probably a mistake. My fear with DNSSEC is that people will say, now we have this new capability. We have sort of like a trusted directory and we ask it questions and it gives us stuff back and we can trust it. So wow, that's great. Maybe we should put some other stuff in there that I can trust, like a recipe or a picture of my cat. And businesses will come along and say, hey, that solves a whole bunch of stuff. We don't have to build a whole new protocol or anything. We'll just put it in DNS. Instead of maybe the traffic going over and being queried to HTTP, it will be queried over DNS. So maybe the traffic load equals out. So we're just shifting some packets from this service to that service. I fear that one day we're going to wake up and have these 200 meg zone files. Like what said, it wasn't really designed for that. But I don't really know how you prevent people from stuffing things in there. Well, I think as I can, you could say, this is a bad idea. IETF don't certify this protocol. Well, like for example, I was looking at the number of records you could put in DNS. There's, I don't know, 20 or 30 different things. It's okay to put your SSL certificates in there. It's okay to put your PGP certificates in there. Like how many, I don't know, how many Ruby resolver libraries actually know how to query a PGP key? I think they know how to do get host by name and that's it. They don't get PGP by name. And so even though we already have this functionality, nobody's really doing it yet. And so I don't know if I'm bringing up a point that's not going to be an issue. But that's one of my concerns. So I've been given this signal. Okay. Yeah, I was looking at dynamic phenomenon. There are both people getting up and people sitting down. So my question is, since I'm going to ask the question, is this, when does the Q&A start and where? So the Q&A will be in room one or A. What happened to the Q&A already? There's signs and what you can do is you can just follow agent X and myself and Moxie and we'll go into the Q&A room. But feeling if a lot of you follow us there, it'll probably get full. And that's just the way the rooms work. Okay, guys, I want to give you a round of applause for our two panelists.
agility, and the idea behind trust agility is with the name Whitfield Diffie in a Jewish investigators to find out what they want to know. question from the audience? In the front row? talk about something else. You stirred this up.