 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 Spontaneity. Spontaneity 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 SAC. 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? 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. The designer. And he 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. Okay. 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, this is for Moxie, is why the digital G-Hod against certificate authorities? You know? Okay. I don't know if it's a G-Hod, but I did start some of this by looking at the recent Komodo attacks. People are familiar with this. Komodo got compromised. And, you know, 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, you know, the question is, you know, what happened to Komodo after all of this? You know, could not have been worse, 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. fare as well after having its trade downgraded? Will the U.S. fare as well? I mean, it should encourage us that nothing happened to Komodo. Oh, I see. Yeah, right. Yes. Exactly. So, you know, looking at this question, I realize that, you know, there's really nothing that anybody can do. You know, 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. Sure. And I think I could say, you know, your options as a client are limited. You know, like, as an end user, there's nothing really you can do, and the browser vendors are in the same position, you know, and Komodo knows it. You know, Komodo knows that the browser vendors can't just remove them from their trust database because it would break somewhere between, you know, a quarter and a fifth of the internet for their users. So I feel like, you know, 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 by... And I think the way to do that is to, you know, 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. So I suppose I'm dressed for security theater at the airport. And it seems to be 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 fine? Well, don't applaud so loud. 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. I'm visibly to drink my whiskey here in the presence of the witnesses. You know, just the way there were many people at court in the European courts who 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. Preceding 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. 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 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 rationally, bound by regulation to only conduct certain communications using certificates supplied by the DHS website. That seems to be 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 proffer keys. And that's where the truck, 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, 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, right? So it could do anything. You know, 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. I used to drinking rye. Who knows what's going to happen? Any last words before you have to be authentic? 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 deems appropriate, it figures out what their keys are and then it issues the 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 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 make certain sprinkling of these. You will have rekeyed or something like that and it'll 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 the 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 TLDs 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 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 tech 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 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 users have made really well informed decisions over the last... Okay, this is a fair question, right? For putting this on the user, aren't users going to, isn't this too complex, right? And I think that really instead of user we should be saying client. Because the way that I would imagine this is that you get your web browser, Mozilla or Chrome or whatever web browser you choose and embedded within it is a set of same defaults. That the organization like Mozilla has chosen organizations that they think are generally trustworthy. And maybe they have it localized. They already have localized versions of their browsers. Maybe they have those notaries localized for different areas of the world. But then 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. It's the initial level of flexibility that they didn't have. Exactly. And then hopefully that will trickle down then to the advanced users. 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 of 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 connect to them, for example, without any firewall. We can get a much better performance and so forth. Whereas if 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 do deep packet inspection on everything they send us, et cetera. So you can make a great, graduated decision on trust. Yeah, 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 get some. 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 X-509, so... All right, the interesting thing is when I draw back and I hear about these trust models, I'm reminded of PGP signing parties. 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. 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'll find one someone you trust. But I don't understand why you think that the same economic model won't happen that they'll be there doing a reasonable job for a reasonable saw community, that it gets bigger, that it gets more costly than 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 price, 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? Let me say it 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's 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. 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 put your foot on the gas and haul us through a turn and you feel the difference between that. You don't know the thermodynamics of what's going on. And one of the ways, 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. I've released some software called Convergence, which is an early stab at inverting this trust relationship and doing things a different way. 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 trust identities. Sort of like the lost leader. Yes, yes. One thing may be necessary, 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, certain, 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 or something. 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. Yeah. 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. And 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. Or do you guys work? Trust them to do what? Just certify your secure communication. Trust them to do that. 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 the CA, which I know it 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 subvert 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? You know, one thing you can imagine, right, is, you know, right now, platforms like the web browser or your operating system are essentially, you know, 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, like 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 and not thread and we're going to try to shift maybe the focus a little bit. 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. How many people in the room have one device with one browser? Only one. No, no, no, no, no, no, no. Right, how many people have multiple devices 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? 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 Witt decides that he trusts me for whatever reason. He's had too much whiskey or rye. And I choose to say, well, I think that actually Jeff is, you know, pulling my chain. I withdraw my trust. But Witt doesn't see that in any time, any near real time. So I trust Jeff based on my reputation. So this idea of cashed or influenced 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? That if things change. The OSCP kind of? Yeah, exactly. Right now, certificate authorities have the same problem. They're revocation mechanisms that allow them to revoke their decision. Unfortunately, they don't actually work. And so that tends to break down. But 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 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 too broad. And in my question, I would speak explicitly in trust 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 its comment, if perhaps there is a simpler way. For instance, Tor puts a hash of the private key in the DNS name itself and a pseudo domain.onion. Why don't we do something like this natively in the browsers so we could get away and get rid of the 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 that are hard to analyze and simplicity security and simplicity have a lot in common. Aren't you shifting your trust to the DNS layer? Sort of, which we already do when we are another. Why another layer? Yet another layer to create another failure. So that sort of like Dane or other proposals like that where you put your public key in DNS query? Right, in the site name itself say X, Y, Z, 1, 2, 3, whatever big hash dot we choose for that. And I think that it reuses in a way or another 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 talking about, 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 the 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 strings. So if you're going to send somebody like Twitter from now on instead of twitter.com you're going to be 7-3-2-5-9-4 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 compelling reasons we can make this switch on the same day. We can make this switch on the same day. I think IPv6 is you know, it's 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. It's time to, you know, often you give up on something it 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 Trusser, or whether we're going to do it. 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. You know, where, you know, at any moment you can decide, well, you know, fuck these people. Well, yeah, but I mean, if you don't 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. I just take turns. Does any of this remind you of the trusted users, trusted identities in a cyberspace ? No. The ticks, the proposal coming out of the U.S. 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. Wait, so the government is proposing this thing that sounds scary, and they called it tick? What about it? These people need a PR department, man. I think you have to be very careful about this. I think it's, I've heard people say, you know, around for a while you 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 era 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 way about 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 know. 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 wonder 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, you know, why did I throw away the money to hire somebody 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 true. I think that's handled in a lot of current things by the fact that the, your customer, your paying customer I think was X, you know, gets things. Paying customer is the client who's paying either A or B. Yeah, and I think if you pay A, you get 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, how did B learn what it told you? Because B is, 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. Hello. 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? Or... Who are the customers in your your model here? The customers would be some marketing firms or something like that. You're saying you have a large number of customer, you have some customer data. You said your customer data, what is it you know have a site your customers would like to have? IP addresses 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 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 underestimated 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 10 minutes left. We could just keep doing questions or we could talk about something else. Ah, 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 have the same problem related to which ciphers do I trust. And the cipher suites are 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 if my browser crashes and I've gotten it down now to my mobile devices and everything I have can support the TLS 256 with Diffie Helmet. But if I turn on AES 256 without Diffie Helmet, the browsers prefer that over you Whit. Why don't they like you? I think you're more secure. I think the Diffie Helmet key exchange there is probably better for users. What's the alternative? You need some public key component, right? The alternative is RSA. And it seems to default to that. I don't know if that's a legacy of older browsers but 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 Helmet 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 Helmet. In retrospect, it took me a 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. Whereas in a Diffie Helmet 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 trust structure, the Diffie Helmet 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 Helmet 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. It's written quite a variety of rings, but none of them are better than the integers. Whereas with Diffie Helmet you can do it satisfactorily in quite a variety of number systems and particular elliptic curve groups work a lot better than modular modular rings. And so why is RSA more popular? Well, in part, because I backed it rather than Diffie Helmet. Is there a component between RSA and the Diffie Helmet of sort of perfect forward secrecy? Well, Diffie Helmet is the better thing for giving you forward secrecy because it's very cheap in Diffie Helmet to manufacture ephemeral keys. Manufacturing RSA keys, you can manufacture ephemeral ones, and some systems do, but it's expensive. So... 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 in 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, so if you could always be having the properties of PFS 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 just haven't thought about it. I don't know deeper reasons. The phrase incidentally is misleading I know it became 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 based on what might happen and if anybody doesn't know this stuff it means 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 was enough trouble just getting things to work without making them perfect. Any comments, Matzi? 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. We used to work for a storage vendor we really like that trend. I mean it is a little bit more expensive and I think that's probably why your web browser does not prefer the forward secure mode because there's a few extra operations in there but 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 am making a decision to basically scare away a certain percentage. Yeah. I don't actually know this protocol as well. You don't support digital signature algorithm? Okay. Well Diffie helmet as such doesn't sign but L-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 he's talking about me. He's talking about you using the mic. Somebody came and put the mic closer to me I didn't see why. No just one point that there is 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 want is 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. 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 and it 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 this is a good point, right? Speed isn't 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 so it should be slightly faster in the common case I would say so the first time slower almost imperceptibly slower but yeah you mentioned a point of information you mentioned that I got the impression you wanted Diffie Hellman chosen as a cypher before RSA cypher 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 it's my position that Dane, 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 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 a trusted directory and we ask it questions and it gives the 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 DNSSEC instead of maybe the traffic going over and being queried to HTTP traffic load equals out and so we're just shifting some packets from this service to that service and I fear that one day we're going to wake up we're going to have these like 200 meg zone files and 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 ICANN you could say this is a bad idea IUTF 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 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 it's not going to be an issue but that's one of my concerns I've been given this signal okay I was looking at a dynamic phenomenon they're 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 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