IETF 83 Technical Plenary Paris, France Monday, 26 March 2012 SESSION AGENDA 1. Welcome - Bernard Aboba 2. IRTF Chair's Report - Lars Eggert 3. IAB Chair's Report - Bernard Aboba 4. RSOC Report - Fred Baker & Heather Flanagan 5. World IPv6 Launch - Leslie Daigle 6. Technical Session: "Implementation Challenges with Browser Security" 7. IAB Open Microphone Session MINUTES 1. Welcome - Bernard Aboba "Agenda," http://www.ietf.org/proceedings/83/slides/slides-83-iab-0- technical-plenary.pdf Bernard Aboba welcomed the audience to the technical plenary and presented the agenda for the session. 2. IRTF Chair's Report - Lars Eggert "IRTF Report," http://www.ietf.org/proceedings/83/slides/slides-83- iab-6-technical-plenary.pdf Lars Eggert reported that 6 IRTF Research Groups are meeting at IETF 83: - NCRG: Network Complexity - MOBOPTS: IP Mobility Optimization - DTNRG: Delay-Tolerant Networking - ICCRG: Internet Congestion Control - SAMRG: Scalable Adaptive Multicast - CFRG: Crypto Forum The Virtual Networks Research Group (VNRG) closed since IETF 82. Three IRTF-stream RFCs have been published since IETF 82. Lars announced that the Applied Networking Research Prize (ANRP) [http://irtf.org/anrp] is moving to a yearly nomination and award cycle, so there was no ANRP awarded at IETF 83. Lars noted that the IRTF has an Intellectual Property Rights statement [http://irtf.org/ipr] and that the IRTF follows IETF rules. 3. IAB Chair's Report - Bernard Aboba "IAB Report," http://www.ietf.org/proceedings/83/slides/slides-83- iab-4.pdf Bernard outlined the IAB responsibilities as defined in RFC 2850, namely: - IESG Appointment - Architectural Oversight - Standard Process Oversight - RFC Series and IANA Oversight - ISOC Liaison - External Liaisons Bernard introduced Jari Arkko and Marc Blanchet as new members of the IAB, and thanked outgoing members Olaf Kolkman and Andrei Robachevsky for their service. Bernard also announced that Mary Barnes has succeeded Dow Street as the IAB Executive Director. Bernard outlined the current IAB Programs and Initiatives, and directed people to the IAB website [http://www.iab.org/] for more information on those activities. Bernard noted that one new IAB-stream RFC has been published since IETF 82, and that two more IAB-stream documents are currently in the RFC Editor Queue. 4. RSOC Report - Fred Baker & Heather Flanagan "RSE Report," http://www.ietf.org/proceedings/83/slides/slides-83- iab-3.pdf Fred Baker reported that Heather Flanagan was hired as the RFC Series Editor and began work in January. Heather reported that current RSE projects include updating outdated information on the RFC Editor website [https://www.rfc-editor.org/] and updating the RFC Style Guide. Heather is planning to add a wiki to the current RFC Editor website. Heather noted that she is chairing a BOF at IETF 83 on RFC formatting to gather input as to whether ASCII should remain the standard for RFCs, and invited interested parties to stop by. 5. World IPv6 Launch - Leslie Daigle "World IPv6 Launch," http://www.ietf.org/proceedings/83/slides/ slides-83-iab-5-technical-plenary.pdf Leslie Daigle reported that World IPv6 Launch 2012 is scheduled for 6 June 2012. World IPv6 Launch intends for IPv6 to become part of regular business, where IPv6 is on by default without requiring special configurations. Leslie briefly recapped World IPv6 Day 2011, during which more than 1000 websites turned on IPv6. The motivation for both events is to: - Break the chicken-and-egg problem of IPv6 deployment: let networks see that content is being delivered, and let content providers see that networks are rolling out IPv6 - Improve IPv6 connectivity by gaining a better understanding of the outstanding issues - Provide a target date for planned IPv6 rollouts - Spur organizations to create a plan for rolling out IPv6. 6. Technical Session: "Implementation Challenges with Browser Security" "Agenda: Implementation Challenges for Browser Security," http://www.ietf.org/proceedings/83/slides/slides-83-iab-7-technical- plenary.pptx Hannes Tschofenig chaired a panel session on "Implementation Challenges with Browser Security." Hannes noted that there has been an increasing number of data breaches and security incidents resulting from things like misconfiguration, questionable operational practices and implementation bugs. Panelists were invite to share their experiences. - Eric Rescorla (RTFM) See "How do we get to TLS Everywhere?" http://www.ietf.org/ proceedings/83/slides/slides-83-iab-9-technical-plenary.pdf - Thomas Lowenthal (Mozilla) See "Cryptography Infrastructure," http://www.ietf.org/proceedings/ 83/slides/slides-83-iab-11-technical-plenary.pdf - Chris Weber (Casaba Security) See "When Good Standards Go Bad," http://www.ietf.org/proceedings/ 83/slides/slides-83-iab-8-technical-plenary.pptx - Ian Fette (Google) See "Lessons Learned from WebSockets," http://www.ietf.org/ proceedings/83/slides/slides-83-iab-10-technical-plenary.pdf - Jeff Hodges (PayPal) See "It's Not the End of the World," http://www.ietf.org/ proceedings/83/slides/slides-83-iab-12-technical-plenary.pdf At the end of the presentations, Hannes opened the microphones for questions from the audience. An edited transcript of the Q-and-A session follows: MARSHALL EUBANKS: I would point out there is an evil.com, and while they might like being promoted in the IETF, I don't think that was the intention. DAN YORK: The presentations are all pretty much focused on the desktop. How does this change when you look at it from the mobile browser perspective, and what areas of work need to be going on there? IAN FETTE: I think there's a few things that change from a protocol level and usability level. One, from a protocol level, you have to remember that mobile typically has much higher latency. If you really want to do things like SSL, you do revocation checking before you do the connection. But it's hopeless if you try to download 20 megabytes; if you wait for a response, you're adding at least about a second of latency on there. So, there's protocol challenges. Then there's usability challenges of the user interfaces. There's the obvious things, like the smaller screen. If you think that users look for something like a lock, or they want to click on the lock and get more information, more power to you. But it's even harder to believe that it's worth giving space to something like security indicators on a mobile device where space is at such a premium. So I think there's two considerations, one protocol level and one user interface level. CHRIS WEBER: Yes, I would add to that and say that mobile just makes you notice all the ways that you've been lazy on the desktop. The network sucks, the screen is small, and it's hard to click on things and read things. You could download a revocation list, you could wait for latency; you can't do that anymore. You see all the things that you haven't been quite doing right, and now you really have to get it right. TED HARDIE: In particular, about mobile applications which use web technology but are not browsers: I notice in a lot of cases browsers have gone to very fast refresh cycles, in order to deal with the vulnerabilities. But the downloadable applications don't seem to have the same refresh cycles, and not even the same rates of adoption when the refresh cycles are high from their local app stores. I'm wondering whether that's becoming one of the lowest common denominators, or whether you see this as a completely separate problem? CHRIS WEBER: With all mobile operating systems, we're trying to fix that problem by having mobile applications basically be web pages. Then they can have really fast update cycles with really little overhead. IAN FETTE: There's a lot of applications that just wrap something like a web view, and they don't seem to get updated frequently. TED HARDIE: Right. They're basically static. IAN FETTE: I think regardless of whether you're talking an application that's a web view, or just a web page running on the mobile browser, it is dependent on the platforms they run on--so the equivalent of Android or IOS. You're at the mercy of either carriers picking a new version, or you're at the mercy of the company that's providing your operating system to push [updates] to all the users. This has significant costs, especially on mobile. There's a cost to push out the large updates, so it doesn't happen as frequently as we like. I think that's one of the realities that we're dealing with right now. I think there's plenty of people unhappy with it. But I don't think it's unique to applications wrapping a web view. I think you have the same problem whether you're an application that wraps a web view, or whether you're trying to run on a browser shipped with a platform. HANNES TSCHOFENIG: And so, you don't separate that stuff out on a mobile phone. You have to at least two possibilities to run the applications. One is a native application which has a very different security model; it has the sort of permission-based security model, versus web-based like a web browser that just runs regular web pages, and those are very different. Do you see the direction going away from the regular web usage to something mobile, the native application space? Or do you see a totally different model? Because from a security point of view, these sort of details matter. CHRIS WEBER: On our mobile operating system, all the applications are just a bundle of HTML javascript, so we definitely think the future is in just having web apps. You can cache them, and we need some sweet APIs to do all the stuff these devices can do, but I think the appropriate security model in the future is web apps with smart APIs that are enabled through good preference management. IAN FETTE: I'm going to take a practical view and say I think we see a bit of both, especially on platforms like Android and IOS. You see essentially HTML in a web view. They both have pros and cons. Whether it's a native app, they're both technically native apps; whether it's written in java or objective C or a thin native wrapper around it. You still have the constraints of the platform. On the web app that may or may not be wrapped, you're dealing with whatever browser happened to ship when the user got the phone. With the native app, you're talking about what version of the java runtime am I dealing with? Does this version of java support SNMP? Does it support new things that we're trying to do to with SSL? Things like, if we want to make any changes to the handshake to indicate what sort of protocol we want to speak that's not going to be supported on the mobile device. You're stuck with constraints. ERIC RESCORLA: I'm not sure if this is a mobile versus desktop issue in particular, but one of the things that's become apparent, if you look at Android versus IOS, that's two very different security models they adopted. Namely, an Android app comes with a whole package. And you're supposed to say yes or no. And with an IOS app, if Steve liked it, I guess it's okay. [But as a user that's] like you're on your own, and you download stuff and nobody is curating it and telling you what you're supposed to do and not supposed to do. I don't know if it's inherently about mobile, but it's noticeable that the manufacturer of the device is putting in security for you--but how well, is not clear. CULLEN JENNINGS: I have a two-part question. The first part is, there's some discussion on the number of people you're trusting in these root trust lists that are inherently in the major browsers. I certainly understand that some of the traditional [Certificate Authorities] CAs are issuing certificates to enterprises that allow them to masquerade effectively as any other web sites, so they can do interception type things for whatever reason. So the first part of the question is, can you say a little bit about how many of those types of certificates do you think are out there, and how prevalent they are. And then the second part of the question is, what do you think the browser vendors should do about this? IAN FETTE: We have seen a non-zero number of these that have been used in practice; essentially man-in-the-middle connections. As for what we should do about this, our first step has been to [come up with] a clear written policy that says this is not okay. And we have made it clear to people that we know who are doing this, that it needs to stop, and we've given them timelines for remediation. In terms of what happens if we see it again in the future, I'm hopeful that we'll be able to say, "Here's our clear written policy, you have violated it, we are going to now take a harsher stance." CHRIS WEBER: I think one of the problems is that we only have one size stick. And that stick is really big. We need to work on developing smaller sticks with which to beat Certificate Authorities when they misbehave. ERIC RESCORLA: I think it's clearly not okay. I don't think there's much debate about that. I realize that [the CAs] think it's okay, but I'm not aware of any browser manufacturer that thinks it's okay. I don't think it's okay, for whatever that's worth. I mean, it's certainly true that we need to develop some way of dealing better with this stuff. There already is some active work on this. The core problem in dealing with this obviously is, you have a huge stick to make the CA do what you want, and it's expensive. And the question is, can we offer them something better than that, that we want them to do? BILL MILLS: If the CA thought it was okay, they would say, we've sold this number of them, and if people knew they were offering a certificate to the man in the middle, that would clearly be bad for them. IAN FETTE: Apparently some actually did market it. BILL MILLS: Lovely. CHRIS WEBER: And some still did, until very recently. BILL MILLS: We're looking forward to rapid iteration and fixing things and getting better models in the new stuff, but there is still a tremendous problem of users out there that have notably old and huge attack surface browsers. And when you deal with them from the web server side, you're still protecting the users from their own software, daily. Is there anything that we can do about that, to try to reduce the cruft out there? What can we do systematically about that? CHRIS WEBER: When you see IE6, tell them to install something better. That's really anything. JEFF HODGES: Yes, just to comment on that. Our vice-president and chief information security officer has a blog post up, basically encouraging the world at large, "Let's upgrade your browsers, folks, move off the old stuff and get to the new stuff." SEAN TURNER: I'm all for Eric's statement. So the question is, how do we get browsers and servers to actually implement the later versions? Is there something more that we should be doing? IAN FETTE: Browsers and clients. The hardest part is not implementing the newest version, but yes, we have been slow. SEAN TURNER: TLS.1. IAN FETTE: The hardest part is actually turning off the old ones. So two weeks ago, we turned off our RC4-128 with MD5. [Applause.] IAN FETTE: But we actually turned it back on. Sorry. There were a number of sites that broke when we turned off this known bad suite. We were getting tons of bug reports. There are a lot of sites out there that for some reason are only configured with this suite. SEAN TURNER: It's really fast. IAN FETTE: You know, it turns out we don't really want to jump off the bridge and shoot ourselves in the head at the same time first. So we had to turn it back on. JEFF HODGES: And access of web application providers or web application services depends on third parties, such as their TLS, and are waiting for those guys to implement. ROSS CALLON: I've occasionally heard rumors that I might have a reputation for being nice, so I'm going to end that once and for all now. I am Ross Callon; I'm an IAB member but I'm speaking today solely as an individual. I'm concerned about the complexity of our security solutions, and whether they address the issues. To give you a couple of examples, while I'm talking as an individual, I happen to be an IAB member so from time to time I go to the I1B web site (an externally hosted website used for IAB business). Every time I go to the I1B web site, I get a warning, the security certificate presented by this web site was not issued by a trusted certificate authority. The security certificate is expired or not yet valid. It seems to me if this stuff is too complicated for us to use, it's probably difficult for somebody who is not in our industry. As another example, I happen to know somebody who is head of some sort of a health care agency, and there have been times when she's gone two or three weeks without being able to log onto her work systems from home, because of failures of the security system. She's gone in and talked to the IT person in their company multiple times, and they take her fairly seriously since she runs the agency, and they still can't get it to work. So I think this model--that when authentication fails, you never send any information because you're assuming the person trying to log in is an attacker--causes real agencies to not be able to use the Internet, with the result that they lobby to turn [the security] off. I think that's probably not good to improve the security of their use of the internet. Now, of course, they can't turn it off if they're a health care agency, because there's federal laws about it and stuff, but nonetheless, it makes security less popular. Another thing that concerns me is when I use some secure web connection between my laptop and wherever I'm connected to, I trust the security of the protocol, but the problem is I'm pretty sure my laptop is infected so every key stroke I enter is going off to Eastern Europe. And furthermore, I'm not sure I'm talking to the web site I want, and could be talking to a man in the middle. I think I have to believe that the stuff is not secure, even if I'm using a secure web service. Finally, of course, I've heard of denial of service attacks, in the tens of gigabits. We're not good at that with the highest speed devices out there. So I believe security is very, very important, and I don't know what the solutions are to these problems, but I fear that we might not be exactly hitting the nail on the head. IAN FETTE: I think you raised about ten problems. I'm going to take solace in the fact that I think we're coming close to answering one of those, not all ten. For better or worse, process computing seems to have sat on the shelf for quite a while, and it now seems to be coming back. We do have devices that are doing verified boot, and maybe you will at some point in the future have some level of security satisfaction. ROSS CALLON: So I'll be able to get a laptop I can trust. IAN FETTE: Yes. But as far as all the usability problems, suggestions are welcome. One out of nine. That's not bad. ROSS CALLON: One suggestions that I do have is that when authentication fails, the hackers probably knows why it fails; it's the honest users who don't. So it might be a good indication to send some reason why it fails so the user can take that to the IT person. JEFF HODGES: There's all those issues. That particular notion was brought up and discussed a little bit today in the WEBSEC working group, actually. HANNES: Thank you, Ross. Actually, we had found client-side certificates un-deployable for the reasons you mentioned. That's why we switched to passwords. UNKNOWN IETFER #1: I wonder if you can help explain one thing that bothers me with the web security model, and where you think it's going. We have this security model that says it's okay to get code everywhere. I can't get data everywhere. So I have the same origin policy deployed in all browsers. The industry was clever and found a way around that, called JSONP. We address data and ask code instead so everything that comes from everywhere is addressed as code. There are a lot of things out there that depend on that functionality, not to address JSON as javascript. It seems like intuitively, that it is opening up more attack vectors than actually doing anything good. Also, would there be any change in the future that would shut that functionality down? Or is there any way else that it could be straightened out so that data is actually treated as data without that limitation? ERIC RESCORLA: JSONP is a terrible idea. In modern browser servers you may not need to do this anymore. UNKNOWN IETFER #1: Because I haven't seen any browsers so far that will stop me from doing JSONP. ERIC RESCORLA: What happens is that we developed technology that allows you to do the same thing that you can do with JSONP. I'm not aware of any work right now in breaking JSONP. DAN YORK: I've got a question from the Jabber chat room. John Klensin asks, "Would someone like to comment on the consequences to TLS and CA management (and user understanding of what is happening) of hundreds of new TLDs, some with 'equivalent' aliases, and some in scripts that get rendered as '?????'" Anyone care to play? ERIC RESCORLA: I don't think having a lot of TLDs changes anything. I think having a lot of question marks creates a problem for Ian. IAN FETTE: If you look at the lowest common denominator practice, you look up the WHOIS information for this domain, you send an e-mail to the technical or administrative contact for the domain and see if they can reply to that, or you try route at that domain. Given that we already have that lowest common denominator system in there, sadly, I don't think that really changes that much. It's sort of a nightmare with [choosing what to] display and whether the user can understand that paypal.onlinebusiness.com is not really the PayPal that you're looking for. So there's some challenges in terms of users understanding URLs, but I don't think that the certificate issuance part is the biggest part of that challenge. JOHN LEVINE: I'll try and make this coherent. The comment before about mobile browsers being worse in various ways, they're basically a leap 15 years into the past. The networks are slow and the mistake people are making are very familiar. In some of your fascinating presentations, I saw a whole bunch of ways that reasonable features interact to produce bad results. Right? Like, who would have thought that having an entity for ":" would actually be a security problem. And so, we have approaches to limiting the amount of interactions that are going on. Sandboxing, trusted computing hardware--which is great if you trust the entity with access to the keys in that hardware, which some of us don't. You've got the Android model, which is horrible. I have two sample users, my 16-year-old daughter and my 75-year-old mother-in-law. They read the questions as "Bargle bargle? Okay?" to which the answer is always "Yes." [As for Apple's IOS], Steve has excellent taste, but maybe his preferences are not my preferences. So having set this up, my question is, do you see any approach with any hope for a security model that actually manages to limit the damage while still providing enough access to what's inside the box, to produce useful applications? IAN FETTE: I mean, we've obviously explored the two that you describe, and there's a third in there, which is, let the user pick and choose which of the permissions they want to grant, which is even more complicated for the 16-year-old or 75-year-old. But from the application developer side, you've now got two totally impossible permutations that you may have to deal with. So, it's untestable. HANNES TSCHOFENIG: It's obviously the crucial question. Do you want to support all the innovation we have seen on the internet, with a very open model where everyone can, with essentially no barrier of entry, write new applications and new code? But then, obviously, you want to keep the bad guys out. How do you do that? And at the same time, you have the problem, as we explained earlier, that users don't understand these permission models--nor do we--and suddenly Angry Birds asks for your calendar and you wonder, why is that? But I still want to play Angry Birds! So I don't have an answer to that. JOHN LEVINE: Either the user has to understand what's going on, or else you delegate the validation to some third party who you may not trust. And you know, we've been going down that rathole for decades. I'm wondering if there's a rathole that's less deep. TOM LOWENTHAL: As the saying goes in the security industry, there is no silver bullet. JOHN LEVINE: I was hoping for a lead one. CHRIS WEBER: There's a researcher called Timothy Lee who has been looking into the problem called trusted computing. That is delegating trust for other people to validate the permissions, without creating the walled garden sort of system that Apple has where there is one person who makes all the choices and you can't appeal them. So if you want to look at the alternative approaches to this, I recommend you check that out. DAN YORK: Dan York channeling John Klensin from the Jabber again. He asks, "If a CA has issued a Cert for example.mars, and ICANN sells .mars to someone, do we have a plan?" IAN FETTE: So, one of the problems is that it's not just example.mars. It's anything that's an internal host name. So a CA could sell a certificate for, you know, server.local or server.microsoft. CHRIS WEBER: And they have, for server.local. IAN FETTE: These will invariably get sold, as you point out, and they will generate conflicts, which is why we think it's a bad idea. But there's a lot of money in it, so they haven't stopped. DAVE CROCKER: This is my second time at the mic. The first time I said my name was Ross Callon, and I did such a good job of imitating him that you didn't laugh when I said that I was known as a nice guy. [Laughter.] DAVE CROCKER: In fact, when I got up, I was going to say something very similar to what he did. I don't think that the message is quite getting across, although the reference to the trust allegation gets there a little bit. And then suggesting that we give users more options of what to say. There's a fundamental quality that's like fingers in the dike to the kind of work that's done now. And they're excellent fingers, trying really hard to do a good job. But, I listened to four of you get up here and give rather unpleasant news to us, which we may or may not have already known. In fact, it's not new. It's true, but it's not new. And then we have one person get up and say, but we're closing the surfaces down. This is also true; the only problem is that we don't know what the limit is. So as much as we're closing, we don't know how many more there are to go. Let me suggest that we need to start with a simpler model. It needs to have the degrees of freedom it needs to have, and that doesn't include giving users lots of options. It needs the right degrees of freedom. So the trust allegation sounds like a good idea, but as of right now, the model of what we're trying to make better is the wrong model. IAN FETTE: If I understand what you're saying, we're starting with a set of a fundamentally flawed things and making incremental improvements, rather than a more sound model from the beginning? Is that an accurate characterization? I agree, we're starting from a complex model, and the incremental efforts are proving to be incremental with predictable results. I would love to start fresh from an approvable, sound base. I just don't think we can throw out the whole Internet like that. CHRIS WEBER: He's not suggesting that we throw out the whole Internet. Just the whole web. JEFF HODGES: Maybe another way to look at this is that all of this--the underlying Internet, but also the web--are experiments that escaped from the lab. But it's all been wildly successful, from a global perspective, and it's not showing any signs of really stopping. We need to look at things as probabilistic. We'll never shut everything down; we're always going to be trying to do a little bit better. And so far, we've been doing a good enough job that, in general, people are finding value in the services that are provided over the net. And people are making a living at it, also. DAVE CROCKER: There is an argument that the primary reason for that is not because of the very good work that you guys have done, but because the economics of the bad guys means they want to keep things going. JEFF HODGES: Yes. I've actually used that argument in discussion sometimes. PETER SAINT-ANDRE: And Dave, I think it's actually the economics of the good guys too. Because we've already heard that the CAs keep issuing certificates because there's money in it. And Ian is saying, we want to shut off the cipher suites or people complain too much, which equates to money. So we need to look at the economics here. HANNES TSCHOFENIG: Yes, thank you, Peter, that was a good remark. It is certainly difficult. As some of the speakers have pointed out, you have an existing web application landscape you have to work with. Of course, you could say, "Let's start from scratch and redesign everything and make it better." But that is not really an option unless you're working in a research project. The Web Security WG was created a little over a year ago, and there's a counter group in the W3C, and we have cross-participation to keep track of what's going on and make sure we react quickly enough to some of those developments. But it remains a challenge. CHRIS WEBER: What Hannes is saying is that we have a lot of very organized fingers. UNKNOWN IETFER #2: I want to also comment on security in the internet. We discovered that the Internet security model, using the client- server model is actually quite limited. I remember that the two gentlemen who mentioned the trusted computing model are from Google and from Mozilla. But I could not understand how deep you actually refer to the trusted computing model. Because this reference monitor concept that is kernel-built operating systems, and if you try to solve a problem like executing in mobile remote, you actually cannot just directly use the same concept session and identity that you use in exchange like a web browser or client server. It's the same with the cloud security model. It's utilization of a security model of utilization environment. A trusted computing platform can actually give a good idea how you can track all this check intersession, identification, and all this context for security. That actually creates consistent end-to-end security. So, my understanding is that IETF is developing a security model that needs to look wider. IAN FETTE: For us, in trusting computing, we have a trusted, load- verified boot which then loads a verified browser. We haven't taken it to the point of doing a remote [test] of the service that you're talking to. So someone like a streaming video provider might want to know you're a web browser that represents an actual user. There's lots of privacy concerns here; you don't want to give somebody an ID that tracks you across the web. How does the browser give an identification of me that doesn't provide a fingerprint of me all across the web. We've looked at TC to the point of getting a known good operating system and browser running, and we're starting to explore how we do identification to a third party. We haven't looked at combining identification into third-party environment back into the client environment. UNKNOWN IETFER #2: Yes, this is actually the way in which we're also moving in our research. Using trusted platform to insure integrity, and after that, you can protect the session-based data and privacy. JEFF HODGES: Hannes, I wanted to pop back to Dave Crocker's point on the bad guys. There was one thing, there's some really interesting work. Technology is not always this answer to the solution, as people were saying. There's economics and there's financial money flows as well, so there's different kinds of bad guys. But one big group of them are the people who are trying to make money off of everybody and playing against the rules. There's people, particularly Stefan Savage at the University of California San Diego, who are doing research on tracking down the money flows that are behind that and figuring out how to shut them off. They use technology to figure out who the acquiring bank is, for example, and putting pressure on them is not a technological problem. They're actually seeing some success in their results. It's quite interesting and something to keep in mind. CHRIS WEBER: Okay. We've actually defeated Felton's Second Law, which is, when presented with a problem, technologists will think it's a policy problem and people who work in policy will think that it can be solved with technology. BENEDIKT STOCKEBRAND: There's one thing I wanted to say about the entire TLS discussion which is probably rather displeasing for most people here to hear, but please remember that strong cryptography is hardly ever as strong as people think. In other words, we've seen a lot of crypto systems that were considered secure be broken, but we still have yet to see somebody prove that weak crypto systems are actually stronger than we expect. So we have a fundamental problem here in the way we think, and we should really keep this in mind. Unless I'm totally mistaken, in Germany, we have a problem. We now have identity cards--national identity cards that you can get a certificate with, chipping with them. And this certificate is secure. By law. AUDIENCE MEMBER: That works? BENEDIKT STOCKEBRAND: Yes. It does. If somebody messes up with your ID card and does funny things, it's your problem. That's basically what it boils down to. So if we don't get this straight, we can't expect politicians to get this straight. The crypto systems we use are inherently not provable to be safe. Complaining about users (or politicians) being too stupid to use them is sort of unfair, because we have our problems and our very area of technology, with the same issues. Just keep this in mind, because otherwise, we may wind up with the equivalent of some nuclear power plant getting swamped by some stupid wave or whatever. We should understand and keep in mind the limits of our systems. That's No. 1. And No. 2, strong cryptography is nice for a number of things but there are also a number of things that actually have a negative security impact from using them. Just doing everything on TLS doesn't really help in all cases; it can be quite counter-productive. It's much more difficult to do multi-level security, it's much easier to do denial of service attacks against an HTTP server, for example. I've had experience on that a long time ago. It wasn't very fun, simply because it's much easier to send crap to some HTTPS or whatever crypto server and expect it to try to decrypt things. If you do things in plain text, you can avoid that problem. And finally, there are certain people who have lots of problems that have strong crypto and embedded systems, especially battery-powered ones. So strong crypto needs battery power, needs chip servers. Strong crypto is not always the easy solution it may seem. IAN FETTE: You made a number of points, but as to the one that crypto may not be as strong as you think it is: we have cipher suites that we know are not strong and we know are broken, but we cannot turn them off. That makes me even more depressed thinking about the ones we think are strong but don't know yet. Yes, there are definitely problems we are not aware of, but there are plenty we are aware of that we can't even figure out how to solve now. ERIC RESCORLA: I'm not sure I'm entirely convinced by your argument about things not being as strong as we think they are. I think things change, but the history is remarkably encouraging. So even the algorithm you were just citing as relatively weak, there's basically no known good attacks on it. So, while people may dance about the number of systems they help if remarkably well and remain [viable] long past their expected design life. BENEDIKT STOCKEBRAND: We can talk about the strength of today's crypto systems and maybe in 20 or 30 years, maybe we would have a good laugh at it then. Yes, today we don't have any known attacks, at least not widely known or known to us, but that doesn't mean that they aren't there. HANNES TSCHOFENIG: But the issue of what Eric is saying is that the crypto algorithms are not our problems--at least from those talks and also from the workshop we had last Friday. If you want to solve some security issues, don't work on the crypto stuff; work on the rest and you will do us a much better favor. CHRIS WEBER: If your suggestions is that we shouldn't use crypto until we find some crypto that we know cannot have any attacks against it, I think that is a poor proposition. BENEDIKT STOCKEBRAND: That's not what I propose; but I propose if you travel by car, you drive carefully. You don't do things your car isn't up to. I just want to make sure that you realize and everybody here realizes that are there are limits to the way we use crypto. And if we use it without keeping that in mind, we're probably going to get hurt. TOM LOWENTHAL: I'm going to over-generalize what you're saying. Because when you're faced with implementing security for applications and even operationally across an organization, people have basically come to accept that there are limits, like you're saying, and things probably aren't going to work, and they're going to break down eventually. So we've taken a strategy of assuming compromise and assuming that we have attackers now amongst us. UNKNOWN IETFER #3: I just thought I'd give some information about that storm surge that hit Google when they disabled that algorithm. That was 0.2% of the servers on the net, plus or minus a little. RC5, RC4, with MD5. That was probably 0.2, 0.2, 04% of the servers out on the net. IAN FETTE: I'll just point out really quick, when we're talking about these metrics, it's important to not just count the number of servers. You have to weight them by the amount of traffic they get when you do the analyses. UNKNOWN IETFER #3: I don't have the exact number for those at the moment. But that's the number of servers at least, that I saw in sample of 600,000. MAX PALA: I want to assure everybody that the situation is not as bad as the guys here said. In a sense that, from a TLS and cryptographic point of view and X.509 point of view, we have instruments to deal with revocation and a lot of other things. The problem here is that browsers have been ignoring a lot of research in trust and trust- building efforts. So we find ourselves in a situation where browsers trust everybody for everything. Let's say that they give up in doing their job of verifying who is trusted or not, and ultimately that the user doesn't trust the CAs. The user trusts the application. And this is something that the browsers have to take care of, and actually there are activities that are going on. IAN FETTE: I would love to know what mechanism you think we have to actually do revocation, because we have found from our experience that the only mechanism we have, meaning the browsers, is to push a new version of the browser. We can't rely on CRLs, they're too large, and OCL fails. If you try to hard fail, you break the internet. Also the median OCSP response is on the order of hundreds of milliseconds. So we do not actually have a reasonable revocation mechanism. We have people trying to develop them, but there is no deployed reasonable revocation mechanism at the present point in time. We also don't have good trust control systems. MAX PALA: I understand the problems, but what you were referring is CAs that don't do their job. Actually you control your trust list, which is a mechanism that is 20 years old. CHRIS WEBER: That's a great question. If Verisign does something bad, should we revoke the certificate? IAN FETTE: No. We found out about this, I think it was on a Monday. We pushed out something that would block the certificate we knew about. Blocking it all would have taken down the taken down the Dutch government. They said, we have no indication that the other CA is bad. And they came back and said, we think the other CA is bad. So take the whole thing down. ERIC RESCORLA: It's important to remember that the problem is not just the CAs, it's the users relying on the certificates issued by the CAs. WES HARDAKER: The brief point is your marketing department is broken. It's very broken, because the thing is, all the applications these days end up getting in these races, and the races are badly prioritized because what happens is, one marketing department says, our X application is faster than everybody else's. And it doesn't matter that you're stripping security features out of it, or it doesn't matter that you're saying, we're not going to use this algorithm anymore because we get too many bug reports. And you refuse to say, it's not our problem. I'm amazed that nobody at this point has started turning off Windows firewalls because it shaves off a few milliseconds to speed up packets to the web browsers. Somebody needs to say, ours is more secure. We will save you from maliciousness on the internet. And right now, that's not where the focus is. IAN FETTE: I agree with you that we need to focus on security. I disagree that we're not focused on security. I assume you're talking about us. WES HARDAKER: No. I'm talking about everybody. IAN FETTE: I think there's lots of browsers out there right now that are focused on security, even if you look at Internet Explorer, who I used to love to poke fun at. IE10 is much more secure. Chrome, we put a million dollars on the line for our recent security conference. I think we are doing a lot to make sure that security is a priority. I reject the notion that we're trying to shave off security for speed. Not turning off MD5 is not a matter of speed. If you break a significant portion of the web, (A) you just can't do that, and (B) the users are just going to go to another browser. So that doesn't actually solve the problem. It's not quite as simple as saying, "Let's break some percentage of the web." WES HARDAKER: I'll give you an example. I didn't say it's not important. Speed is more important. I've talked to multiple browser vendors in the last couple of years who said they will not do DNSSEC for every request, because it will slow it down. We will not do extra security because it's slower. CHRIS WEBER: I think that you include in that statement the assumption that DNSSEC is actually extra security. BILL MILLS: In one part of the talk, you had a suggestion that we should go to 100 percent TLS, and that would be a great thing. But on the other side, there is actually right now a useful boundary in the cookies space and security model in the browser where things are SSL- only, and you have things that are less trusted. Is there a trade off there in terms of pulling everything into the TLS side, or would we be potentially pulling in things that are less invested into someplace where we had things that were more secure or more valuable? ERIC RESCORLA: I think the answer is largely no. I think it's already important to remember that the isolation is extremely imperfect, and in particular there's a right HTTP / HTTPS side which makes it extraordinarily imperfect. Google is pioneering this by cutting up different domains and HTTPS not HTTP. HANNES TSCHOFENIG: Let's thank the panel members for their presentations for their discussion. [Applause.] 7. IAB Open Microphone Session Bernard introduced the IAB: Outgoing members - Olaf Kolkman, (IAB Chair, 2007 – 2011) - Andrei Robachevsky - Dow Street (Executive Director, 2008 – 2011) Incoming members - Jari Arkko - Marc Blanchet - Mary Barnes (current Executive Director) Incumbents (terms expiring in 2013) - Alissa Cooper - Joel Halpern - Russ Housley, IETF Chair - David Kessens - Danny McPherson - Jon Peterson - Dave Thaler Returning members - Bernard Aboba - Ross Callon - Spencer Dawkins - Hannes Tschofenig Lars Eggert (as IRTF Chair), Heather Flanagan (as RSE) and Leslie Daigle joined the IAB on stage for the open microphone session. An edited transcript of that open microphone session follows: BERNARD ABOBA: At this point I'd like to open up the floor to questions for any of the IAB, IRTF, RSE or questions on Leslie's World IPv6 Launch presentation. [Silence.] BERNARD ABOBA: Since we have to have at least one question, we'll be asking questions of the audience if we you don't get at least one from you. Hopefully we have some good ones. [Laughter.] BILL MILLS: I'm always good for a question, whether it's good or not. [This question is for the RSE.] For those of who haven't had a chance to read up completely yet, can you discuss what the most compelling possible alternative to text is, and what your honest opinions are on this? We're going to all have opinions too, but if we were doing a BOF and polling you, is there general consensus on your end yet? HEATHER FLANAGAN: No. UNKNOWN IETFER: I have a question regarding IAB workshops. We know that occasionally there are some workshops before the IETF meetings that are organized by IAB; for example, that we had the Smart Object Security workshop this time, organized by Hannes. I just want to know, what's the policy about the organization of the IAB workshop? I mean, how can we make the workshop and things happen with help of the IAB, and possibly, sponsor on the back end? HANNES TSCHOFENIG: That's a very good question. First of all, there was a workshop [http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/] last Friday on Smart Objects Security, and I will send the papers [http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/] and all the slides [http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/slides/] around. But I have to say, there were a couple of folks from IAB and also others involved, but it was actually not an IAB workshop. A couple of us just thought that we should really get together and talk about this. On IAB workshops, it's pretty much a community-driven approach, as we are ourselves working in given working groups, and we see problems that need further discussion. Other people could say, I could host something somewhere, so we do this. It's very interactive. For example, if you would like to host a workshop where you have proposals for topics or anything else, then your input is appreciated and of course, it's a message not to speakers only, but to everybody else. If you think there's a workshop topic, or any other topic that you think that the wider community needs to discuss, we can definitely talk about it. Obviously, there are lots of different ways to make progress on certain topics; a workshop is not the only possibility. If you have anything that goes beyond the IETF work, come to us and work with us. BERNARD ABOBA: One thing I would add is that we have IAB Programs and Initiatives, in order to enable the IAB to complete a coherent work plan. That way we don't just have an IAB workshop and abandon the topic. Smart Objects is part of the IP Evolution initiative so there are a group of people (IAB and non-IAB) accountable for it, and there are owners responsible for follow-through and accomplishing a set of goals over time. ANDREW SULLIVAN: Before I start this, I want to acknowledge my part in the responsibility for the thing I'm going to talk about. Recently, a communication went to ICANN about their management of the root zone, and in particular, the character sets that are going to be used for IDN labels in the root. I don't want to cast any aspersions on what happened there, but the communication went to ICANN rather late in the process, and, we spent a lot of time working on that. But ICANN is doing a great number of things in the root zone, and I'm wondering if anybody has any ideas so we can make sure a repeat of that does not happen. What happened is practically two years into ICANN's massive expansion, they got the message that it would be a bad idea. I have to put my hand up and say, I was one of the people late on that, but I don't know how to fix that, given our own procedures and the way that we are not in sync with other communities. I'd like to know if anybody has any ideas on how to avoid that in the future. BERNARD ABOBA: Dave, do you have a comment? DAVE THALER: No. I'd ask the same question. I'm in the same boat as Andrew. We have the Internationalization Program, which is where this was originally discussed. It was also discussed in the IANA Evolution Program that we have. And I don't think I have any bright ideas on what to do, Andrew. So if other people have ideas, we're open to input. BERNARD ABOBA: I think we have an open action item to figure out what happens next. DAVE THALER: Right. Part of the open action item has to do with RFC 1123, which defines the concept of internet host names, and there's some language that says it will be alphanumeric only. We're already violating that [with IDNs]. The action item now is to make sure that gets fixed, because the current RFCs can be read, but that's not the current intent. We're trying to figure out the right way to push it through the process without delaying allocations, and that's part of the reason for the ICANN exchanges: to clarify that's not harmful, and we do need some things to get done in the RFCs. BILL MILLS: It's Bill Mills again; I'll always grab a mic. On the RFC format stuff, because it's everybody's favorite: I'm not an enormous fan of the current text format, as it has several obvious advantages. My personal preference would be something relatively close to that, maybe something that could be transformed into the text, and other more happy things like PDF and things like that. Is that one of the favored directions? I mean, if-- SEVERAL PEOPLE IN THE AUDIENCE: Go to the BOF tomorrow! BILL MILLS: All right. HEATHER FLANAGAN: Yes, the BOF tomorrow is going to go over some of this. But because of the massive wealth of history behind this particular topic, and the fact that I have only one hour for my BOF, I've solicited folks to come ahead and submit their brief lightning talks to give me a heads-up on what's going on. This topic has been around so many times, I felt if I wanted to make progress on it, I could either ask the community to give me a sanity check of where they think things stand now, or I could review the last ten years of the RFC-interest mailing list. I like my hair brown, not gray, so I chose the informative method. I don't think I should have an opinion. Do I have a personal opinion? Certainly. Am I going to share that on stage? No. As RFC Series Editor, I don't have an opinion yet. I need to hear from the community and see if the consensus is there. That's the decision, not what I think or whether my boyfriend said he won't love me anymore if I don't allow text on dumb terminals. So see you tomorrow night. BERNARD ABOBA: Do we have any questions for Leslie on World IPv6 Launch? RICHARD BARNES: On the IPv6 launch, I've been enjoying the cat pictures and the slogan, "This time it's for real." I wonder if you're interested in hiring the proper voice-over actor to go along with those. LESLIE DAIGLE: Interesting idea. We'll have to take under consideration for an expanded social media campaign. BERNARD ABOBA: Okay. Any other questions? If not, I think you're off for dinner. Thank you. [Applause.] [End of plenary.]