IETF 83, Paris France,
		Technical plenary.  
>> Okay.  Welcome to the IETF 83 technical plenary.
		So, a few little pieces of information.  The presentations have all been up loaded with about a minute or two to spare.
		So they're up on the materials management site, including the agenda.  And we will be using the jabber room, the note well, I won't read it, a little blit about the agenda.  
>> We'll have a session by Leslie Daigle introducing IPv6 launch and we'll have our open microphone session, because this period is very packed, we'd like to ask you to hold questions towards the end and hopefully we'll get them all in.
		But, we'll need to do that, I think to get through the entire agenda today.
		So, that's our addenda for this evening.
		So, I'd like to ask Lars to come up.
		Yes.  
>> Hello.  My name is Lars Eggert and I ever chair the IRTF task force and people are coming and going in jabber.  Don't go to bad attitude yet.  Wait until after this one.
		This will be brief.
		We do this every IETF, so you should be familiar.  We have six research groups in the meeting this week.  The network complexity group is new, they met the first time this morning, if you missed that, join the mailing list.  Mobility optimizations, delay tolerant networking, I cc R G.  The scaleable adaptive multicast, and crypto forum is the first time we meet physically on, they meet on fray, if you're a security guy, you should really go there.
		There's another working group that is meeting on Saturday, which is a network management research group.  They have a meeting together with the workshop, on usage of net flow and IPv6 and network management and that's this Saturday.  I believe the coordinates are on the mailing list.  We don't have an IETF open meeting.  We had one the last two sessions, the feature presentation was the invited talks from the applied network and research prize winners, we didn't hand outd prices for prizes for Paris, and hence we have no session, I will get to why in a little bit.  And we have an official meeting on Wednesday, with some proponents who are proposing a research group on information and centric networking and that's the lunch slot.
		This is my slot take on the activity.  Research group.  The virtual group on the bottom has closed since the last IETF meeting.  Despite various attempts of re interjecting energy the community has moved on and therefore decided to close.  I would count two-thirds of the research group active for some definition of active.  And that the rest of this, sort of struggling a little bit with energy.
		This is our stream.  The IRTF stream, you can see it's way less busy than the IETF stream or maybe the IAB stream but we did publish three documents since the last meeting, two of them are the hip research group and woun out of spam if I got the colors right.
		So, the applied networking research prize we handed out four of them together with ISOC who is graciously funding this on the selection committee and we have a call for nominations, and there's a web site that you can go to to read more.
		We decided together with ISOC and the selection committee members for 2012 and later we're going to a yearly nomination and award cycle, rather than having one cycle per IETF meeting.  It turned out to be too frequent for the academic time scales so sging forward we're going to have a call for nominations in the fall of each year, we're going to select the prize within ers for the following year and invite in winners for the following year and invite them.  We're going to ward prizes for all of the three prizes in the following year and we together with the winners will figure out who will attend which meeting.  Oftentimes there's re sfrixs with Visa and so forth.  sos this is the schedule we're moving to.  In 2012 this is difficult, since we're shifting greers gears, we're going to skip Paris and it was fot possible to run a call where we think we get enough quality papers in. 
So we skip Paris but we're going to have a call, trip open some time this week when we iron out the last issues with the nomination sem system and we're going to select awards for both Vancouver, and the summer and Atlanta in the fall.  So, watch that URL and subscribe to IRTF announce and you'll see the call for nominations and I encourage those of you who hang a around the academic community, if you think would be a git fit, summarized in the little blush there, to nominate the main author for the prize.
		Finally, we have an intellectual property rights statement in the IRTF as well.  The one thing you need to remember is, that the IRTF follows the IETF rules.
		So, there's nothing that is new other than this is now being explicitly stated.  dwas sort of unofficially implied before.  Our intellectual property statement is slightly different but the rules are the same.  The difference is that our little statement and you can read it here other at the web site, is actually descriptive.  So it tells a new IRTF participant what they have to do to comply.  Rather than, you know, the IETF note well, which is a little bit more cryptic in what you actually have to do.  So this is ours.  And that's my last slide.  Any questions or comments?
		
>> Thank you.
		
>> 
>> Okay.  The IAB is an international organization so some people ask us where it is located.
		And we tell them, all around the world, and this is one of the main IAB out posts.
		By the way, if you see other locations, please send in the photos and we'll use them in future meetings.
		A little bit about the IAB, these are some places you can go to get information.  The charter, the, we have a relatively new web site.  List of the programs and initiatives, some of the drafts we're working on, correspondence and minutes, which are up to date, thajs to Cindy.  A few of the IAB responsibilities are listed here.
		They include IESG appointment.  Architectural oversight, standards proper sos oversight and appeal, RFC seer reens and IANA.  External liaison.  I'd like to introduce some of the incoming IAB members.
		This IETF we will be congratulating and veting our outgoing members on at the Wednesday plenary.  So hold the applause and thanks to them until then.  But the new incoming members are Jari Arkko.  Jari?
		Mark plan Chet.  Is mark here?  We have a new executive director, which is Mary Barnes.  Mary?
		
		(Applause.) 
>> And then there are the incumbents and returning folks who you hope hopefully already know.
		So a little bit about the perhaps and initiatives, we have technical programs, privacy internationalization, IP evolution, emergency services, which is new.  Http web evolution.  DNS and IPv6 for business.  And then we have our administrative programs which include RFC editor.  IANA oversight and U ITU-T coordination.
		Here are some of the public mailing lists that can be used for discussion of some of the technical and administrative things.  We have a general architecture mailings list, we have an international mailing list, a privacy mailing list.  vrn one oo the RFC series.  
>> This is a list of the activities from the IAB web site.  I wobt go each of them, s the IAB web site is a good place to get a sense of what the IAB is up to.
		And I even kourk you to go there.
		So, a little bit about documents, we've published one document, which was the report from the internet privacy workshop and I have two more in the in the queue, one is from the sobs workshop and the independent submission editor model.  Also, we just submitted the RFC editor model V-2 for publication, so we are done with that as well and combined with the hiring of the RFC editor who will talk and get to meet in a minute, and the re appointment of the I S C model we had some major accomplishments about the RFC series, which we're very glad to conclude.  vrn then we have some additional work items.
		So this is a list of the RFC published in the IAB stream.  We have three that are I guess, four, now for approval in 2012 and hopefully we'll get some other things published vrment
		So as I mentioned the RFC series, we have appointed a new RFC editor who you'll get to meet in a moment.  We appointed the independent submission editor and gotten the docks mentsz out that describe their jobs as the models.
		Expense sore Dawkins has been working work Spencer Dawkins has been working on the work, and will clarify that for you folks and as well as for us, and hopefully that will be out by the end of the week.  In terms of things going on at ICANN, the IAB submitted an ICANN performance evaluation.  Appointed Peter as liaison to the RSOC, and recently put out an interpretation of rules, about the ICANN G T L D applicant guide book and just today we submitted a clarification because we get some questions as to what the statement actually meant.
		Some external liaisons, we responded to an ITU-T liaison on updating the collaboration guidelines, RFC 3356 BIS.  We've nominated Hannes and Olaf as representatives to the multi stakeholder platform on I T C collaboration.  And Dan romzs has been appointed to the IAB and about issues of global in operability of emergency services.  There have been no appeals.
		
		(Applause.) 
>> Since the last IETF.  And that's it.  I'll leave the, there's a lot more detail on the programs and initiatives and their progress but I'll leave that to your leisure and you can read it in the slides.
		Next I'd like to ask Fred and Heather to come up to the podium.
		
>> So in a minute, we'll do the slide show thing.
		Okay.  Whatever.
		
>> There is actually a full screen deal.  
>> There's a slide show.
		Here it is.  
>> Oh okay.  So at the last couple of IETF meetings, I've reported to you as the chair of the ISOC and yeah yeah, we're working on that.  We really ought to have an RFC editor.  Maybe we should consider that.
		So, we conducted a search, and talked with a number of people, and ultimately, in November, made a recommendation to the IAB which it announced in December, after we had done some negotiations and actually agreed on that.
		And, at this point, we actually now have an RFC series editor.  So I want to introduce Heather flan began.  
		(Applause.)
		
>> In the internet society.
		So, hi.
		But I figure what you are all probably more interested in is what's actually on my list, what have I learned since January, when I started.
		There's a lot of things pending.
		Including updating the web site, which has information that hasn't been updated in the last four years.  There's the style guide which was actually put at the very top of my list before I started, there's question on is the auto process what it needs to be.  When what you'll see, I want to review them, that doesn't mean I want to change them, that means I want to understand them better.  Very open to input.
		I know this will come as a great shock to you but there's been this question out there about the format for RFCs and whether ASCII should remain the standard, have you any of you ever heard about that.  I didn't think so.  So if you'd like sort of a quick fire hose summation, come to my BOF tomorrow night.  It's going to be lightning talks, people have seven minutes.
		To talk.
		For what they know, and what they would recommend, but no decisions are going to be made, this week.
		So, there's going to be a lot of other things on the list, some things have actually already been accomplished such as updating the copyright page information and getting a site map on the web site.  Providing feedback in the 46205620 BIS, at least in part what my job S and in terms of what are the things I'm working on.  Just this very moment, we have the style guide which is gb going to be split into two sections, there will be the section, we're calling it musting and you'll see some shoulds in there too.  But this is the permanent rules for how RFCs are edited and published.
		The web site is going to exist because there will be over time, changes made, as realities change and as we test out those policies and procedures, they'll go in a web site before we come back and update the RFC style guide version in the future.
		I'm also, as I said, working on the web site.  I will have a WIKI space, because I find that the easiest way to share information about what I'm doing and I want that to be a very open process.  General content update and as discussed in RSOC retreat earlier this week, format is definitely coming up to the top of the list.  The other things that you saw are important, but they'll get there as my queue clears.
		So, that's what I'm doing.  This is where I will be if someone actually want toss find me and either just say hi or ask me a specific question, at which point I can look to sandy and Alice and say, is there something I should know and we'll see how that goes.  You can always find me via e-mail and I look forward to meeting everyone and not remembering very many names over the course of the week.  Thank you.  
>> Thank you.
		
		(Applause.) 
>> 
>> Okay.  I'd now like to invite Leslie to the stage.
		
>> Thank you.  Yes.  soy the world IPv6 launch.  And we do all remember where we're trying to go and why we're trying to get there, right?
		The grass is greener on the other side.
		All right then.  So, in a nutshell, world IPv6 launch in 2012 this time it's for real.  There are stickers to this effect if you haven't got it.  It's a kick off sdait for regular business with IPv6.  Commercial IPv6 at scale by year end.  No, not the whole world yet but some key contributors who decided to get together, commit to this, and get the ball rolling so we can actually understand that this is for real.
		And if you will recall last year, for 24 hours on the 8th of June, Facebook, Google Yahoo and more than a thousand other web sites turned on packs on their front door.  It was a global real world test flight of IPv6.  Really demonstrated the kind of collaboration that brought uts us the internet in the first place and brought the industry together to actually commit to a very important and effective event.
		People commented in plenary, in July, wherever we were, that the traffic numbers were not really that impressive and this is certainly true.  Although notable, in France, where free has had IPv6 enabled for their kebs for a couple of years, it was considerably higher than the general average.  So, pretty clear demonstration if you enable your network with IPv6 it will generate more IPv6 traffic.  What a surprise.
		But the point being that you don't actually have to have skilled users looking for it if you set it up correctly.  So, the background motivations for last year's event and this year's event, again trying to break the chicken and egg problem.  Content providers need to understand that if they make their content available at IPv6, they will actually have customers coming and viewing it.  At the same time, access providers don't want to do the 3WU8D out for IPv6 if there isn't anything for their customers to reach once they have the IPv6 availability.
		So, that's the key issue in both of these events.  Certainly aiming to improve IPv6 connectivity.  Last year there were, there was an outstanding number of issues with you know, potential client misconfiguration, software defaults and we made a lot of progress on that last year.  This year, I think we're going to see a lot of progress in terms of connectivity.  And certainly from the internet society point of view we hope it will spur organizations to create their own plan for rolling out IPv6.  In more specific detail I'll outline the world IPv6 launch in general.  I will say the parameters of this event were put together by the key participants who agreed to leap off the bridge together, so to speak.  It was their commitment to these parameters that is bringing the event into reality.
		You can hear more from some of them, directly, at the host lunch that's happening this Wednesday.  Because there will be another discussion of world IPv6 launch with words from some of the participants themselves.  So I certainly encourage you to get to that event and hear those details.
		Specifically world IPv6 launch is 6 June this year, and it becomes IPv6 becomes part of regular business.
		This is again, access providers, home router vendors, web sites from around the world and certainly we're looking for more participants.  We're looking to accelerate so that those who have some plans will speed them up, we saw that with last year's event.  We're looking to, you know, encourage those who don't have plans yet to understand that the water is safe, come on in.
		And really, as a stake in the ground to say, look, IPv6 is the new normal.
		That's the way it's got to be if we want to get to that greener grass.  So, as I said, several companies will be leaping off the bridge together.  And the web site front, the Facebook, Google Bing and Yahoo, again, pointer to where you can sign up if you'd like to participate.  If you're an Limelight customer, you can talk to them about enabling yourself there.
		The goal for web sites, the requirement for web sites, is to enable IPv6 permanently, on your main web site.
		No side IPv6 web sites and no mirror sites, for real in your business.  And, what we saw with the example from free, if you do that, then IPv6 enabled customers will actually use that natively.
		We will have a reach ability dashboard which was similar to the one we used in 2011 so you will be able to see who is actually living up to their prom 34EUSes on the web site front.
		As I said from the a roubd the world.  AT&T, free, access for all.  And additional welcomes are welcome, additional networks are welcome to join what you need to do to play the game, new subscribers get IPv6 on by default on June 6.  No user configuration required on their part.  And one percent of visits from IPv6 from participating networks by June 6.  That one is a little bit tricky, it may seem like a small number unless you're an access net wourk provider.  The deal is you have to enable a lot more of your network for IPv6 in order to make sure that by the time you whit tell away the people who don't have v6 enabled routers or who otherwise are not going to be able to connect over v6 to give you that one percent number.  So that number will be measured by the big participating web sites so we'll have metrics there as well.
		We have home route err vendors participating.  These are critical to make sure the access networks ask see, Cisco and D link have stepped up to the plate and additional home router vendors are invited to join.  The key things are to have the majority of your products shipping with v6 on by default, without user configuration required, in the v6 inter operability verification by U N H I O L.  And we're exploring the possibilities of others.
		Yes, so, the joining IPv6 world launch is a commitment to commercial grade IPv6.  We recognize that it's a relatively small fraction of the overall industries that have stepped up to the plate.  But I think that by very nature of the fact that there will be v6 in the world commercially for real, will start the draw towards more and more option and acceptance.
		We saw that the world IPv6 day blue the door about pre contraceptions about the do ability and possibility of coordination between industry players.  And we saw that it really did change minds.  And that's really our goal for this year's event as well.
		And after all, it is for real now.  Seriously.
		So, that's it for me, and I think Bernard you said questions at the end if any.  Okay.  Thanks.
		
>> I do want to point out that I think a couple of IETF's ago, when he asked when you'd be able to get cute pictures of cats over IPv6.  And the answer is, we're sending this out on the internet right now.  And on world IPv6 day it will go to the next level.
		
>> Okay.  I'd now like to ask our technical panel lists to come up to the stage.
		I think I've got all the slides, including Jeff's here.
		So, 
>> Jeff?  Okay.  
>> So, hi to you all.
		My name is Hannes Tschofenig, I'm a member of the IAB and I'm tasked today to introduce a security topic to you.
		We are going to speak about implementation challenges of browser security.  As you can see I have, well, actually not see, we have five panel members.
		I will start with an introduction, then we have a couple of sort of position papers, experiences shared by the, our panel members, and then, I will welcome feedback nk questions from the audience.
		A little bit about the background of this pln re talk.  So if you look back in 2011, you may have noticed a couple of security incidents.  There were actually a couple of high profile events and that had also gotten into the media and had, gotten attention of, politicians, and governments.
		So, if you look at each of those, there is obviously a broad range, and there are many different reasons, like from, starting from misconfiguration, to regular implementation bugs like buffer overflows and sort of very basic issues, like even my favorite gaming platform steam got hackd.  So it's really bad.  But many of those aspects are actually outd side the IETF, so while we work on the protocols, there's a longer chain of events that actually need to happen to have secure deployment.
		So to keep up with this sort of every changing landscape we are working on many different security technologies and if you had attended some of those sessions earlier today, you may have been to the web security working group, and there are many other groups meeting during this IETF to talk about various different security protocol enhancements.
		Clearly, there is internet security, is a fairly broad space, so it's impossible to touch on all of those aspects and so we only focus on one slice of it and specifically, the web today.  So that's why we have this focus on implementation challenges for browser security.
		If some of you have been at the Prauge IETF meeting a year ago and there we spoke about sort of the developments in the web and implications for the standards community with http usage, and also with the java script as mobile code distribution platform, we call it post standardization, and of course every one of you is sort of using web and mobile phone applications, but, there's obviously far more under the hood than only those who work in the application layer have been more exposed to those aspects.
		So it's, the web platform is a constantly and rapidly evolving ecosystem and you see when you look at the protocol stack there are a number of different components in there rn I listed a few here on the slides.
		And on toop of that, there's actually the web application.  Which sort of like, before it's different forms like java script code and so on, then provides this sort of rich application experience, that we all enjoy.
		Unfortunately, the side effect of this sort of very rapidly developing ecosystem is that we see more and more threats and vul ner ra ability showing up every day, and so we were wondering, as we were putting to the panel, so if like, what can we do to actually improve the security properties of that ecosystem, of that platform, and specifically, have the capability to slice in some new components, into the platform so that applications are not disrupted.  They, the existing applications, experience from, have benefits from those new kurt components.
		But also, to enable more security new applications.  And it turns out that, these new security features, and introduction into those existing ecosystem causes some problems.  You've heard the IPv6 announcement earlier, compared with IPv6 roll out, there's along transition period as you deploy new security mechanisms as well.  The old stuff doesn't quickly go away chb users don't quickly switch to the new techniques either.
		So, following my short introduction, I'm going to introduce you our panel and let each of them give a short presentation on some of the observations they had made, in their work on, with web security.  So start with EKR.  He's the chair and probably known to most of you guys already.  He's the chair and long time contribute the tore of the security working group.  And he worked on transport layer security, 1.2 and all the other specifications as well in that group and D TLS.
		But he had also reached out to other working groups, specifically in the RAI area to help make the protocols more secure.  Thomas, he works at the Mozilla privacy team where he translates between engineers, lawyers and users and communicates the Mozilla's standards.  And we also have Chris Weber who is the co-founder of Casaba security where he works with leading web companies to he been secure the.  And he Joyce being involved as a working group chair.  He and has spent the last five years making chrome more secure and faster browser.  He's the author web socket and W C3 evrlts and finally Jeff, the guy who showed up late here is a member of internet standards and government team and he's working on various facets of internet security.  And he's active in W3C internet standards efforts.  Without further delay I will jump over to our first presentation, if I find the slides.
		Where are they?
		
>> Questions, we have the questions at the end so we don't get the time completely out of hand.
		
>> So, as I was coming up here I was reminded of two things.  First to speak slowly.  So if I'm not, you know, somebody do 
		(Applause.) 
>> Yeah.  I know.
		And second, that, you know, that you can humiliate me and everybody else up here at vote at apps spot dot-com.  Unfortunately I'm not HTTP S.
		So unsurprisingly I'm going to be talking a little bit about why it is we have this TLS and maybe how to get more out of it.
		So, if we're going to have web security and web applications and a distributed platform obviously the first December rat ta is that you actually get the data from the server that you think you're getting and that other people not be able to read it and tamper with its, et cetera.  So in the web virpt e environment this means hps hpts, and we have this active working group.  And the it's cosmicly large No. 6 RFCs and every major browser and supports it and although the browsers have not been good at keeping up with the newer versions.
		But, the actual picture is actually quite grim.  A lot of the important xher shool sites run hpts, but the vast majority of is not encrypted I've seen estimates of one percent to ten percent is encrypted and something like one percent offer http S at all.  It should be 100 percent or as close as we can possibly get.  Despite the fact that IETF.  So why do people not do this.
		It seems likt a pretty straightforward cost benefit problem.  It's a hassle to get it running on your site and if you're running a non commercial site, people say what's the problem 
>>?  Who cares if anybody can download the data.  What are the costs.  The certificate system is like a huge mess.  Tom will talk later about, you know, for the problems of when the wrong people get certificates, but just as problematic it's hard on for the right people to get the certificate.  And it's, there's still a lot of technical problems that mean when you try to turn from http to https, bad thing happen.  So in particular, there's a thing called mixedd content and people are trained to type http, and we have to kick them over to https.  Those are sort of lower, from sites that are important, and most sitsz are not even, close to the issue.
		So, this is why.  IETF vote doesn't run https.  I asked Cullen experimentally when I was preparing this talk to get me a certificate.  And to take pictures of everything as it was happening.  About 45 minutes later I get the following message in I M.
		
		So, you know, if a man with a Ph.D.  Can't do this, who can?
		I think afterwards, we'll show you the video of the screens, but I think Cullen has not done it even after 48 hours.  So, like this is the a difficulties disaster.
		Moving onto an alternative.  And I'm not going to talk about it in the detail.  But the one people are most familiar with is storing the keys or hashes to the keys or some such thing in the DNS and securing it with didn't SEC.  And so maybe we can replace 5509 with something like this.
		There are transition problems that make it a hard sell.  Collective action problem.  Where every browser in the universe support 509 P kicks and no other browser supports any other method.  If you're a server and you want to taw talk to anybody.  You need a certificate.
		So, if we had some new system, now you have to have two credentials, one for certificates and one for the new system.  This situation will more or less last in perpetuity, five or ten years at least until every client has whatever the new system is, because only at that point can you expect people to talk to you.  Conversely this means that clients don't get any benefit from implementing verification from the new system because they can't talk to anybody, and of course, it keeps moving around because if clients don't smort it, then clients don't either.  The question to ask, is, at what point can servers stop getting certificates.  The answer is probably almost never.  This is not applying to systems that misuse of P K certificates.  Only allow the following certificates for me. 
And that's a totally different situation.
		We actually have a good working example of this in the server name indication.  So, people, may not know this, but originally when TLS was first deployed and first designed to only support one server per IP address.  So https has multiple servers.  TLS didn't support this.  This made TLS more expensive because you had to have a separate IP for each system.  So it's common to have the hosted service providers to charge you more extra to run TLS because they need static IP.  This problem has been known about for 15 years and it was fixed in 2003 in this thing called server name indication.  The client connects to the server and says this is the server I want to talk to.  This is supported almost everywhere.  But not quite everywhere.  So unfortunately, even now, windows X P, if you're running I E on windows X P, the consequence is, it's hard to estimate but probably five or ten percent of the clients, can't turn on the thing and hope it's going to work because you have a problem.
		So, you anticipate something similar happening in any alternative system and the situation is worse because it doesn't actually bring anything to the server whereas S S N I does.  Imagine you got past this problem and you have a certificate.  What now?
		So I've got an http site and I want people to Hughs https.  Unfortunately all people are trained to type http in the browser bar.  So we need to train them.
		This will work, but now we have an active attack problem.  So the client connects to the site and the man in the middle basically suppresses the redirect, and the client thinks everything is fine and the server thinks everything is fine, but it's not.  We need this to be done in a secure fashion.  So once you're doing it once from your home e network it sticks around.  A lot of possible biltsz have been explored.  Speed has an upgrade mechanism.  Maybe a DNS record.  There's https everywhere that is a catalog that D T L V S.  And there's a lot of possibilities but we need something.
		Okay.  The second problem, just turning on H T P S is this, if you have, of course, understanding how java script works.  If you have a page that loads java script, all the java script runs in the same context no matter where the it's from.  Say I'm running a site and I suck something from Google analytics.  That stuff is all run anything my security context.  That's every security piece on the page even though it didn't come from my site.  It can read cookes and generate requests.
		So, what happens if, when you have an https page and you load a script over http and the consequence bees Is the attacker has a lot of control over the page.  It's not quite as bad as everything over http.  So this is active mix content.
		So, not great.
		So, unfortunately, this kind of stuff happens all the time.  Here's an example.  Slate, popular web site.  This stuff on the left, you can't really read is like chrome's list of every script it's loading and about a third are off site.  This is http page.  Generally, the pages are just, not occasionally, the 350E78 load up scripts, this is the norm for how the web works.
		So the browser manufacturers are very cognizant of this problem and they're doing something about it.  What they're doing is being more aggressive about not allowing mixed content.  So right now, the simple majority will accept mixed content and maybe give you a warning.  But more and more of them are going to oppress it by default.  This is chrome canary.  You can see this annoying bar and you have to override this.  I wouldn't be surprised to hear I have no internal information about this, that some day, even the it's going to be hard to turn it off.
		So, we have this, another collective action problem.  It's obviously do what the browser manufacturers are doing.  But it's a threat.  However, it makes it very, even more irritating to turn on https for the site now, because now it works just fine and now it doesn't work on anymore because I have all these http dependencies, maybe some of the dependencies are not served over https at all.  So sometimes you'll see things where you simply can't get it over https.  Even if you can, you have to modify the links.  So we need to find some way to square the incremental things on site, because you want everybody to gradually migrate and you want it to be painless as possible but they're not going to do it if every time you do it everything sploydz.  I don't have a great answers here, ranging from the browsers keeping cashing, and URLs with hashes and there's a bunch of possibilities. 
So, but, or another possibility is sort of a mixed mode like speedy runsz where it's over TLS but not aggressive.  So there's possibilities here and we need to solve this.
		So, summarize, if you want to have any web security, you need some communication with security first and as a practical matter, this is going to be TLS you can't replace TLS either.
		But we need to make it easier for the server operators so when we have the choice to use TLS or not, it is not a pain, so that you know, that way people don't have to make a Hardie sition.  This involves, somehow making service side credentials easier, and hopefully harder for the attackers, it involves making it save without making anything to explode, and making users convert as fast and secure as you can.  Hopefully, this is something I plan to work on over the next couple of years and I hope some of you will too.
		
		(Applause.) 
>> 
>> Yes, deep magic there.
		I'd like to thank Hannes for inviting me to speak here, and remind you, if you have questions please hold them until the end of all these presentations when we'll have a long Q and A session.  I'm Tom Lowenthal, and I'm here to talk about cryptography and its infrastructure, also known as the P K A rat whole I hear.  So I'm going to say three things.  I'm going to give a fair RAI tail or general and the need for P K I, I'm going to splain that everything, works perfectly and is broken, and then talk about the mirror implementation details being some of the most important details of some of this type of system.  So once upon a time, in a disz tanlt far away Kingdom everybody was worried about security.  And so a couple of brave heros came together and they man geld some magical numbers and they produced a super perfect complete system, called public key encryption. 
And this system is completely perfect, because it is completely not penetrate able as long as you do it right.  And it has the beautiful property that you just make sure everybody knows your key and they can encrypt messages to you and verify you all the time and it has no problem.  Except for the problem of making sure that everyone knows your key.
		So, in the early days of cryptography, we assumed that this would be solved with the crypto key fairy.  So if you wanted to know somebody's key, you clap your hand s and three times spin around and the crypto fairy whisperd in your ear.  This was not scaleable.
		So we moved to plan B, which is just finding one person that everybody trusts and they would hand out all the keys.  You go to them and they tell everybody what your keys are.
		So the problem was finding a person that everybody trusts for all their applications, whether it's me checking my pictures of cats, or the activist in Iran doing something that will get him killed if he is found out.  This is a really easy problem.  Because we found about 1500, depending on how you count them, people that everyone trusts all the time.
		
>> And as you can see, from just some of the companies on this list, all of those 200, 400 people never make mistakes.
		
		So, in addition to the major mistakes, like some of the people in the previous ones, they routinely sign things that are wrong.  They issue certificates for names that don't exist or can't exist or names that are unqualified and domain names with got Mars as the top level domain, I kid you not.  There are several hundred certificates issued for the fully qualified domain name, local host.
		So, whenever we make a secure connection, we rely on none of these 200 to 400 to 650, to 1500 entities ever making a credit card mistake, which they never make.  Sounds good to begin with.  So we got a perfect system, that has one little dependency in the middle, that makes it completely imperfect in every way.
		So, this is just an implementation detail, right?  We fix cryptography.  We just need to somehow institute a public key infrastructure, and exactly who are the providers of keys, and who issues what certificates to whom and what their standards are.  That's really an implementation detail.
		Except that the implementation details are the whole business here.  Start to end.
		Different people have different expectations of what a certificate means.  Different people have different expectations about when it's appropriate to issue a certificate.  I may think it's okay to issue an E V certificate if you've been following me around for the last couple of months and you've vigorously done a background check on me.  Some people think it's okay.  Some of those 200 people that are responsible for issuing all the certificates, might think it's okay to delegate the awesome all mighty power of every connection na occurs over the internet, to somebody else.  Somebody who is completely undetect able by everyone in this room, by every user, by every browser, vendor, by every web site.  Someone who, whose identity is unknown, can have the awesome power to disrupt every secure connection on the web and net, and just by one of those 200 people delegating their authority.
		In addition, different certificate authorities live in different places with different norms, different cultures.  Some think it's okay to issue certificates to governments to in September the entire internet.  Some think it's okay to intercept certificates to companies to intercept, the company.  Some think it's okay for a particular domain or set of domains.
		Some people don't think that's okay.
		But this is just an implementation detail about who thinks which certificates are okay and when you should issue them.  So it's not going to disrupt the entire system, right?
		Well, the problem is that this principal, that I'm sure no one has ever seen before, pervades the entire system.  If you're a browser, you think, well, I know what a certificate means, I'm going to make my security assumptions based on that.  If you're a user, you know what the green, or blue address bar means.  I'm going to make reasonable security assumptions.  But users don't know the phrase user security assumption.  But if you may have a different set of assumptions from that group of people.
		So how do we fix it, how do we deal with certificate authority mistakes?  How do we in particular deal with mistakes from very large certificate authorities.  Right now, those who are the ones who provide the list of trustworthy C As, have only one enforcement option.  The trust model says that a certificate is either valid or not.
		So, to enforce the trust of a route, the route is either trustworthy or it's not.
		So, let's imagine a future in in which one certificate authority that controls the vast majority, or the vast ploor ral tea of certificates on the internet that are used for the vast plurality of web sites were to make a mistake.  Were to make a massive mistake and accidentally post their public key, their private key on the web.
		Highway would we deal with that situation?  Distrust is the only option.  And if distrust means that all of those sites, all of those other internet services that rely on this particular route suddenly stop working, especially, if they have a really secure system, like H S T S that says if it's broken, it just doesn't work, this is a really difficult problem and I'm sure you'll be happy to note that I do not have the solution yet.
		Thank you very much.
		
		(Applause.) 
>> Chris.  Hello, everybody.  I'm Chris Weber, I would also like to thank Hannes for inviting me here today.
		I'm going to just bring it back around.
		And remind everybody that the topic is about implementation challenges in web browsers, and one of the things I like to focus on in my day job is breaking web am applications and breaking web browsers.  All in good sport of course.
		And, sort of the problem statement of this presentation is, there's a sosht of counter intuitive transition period, we talk about the transition period sometimes, about the lag time when we're implementing new security features that are good but we still have the lag time where people need to catch up.  Well, there's also the transition period that sometimes those new security features can turn back to fight us and actually booit us in the buts and we'll byte us in the buts.  So we'll see some examples in this presentation.
		One of the other things, you know, that I see a lot of, is just how complex kurt is getting.  And I'm speaking from the perspective of the application engineers and the designers, the people who are building applications and all of the infrastructure that exists.  I mean, you pretty much have to be close to a rocket scientist to get it right these days.  There's so much to think about in terms of all these moving parts and pieces.  You miss just one little thing and it could compromise the entire operate. Operation.
		So just some examples of some things you have to think about as an application designer, this is just a subset of some of the security mitigations that exist, in protocol and standard form for us.  Everything from same origin policy, which was luckily just defined for us last year, and it's been this enormous topic and obviously, the center of the web security model since the beginning of time.
		And everything that falls across the standards bodies, everything from I frames and cryptography existed at multiple levels, we talked about the transport level and there's cryptography, and there's cryptography on sessions and a lot of places that it applies inside the applications.
		So just to get your head around all these things, all these mitigations that exist inside the web browser, and the features that it can provide us, and knowing where to apply those is a challenge in itself.  X frame options, where do we need to put that?  Every single page or response that comes back toll client or in just a subset of those, and what happens if we for gelt to put it in one place, is that going to compromise our entire application, and is it worth the over ted to do so in
		And then, you have to think about when the, when new features roll out, how are they going to inherit that model that was already there?  Are they going to know that this protection also needs to come along with their new feature?
		So, web applications have, are in this position where, their biggest client is out of their control.  The web browser, they have no control over it, except for the Code they run inside of it.
		And not just that, but as an application engineer these days, for a big site, or a big provider, you need to basically build your applications to support everything that's out there.  So you're talking about multiple versions of Firefox, internet Explorer, chrome, safari, running on P C, running on the Mac.  Running on smart phones and tablets and you have to get all of the security pieces right in all those places.
		So just as an dpam pel of one of the transition painks.  Facebook was compromised with cross research sharing.  XML http request was the impetus for web two point O.  That's what gave us Ajax back years ago.  When http http request was first rolled out and it had bugs along the way, but basically the origin model, the security mode el for it.  XML http request will on make requests to the site that invoke it.  It will never make across origin request.  That all changed with cores.  Cores, because web application developers, have been matching up and getting around the restriction for years, it became a better idea, and it really is a better idea to standardize that to something that's secure and reliable and robust.  And that's what correspondence is.
		The problem here, with this Facebook example is that it caught some people off guard.  So Facebook had the application, you can see by the URL here, they would take everything after the fragment, in this case, profile Dot HTTP.  And they would take the content that came back from that page and mash it up so you could come here and get your profile information and your instant messaging information.
		At the time that was perfect, because there was no threat of this page making across origin request.
		When that browser started implementing correspond, this is an example of the feature that did not know that this was going to happen to them, that the new feature was going to come and byte them in the but.  And that's because, I mean, quite honestly, application engineers and developers don't really care about standards that much.  They're just building applications and features.  They're into the paying attention to all the things that the browsers are doing and all the new standards that are emerging.  So when an attacker can now change everything after the fragment identifier, they can load up their own script and code inside Facebook and control at that point the user's browser.
		So, HTML five introduced a huge number of new named character references.  Here's a quote from Mario on Twitter.  Where he's basically saying that he was able to own compromise a web application fire wall, and also an HTML sanitizer all in one shot because of this new name character reference.  This is an example of cross site scripting, which is a way for attacking to attack malicious script inside of a page.  Being possible because for years, everybody in an application engineering would treat hyper links in their code asthma lish shus and hopefully not trust them, and java script colon alert is obviously one you don't want to allow to be input into your application unless you're the one providing it.
		So if it comes from an attacker, usually an application designer will parse everything up to a Colorado long and make sure it's an http or https link and then accept it or reject it based on other parameters.  In this case, they were bypassed because of the ampersand and name character reference being equivalent to the colon.  Photograph
		In line S V G was opened up as part of HTML five and Firefox and I believe chrome implemented support for that.  And huge sites like WIKI pedia had S V G for their images at the time and they didn't really, you know, pick up on this new feature being rolled out.  So suddenly the massive sites became vulnerable to attacks, which is intended scaleable vector graphics, but it also supports a lot of running code inside that graphic format.
		So just to sum up, some of the root causes, some of these issues, implementation quirks across the on browsers, Firefox, chrome, I E, everybody implements things a little differently, especially the things like URL handling and the way they're parsed, the way that post message might be treated XML is treated and headers come down.  X frame options have different implementations in each browser.
		There's API security considerations that are well documented by the standards groups in some cases but are more than likely not understood by the application engineers and developers.  And of course there's in in interoperability problems.
		And there are simply two flags, deny or allow, same origin.  And the standard will bring in an extra plaing that will say allow from, where I can say, I'm Facebook dot-com, but I also want oo to allow my page to be framed, you know, by Microsoft dot-com.  And so in the meantime, engineers developing those applications have to deal with the limitations and they'll go for whatever they need right now.
		And then the final root cause is this counter intuitive transition pain when we're turning out new standards that might not be so obvious.  
>> Thanks, Chris.  
		(Applause.)
		
>> So, a, I don't know how many of you were at the IETF back in Hiroshima, I honestly don't even remember how long ago that was at this point.  But we first brought the web socket protocol to IETF many years ago, at a happy little BOF in Hiroshima.  And we just finished it up recently.  It got published as RFC 6455 and I wanted to share a few lessons learned as it relates to new features, browsers and security or as I like to call it, the world is accrual accrual broken place.  My name is Ian Fette and I'm one of the authors on this spec.
		What I want to talk to you about today is three main areas that we found, especially problematic in trying to bring forth this new protocol into the browser.  So just to really quick overview of what web sockets is.  In traditional client applications you can open a socket to your server and send and receive as much information as you want, life is good.
		This is well understood by everybody who writes and sees java.  But on the web you don't have this nice API.  You have all this weird framing and UTF eight encoding and base 64 encode that again.  And it's messy.  So we thought, hey, let's bring a socket to the browser and allow one single TCP connection and life will be good.  And we hit three main areas of concern.  One was there's all these assumed security boundaries that exist that are not necessarily documented anywhere.  And if you violate that, many people get very mad at you.
		There's cross protocol attacks, so people who, you know, don't really want anything to do with web sockets but all of a sudden web sockets make these protocol vulnerable.  And of course that's a problem.  And this leads to, its own set of interesting error conditions.  Error cases.
		So, let's talk about about security boundaries.  These things exist.  They are out there every day.  But they're often not documented.  The most common assumed security boundary that we run across at least in corporations is the notion of having a an intra net.  They say if the request is coming from a sub net computer or behind the fire wall, however you define local traffic, we assume the request is good and nothing bad could ever come from it.  We'll give out the pirt treasure map that shows where all of our gold is stored.  So the interesting thing that changes with web sockets, is we're now letting a third party open a connection from your browser, so the way web sockets works, you download some java script from let's say example dot-com, the browser parses it.  And please open a connection from X pel dot-com. 
That's probably okay if it's talking to itself.  But it could also say, please open a connection to WWW Dot korp Dot corporation dot-com where it's an internal host name.  Since it's coming from your browser on your computer in inside the local network, it appears to becoming from a trusted source, instead of example dot-com.  So this is violating one of the assumed security boundaries.  So we need to make it clear in the web socket world we found we need to make it clear where the request is actually coming from.  So we added in the origin header which is defined in RFC 64541 less than sockets.  And so you're on a web site, example dot-com and they say, please open a connection to korp or internal korp dot-com.  That connection to internal Dot korp dot-com will say example dot-com.  -- I'm losing it. 
The ne tern national server knows where it's coming from and it can choose whether or not to allow the connection.
		So this is sort of, the general principle here is, we needed to respect this implicit security boundary that's not documented anywhere.  People want to know where the request is coming from.  The you're an API server and you're handing out stock quotes, maybe you don't care where the request is coming from.  You you're happy to service everybody.  But if you're an internal service, you need to know where the request is coming from.
		The second class of attacks that was opened up is cross protocol attacks.
		So you might say, great, you've got this origin header and somebody who understands web sockets can check and see where is this request coming from?  Is it coming from my corporate web server or some south outside third party?
		But what if my web server doesn't understand web sockets.  What if it's not what's being targeted.  What if the attacker is trying to open my S M P T server or choose whichever service you might want to attack.
		So the initial approach that we took is, well, we said, we want to make sure that you are only talking to a web socket server.  If you can talk to an S M P T server, you can potentially send out lots of spam.  So the proceed tow typical example would be, you buy an ad on an ad network and you have that add kenkt to the user's ISP S M P T server.  And again, they assume that because you're coming from an IP address of that ISP, you are allowed to send out mail.  So if you could host an ad, that would open a web socket connection to a major EUPS, you ISP, you could send oyt as much spam as you want.  That's not good for a browser vendor.
		So we wanted to make sure you're speaking to a web socket server and we had this convoluted proof in web sockets because we couldn't figure out how do you prove this in a good way.  So we have something that's a challenged response.  The web socket client, meaning the web browser, sends a key that then gets hashd with a sort of magic key that's only defined in the web socket spec and that gets sent as sort of this yes, I'm willing to accept your connection response.  We wanted to make sure that a server that was just blindly echoing out whatever it received wasn't getting trickd into accepting a connection that it didn't know what it was.
		So it's one of the more unfortunate complex parts of the web socket spec, but this lets us feel reasonably good that we are only talking with web socket servers when we initiate a web socket.  So this helps protect all the other protocols, like S M P T from malicious web socket requests.
		But it turns out there's another problem.
		And the problem is that there's lots of infrastructure out there that may happily pass on your request, but then still try to interpret it as if it were an http request.  So, I've been told by many people I shouldn't bash proxies, so, I don't mean to, proxies are good.  But web sockets uses the upgrade mek miss mechanism.  So you can say please upgrade to some other protocol.  If the server accepts this request, the connection goes from being http request with http semantics to some other protocol that is defined elsewhere.  It is no longer an http connection with http semantics at that point.
		Unfortunately, some proxies didn't seem to get that memo or they didn't read the RFC completely and so they will continue to try to parse the request, as an http request.  This led to some really interesting attack vectors.  One of which basically lets you suck data out of a corporate internet.  And the other lets you poison caches.  So how does this work.  You open a server, take out an ad and say please open a connection to evil dot-com.  The proxy sees a connection to evil dot-com.  Hands the connection to evil dot-com and evil dot-com now has a buy direction national communication channel with the browser.  So then it can tell the browser, please send something that looks like a get request, and send this to, let's say, internal Dot korp dot-com again.  And some proxies will see the request and even though it's after an upgrade, they're still trying to interpret it as http. 
So they send out the request and the attacker puts a host header on the request and they'll say, please send something that looks like http get request for korp Dot internal dot-com, and so it has that header.  Some proxies, rather than using the IP address will use the host header, so they will then happily fetch the, because they're interpreting this as if it were an http request, they will fetch the data from korp Dot intern internal dot-com.  Which is now eve able to essentially use this as a tunnel through the fire wall to get data from our internal server.  This is bad.  But it turns out there's another fun thing that you can do that's potentially worse and that is, you can make an http request that looks like a request for, oh, let's say the Google analytics java script which is on a very large number of sites.
		And about two percent of deployed proxies out there would again interpret this fake request as an actual request, and to be super helpful they would cache our response.  So you get the connection to the evil server, the web connection osocket sends a request to the Google analytics, and it returns something that looks like a response to the request and the proxy happily caches this so that everybody else who is now behind the proxy, rather than get ting actual Google analytics script, they get your malicious java script and you can compromise a very large percentage of the internet for about point two percent of users which is a very large number of users.
		How do we prevent this?  Well, we decided the root cause of this problem was the attacker being able to send something that looks like a valid http request.  Shouldn't be a problem, but the reality is, there is deployed infrastructure that's buggy and it is a problem.  So we have mask tion, wherever time the browser sends data, it first picks random knots and puts it at the beginning of the data and Xs it with nonce.  And it picks a fresh nonce and Xs everything.  So in a properly implemented client it's impossible for the server to control what the client's dpat ta is going to look like in the wire.  If you didn't do that, it would pre compute what it would look like http request again.
		So again, web sockets has this thing called masksing it was contentious in the working group but it lets us avoid the deployed infrastructure problems.
		Stepping back, and generalizing, what I took away from the web socket experience, aside from some gray hair, was to consider, No. 1, we are deploying into an environment that does have existing security assumptions.  These may be in an RFC, they may be be just lower than everybody accepts, you have to accept these and figure out how to make your new protocol work in existing set of assumptions that people make about security.
		No. 2, there are attacks that have been possible that people learn how to guard against.  But your API may open up similar attacks that are just different enough that people haven't thought to protect against them.  So you need to protect the existing infrastructure against new attacks that are enabled by your new protocol.  And finally, this is sort of a sad depressing point to end on.  But the lowest common denominator really dictates what we can do to new protocols that have security impacts.  So, thanks.  
		(Applause.)  
>> Hi.  I'm Jeff Hodges and I'm also very pleased that Hannes invited me to speak.
		So, given everything that we've talked about here already, I just kind of wanted to up level a little bit, yes, there's lots of issues and such.  And the world is changing really fast, but it's not the end of the world.
		And in the big picture, there's all these non trivial issues, but if you think about where we've been in the past, things are getting better, you know, slowly but surely, we're chipping away at things.
		And, I kind of wanted to take a digression off to the side, just for a second, what we've talked about here.
		Is a key thing to remember about a browser is, it's an execution environment for mobile code.  All this stuff that you're sucking over the net, back to your browser, is not just a document, that just gets rendered and sits there stat klee and doesn't do anything.  You know, it's code.  It runs, it can change things, it's self modifies and opens other connections to other things, like Ian was talking about and can do all sorts of crazy fancy things.
		And, to that extent, you know, browsers are in execution environment, a container for this mobile code.  And when we're talking about this problem, it's key to remember that, when somebody says, example dot-com does this, it's not the server over here that has this domain example dot-com, it's this chunk of stuff you suckd over to your machine, that example dot-com gave to you and is running on your machine doing things.
		The frov dense is important, and where things are running and it can be confusing a lot of the time.
		So ten years ago we had one hugely dominant proprietary browser and it was typically being run with all these proprietary plug-ins and they had all sorts of vulnerabilities in them, and in these things were not getting updated very frequently.
		And, we had just this huge attack surface.  And all sorts of crazy things were going on, not to say they aren't today.
		And today, and in the near future, we're in a multi browser world.  There's healthy competition.  We're converging on open standards.  Plus inless browsers and perhaps branching out towards quote unquote desktop browsers.
		And we have this thing, a new term, and security model restriction frameworks, which are some of the web policy, web security policy stuff that we've been working on, and that to some degree is deployed already.
		And just to dive down into some details, there's in the multi browser world, again open standards base, some are even open source which helps get more eyeballs staring at things and like I said, there's robust competition and there's this trend towards really rapid fixing and updating.  Problems can be found and in some cases, within a day or so, fixes are being distributed actively to people's devices.  We have this emerge gent open web standards constellation or family.  Often it's given this label.  HTML five but really, it's the ongoing HTML five work plus all sorts of other things that are emerging in concert.  And HTML five has built in notions of audio video images and such were not running with plug-ins and all of this is receiving open multi party scrutiny.
		In the security model restriction frameworks, what I'm talking about there, is things like content security policy and frame options.  The https work that's going on here, core, cross over, resource sharing and O auth, different ways for web applications to communicate with each other in a more secure fashion.
		Yes, there's issues.  We're in a transition period.  There's existing web apps that are, you know, there's a period of time where we've, you have to upgrade them, and to these new under pinnings and if you don't as has been talked about here, you may be exposing yourself to some problems.  And shux, as we're putting new stuff into complicated things called browsers, there's going to potentially being issues there as they evolve.  But overall, things are getting better.  As compared to where we were ten years ago.  Certainly.
		The attacks surfaces is argue ably starting to shrink and as a way forward, we need to accept and understand this transition dynamic.  Everybody here has mentioned the word transition.  We'll always be in transition.  But it comes in waves and right now it's big, and hopefully it will narrow down in a couple of years.
		But we need to be cognizant of this and factor it into our design implementation and design practices.  And practices applies to both under pins and web apps where under pins are the server environment, the proxies and deployed infra 12RUBG9 tur that all this is running on top of.
		So that's basically the high level viewing.  Back to Hannes.  
		(Applause.)
		
>> So, that's the end of our speaker list, so, I think it's a good time to open the microphone.  And I think we welcome questions not only for our panel members but also if there are questions to the previous presentation, how do we do that?  
>> Let's just wait on the IAB questions.  
>> Okay.  For the IAB questions, we have them at the end.  Okay.  Marshal.
		
>> I guess it is.  Okay.  I just -- 
>> Who are you.  Marshal Eubanks.  Thank you very much.  I might point out there is an evil dot-com.  And while they might like being promoted in the IETF, I don't think that was the intention.  Evil, Dot example dot-com, sorry.
		
>> Do we have other questions?
		Come on guys.
		
>> See one person walking over.  Shawn.  
>> Hey, Hannes.  It's Dan York.  This is, you know, 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.  
>> Thank you, can you somebody take that question?  
>> What's changing with the mobile phone application work compared to the browser.  
>> I think there's a few things that change from a protocol level and use ability level.  One, from a protocol level you have to remember that, mobile typically has much higher latency.  So if you really want to do things like S SSL write, you do revocation checking before you do the connection.  But it's hopeless, if you try to download a 20 mega byte, if you wait for a response, you're adding at least about a second of latency on there.
		So, there's protocol challenges.
		Then the use ability challenges of the user interfaces are you know, 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 you know, 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 sort of user interface level.  
>> Yes, I would add to that and generalize saying that mobile just makes you notice all the way that you've been lazy on the desktop.
		The network sucks, the screen is small, the 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.
		
>> I would come back to that, but, the mic lines got dead.  
>> This was 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 vulnerable abilities.  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 and I'm wondering whether that's been coming one of the lowest common denominator, or whether you see this as a completely separate problem?
		
>> So, with all mobile operating system, we're trying to fix that problem.  By having mobile applications be basically web pages.  So they can have really fast update cycles with really little overhead.  
>> I think part of it though is on mobile, you do have, so, I think, if I can basically try to restate your question to make sure I understand it.  There's a lot of applications that just wrap something like a web view and they don't seem to get updated frequently.  
>> Right.  They're basically static 
		(Several people talking.) 
>> I think regardless of whether you're talking an application when is web view, such that when web view gets updated, whether you're talking about that or just the web page run oing the mobile browser, it is the fact that browsers and the browser, sorry the platforms they run on, so the equivalent of android or I F S.  You're at the Mercy often of either carriers to pick a new version or you're at the Mercy of the company that's providing your operating system to push it to all the users and this has significant costs especially on mobile, there's a a cost to push out the large updates so it doesn't happen as frequently as we like, and 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.  
>> And so, you don't separate the stuff that, on a mobile phone, you have to at least two possibilities to run the applications, one is native application which has a very different security model, it has the sort of permission based security model, versus a sort of web based sort of like a web browser that just has a different groom so it runs regular web pages and those are very different.  So do you see the direction going away from sort of the regular web usage to something mobile, the native application space?  Or do you see a totally different.  Because from a security point of view, these sort of details matter, also from an update point of view.  
>> As I say, on boot to gecko, our mobile operating system, all the applications, it's just a bundle of HTML java script and H T MS.  So we definitely think the future is in just having web aps, you can cache them and we need some sweet APIs to do all the stuff these devices can dochlt but I think the appropriate security model in the future is web apps with smart A P.  Is that are enabled through good preference management.  
>> I'm going to take a practical view and say I think we see a bit of both, especially on platforms like android and I O S, you see essentially HTML in a web view.  They both have pros and cons.  And whether it's a native app, they're both technically native app, whether it's written in java or objective C or a thin native wrapper around it.  You still have 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 know, the java or objective C, you're talking about what with version of the java run time am I dealing with?  Does this version of java support S N pt I?  Does it support new things that we're trying to do to SSL, things like, if we want to make any changes to the handshake to indicate what sort of protocol we swant to speak? 
N P N that's not going to be supported on the mobile device.  You're stuck with constraints.
		I'm not sure if this mobile versus desktop issue in particular, but you know, one of the things that, that's been come apparent, if you look at sort of ank droid versus I O 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 I O S app, Steve liked it I guess it's okay.
		So, which is much more like, (Inaudible) and you're on your own and you download stuff and nobody is curateing it and telling you what you're supposed to do and not supposed to do.  As I said, 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, I have 
>> I have a two part question.  The first part is, there's some discussion there on the number of people you're trusting in these route trust lists that are inherently in the major browsers.  And you know, I certainly understand that some of the traditional C As are issuing certificates to enterprises that allow them to masquerade effectively, to any, as any other web sites, so they can do inter exception 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 vendor should do about this?
		
>> We have seen a non zero number of these that have been used in practice, to essentially man in the middle connections.
		As for what we should do about this, you know, our first step has been to, there wasn't, believe it or not, we didn't actually have a clear policy saying it wasn't okay, so No. 1, we now have 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 time lines for remediation.
		In terms of what happens if we see it again in the future, I'm hopeful, we'll be able to say, here's our clear written policy, you have violated it, we are going to now take a harsh err stance.
		
>> I think one of the problems is that we only have one size stick.  And that stick is really big.  And we need to work on developing smaller sticks, with which to beat certificate authorities when they misbehave.
		
>> I think it's clearly not okay.  I don't think there's much debate about that.
		So, 
>> You should talk to certificate authorities more often.  
>> I realize they think it's okay.  But I don't think, I'm not aware of nir 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, to the extent to which, for N S (inaudible) block certificates easily as opposed to whole C As.
		You know, the core problem in dealing with this obviously is, you're the st, you have a huge stick to make the C A do what you want and it's expense sivr.  And the question is, can we offer them something better than that that we want them to do, right?
		
>> Okay.  Bill.  
>> My name is Bill mils.  Comment on this.  If the C A 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.  
>> Apparently some actually did market it.  
>> Lovely.  
>> And some 
		(Several people talking.) 
>> And some still do.
		Until very recently.  
>> We're looking forward to you know, 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 server side, from the web server side, you, 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 cuvt out there?  What can we do systematically about that?
		
>> When you see I E six, tell them to install something better.
		That's really anything.  Just to clarify.  Most mosaic.
		
>> 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.  
>> Jeff, I guess my brother doesn't read your CT O blogs.  My brother doesn'tn't read those apparently.
		Okay.  Shawn, and then Russ.  
>> I have a quick, Shawn Turner.  I've all for EKR's statement.  So the question is, how do we get browsers and servers to actually implement the later verses?  Is there something more that we should be doing?  
>> Browsers and clients.  
>> The hardest part is not implementing, the news version, but yes, we have been slow.  
>> TLS point one.  
>> The hardest part to be honest is actually turning off the old ones.  So two weeks ago we turned off on our tip tree, we turned off our C 4128 with M.D.  Five.  
		(Applause.) 
>> You can klach clap but we actually turned it back on.  Sorry.
		
>> So 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 sip err suite.  
>> It's really fast.  
>> 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.  
>> So we should Colorado Colorado lud on that.  turn kol lud on that.  And turn it off at the same time.  
>> And access of web application providers or web application services depend on third parties such as their TLS concentrate tores, and are waiting for those guys to implement.
		
>> Okay.  
>> So I want to tell you a story about a protocol, we, with a known defect.  Which is, the initialization vectors for the messages were predictable because they came from the previous message.  And (inaudible) ex exploit the defect in about 2004.  And the working group duly supplied a fix for the defect but it didn't seem (inaudible) and then, earlier this year, I guess it was late last year, somebody discovered a substantially better ex exploit.  And by the way, unfortunately people didn't actually put it in their code so it was a substantially better attack vector for this.  And I know that N S S is (inaudible) completely up to date.  
>> Russ.  
>> Hi, there.
		So, 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 Russ Cal 11, I'm an IAB member but I'm speaking today solely as an individual.  And I'm concerned about the complexity of our security solutions, and whether they sort of address the issues.  And to give you a couple of examples, you know, while I'm talking as an individual, I happen to be an IAB member so from time to time I go to the IAB web site.
		Every time I go to the IAB web site, I get a warning, the security certificate presented by this web site was not issued by a trusted certificate authority.  The is 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 like, not in our industry.
		
>> Agreed.  
>> As another example, I happen to know somebody pretty well, who is head of some sort of a health care agency.  Okay.  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, and gone in and talking to the IT person in their company, multiple times, and you know, they take her fairly seriously since she runs the agency and they still can't get it oto work.  So I think this model, when authentication fails, you never send any information, because you're assuming the person trying to log in is an attacker, causes people like real agencies, not internet stuff, to not be able to use the internet, with the result that they lobby to turn it off.
		And 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.
		The other, another thing that concerns me is, you know, 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 ease stern 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.  So I think I have to believe that the stuff is not secure, even if I'm using a secure web service.
		And finally, of course I've heard of denial of service attacks, in the tens of giga bits.  And you know, 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.
		
>> I think you raced about ten problems.  I'm going to take sol list 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 becoming back.
		We do have devices that are doing verified boot and maybe you will at some point in the future have some level of secure, I don't know what the right word is.  
>> Satisfaction.  
>> At a 
		(Several people talking.) 
>> So I'll be able to get a laptop I can trust.  
>> Yes.  But as far as all the use ability problems, suggestions welcome.  One out of nine.  That's not bad.  
>> One suggestions that I do have, when authentication fails, the Hackers, probably knows why 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 and so the user can go to the IT person.
		Or alternately you can send a notice to the IT guys.  
>> With some risk of denial of service factor.  
>> There's all those issues.  That particular notion was brought up and discussed a little bit today in the web sec working group actually.
		
>> Thank you, Russ.  Actually, we had gotten rid of, at least found client side certificates undeploy able probably for the reasons you mentioned.  That's why we switched to pass words.
		So, stev fan.  
>> Hi, thank you.  I wonder if you can help explain, one thing that bothers me with the web security model, and where you think it's going, and so, 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.  So of course the industry was clever to find a way around that.  Called Jason P.  We address data, ask code and instead so everything that comes from everywhere is addressed as code.
		So, there is a lot of things out there that depends on that functionality, not to address Jason as java script.  And it seems like intuitively, that it is opening up more attack veblingt tors than actually doing anything good.  And also, would there be any change m the future that would shut that functionality down?  Or is there anyway else that that could be straightened out so data is actually treated as data without that limitation?  
>> Jason P is a terrible idea.  And that's why (inaudible) is developed.  In modern browser servers you may not need to do this anymore.  
>> That's not the complete story.  Because jaition son P is the is 
		(Several people talking.) 
>> Without the problem where you have to trust the site.  
>> So you can do cross origin XML requests.  
>> Or Jason.  
		(Several people talking.) 
>> Can you do that across current browsers?  
>> Because I haven't seen any browsers so far that will stop me from doing Jason P.  
>> It's not about stopping you.  Unfortunately it's very hard to take things away.  It's like having little kids, you can give them more toys, but you can never take one away.  
>> So what happened is basically.  
>> You can try.  
>> What happens rather, is that we developed technology that allows you to do the same thing that you can do with Jason P without (inaudible) I'm not aware of any work right now in breaking Jason P.  
>> Just a really stupid question, but wouldn't it be smarter to do it the other way around to force script to come from the same domain but allow data to come from everywhere.  
>> That's what I said in my talk.  That would cause the entire web to break.  
>> Hannes.  
>> I've got a question or two questions from the jabber chat room.  Jon klen son said would somebody like to comment on the consequentes to T A S and C L management, and what's happening.  Hundreds of new T L Ds some with scripts that get rendered as question mark, question mark, question mark.  Anyone care to play?  
>> Really?  
>> I don't think having a lot of T L Ds changes anything.  I think having a lot of question marks creates a problem for Ian.  
>> If you look at sort of the lowest common denominator practice, you look up the who is 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 from with the what do you display and can the user understand that PayPal Dot on line business is not really the PayPal that you're looking for.  And most likely you should register that by the way.  
>> Already did.  
>> 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.  
>> The second question, also raised by Jon klen son is, -- 
>> So we don't have Jon only talking, actually, Jon.  
>> Thank you.  I'll try and make this coherent.  The comment before about, I'm Jon Levine.  The comment before about mobile brours ers 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.
		So, I saw in some of your fascinating presentations I saw a whole bunch of ways that sort of reasonable features interact to produce bad results.  Right?  Like who would have thought that having an entity for colon would actually being be a security problem.
		And so, we have approaches to limiting the amount of in interactions tla are going on.  Sand boxing, trusted computing hardware if, 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 question at bar gel bar gel okay.  To which the answer is always yes.  Apple's, 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, any hope for security model that actually manages to limit the, you know, limit the damage while still providing enough access to what's inside the box, to produce useful applications?
		
>> 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.  
>> That sounds like double gar gel.  
>> But from the application developer side you've now got two tochlt N possible, perm mutations that you may have to deal with.  So, 
>> That's pass able.  
>> It's tough.  
>> Yes.  
>> 
>> It's obviously a really, the crucial question.  Like do you want to have, support all the innovation we have seen on the internet, with sort of a very open model where everyone can essentially no barrier of entry, write new application, 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, Chris specifically pointed out, stuff gets more complicated, users don't understand these permission models, nor, do we, and suddenly angry birds asks for your calendar and many other things and you wonder, why is that, but I still want to play angry birds.  So I don't have an answer to that.  
>> Either the users has to understand what's going on.  
>> Which they don't.  
>> Or else you delegate the validation to some third party who you may not trust.  And you know, which, we've been going in the rat whole for decades.  I'm wondering if there's a rat hole that's less deep.  
>> As the saying goes in the security industry, there is no silver bullet.  
>> I was hoping for a led one.  
>> So, 
>> Any bullet will do.  
>> 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, these sort of things 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.  
>> Thank you.  
>> Let me jump over to Peter, and then come back.  
>> I came in rather late so I would defer to others.  
>> So, okay.  
>> Yes, let's -- 
>> Jon.  
>> Dan York channeling Jon from the jabber wrong.  He asks if a C A has issued a certificate for example Dot Mars and ICANN cells Dot Mars to somebody, do we have a plan?
		
>> So, one of the problems is that, it's not just example Dot Mars.  It's anything that's an internal host name.  So C A could sell a certificate for, you know, server Dot local.  Or server Dot Microsoft.  
>> And they have.  For server Dot local.  
>> And these will invariably get sold as you point out.  So 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.  So, couple of things so far that have sort of run right up to this edge of cliff but then backed up.  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.
		in in fact, when I got up, I was going to say something very similar to what he did.  And 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, does 7b89.
		There's fundamental quality of fingers in the dike to the kind of work that's done now.  And it's excellent fingers, trying really hard to do a good job, but, I listen to three or four of you, I guess four of you get up and give rather unpleasant news to us, which we may or may not have already known, but in fact, it's not news.  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, which is also true, the only problem is, 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, but 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 inform make better is the wrong model.
		
>> I understand what you're saying to be, we're starting with sort of a fundamentally flawed things and making incremental improvements rather than a more sound model from the beginning sp?  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 approve able sound base.  I just don't think we can throw out the whole internet like that.
		
>> Well, it's such a limited view -- 
>> Sorry.  
>> He's not suggesting that we throw out the whole internet.  Just the whole web.  
>> No, just the 
		(Several people talking.) 
>> And 
		(Applause.) 
>> And maybe another way to look at this, Dave, also, is you know, 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.
		And we need to look at things kind of as probable list tick.  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 rs in the services that are provided over the net.  And people are making a living at it also.
		
>> There is an argument that the primary reason for that is not because any 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.  
>> Yes.  I've actually used that argument in discussion sometimes.  
>> And Dave, I think it's actually the economics of the good guys too.  Because we've already heard the C As are keep issuing certificates because there's money in it.  And Peter is, I'm juming ping in.  And Ian is saying, we want to shut off the cipher sweets or people complain too much, which equates to money.  So we need to look at the economics here very much so.  
>> Yes, thank you, Peter, that was a good remark.  It is certainly difficult, as some of the speakers had pointed out, you have an existing web application, whether you have an existing landscape, you have to work with.
		Of course, it would attempted to say, let's start from scratch and re design everything and make it better.  But that, for many is not an option unless you're working in a research project.
		And, so that's some hard play ground and so these guys are working with others in the IETF and the W3C and various groups that have been created not too long ago.  The web security group was created a year ago or a little longer.  And there's a counter group of W3C and we have cross participation to keep track of what's going and and make sure we react quickly enough to some of those developments.  But it remains a challenge.  
>> What Hannes is saying, we have a lot of very organized fingers.  
>> It's (inaudible) from Amsterdam.  I want to also comment on security in internet.  We at least try to solve the problem of greed security, (inaudible) we discovered that the internet security model, using the client server model is actually quite limited.
		Because, it uses, so called client service, server security model.  This open system inter connect.  But actually, I remember that two gentlemen mention about trusted computing.  Model.  Is from Google and from Mozilla.  And that, but I could not understand how deep you actually refer to the trusted computing model.  Because this is reference monitor concept that is kernal built operating system and if you try to solve this problem like executing in mobile remote, but actually it has some similarity.  But you can actually cannot just directly use the same concept session and identity that you use in exchange like web browser or client server.
		The same with, with when we develop in the cloud security model.  It's utilization of security model of utilization environment.  And trusted computing platform is actually can give a good idea how you can track all this check intersession, identification, and all this context for security.  That actually creates consistent and end to end security.
		So, 
>> So for us, -- 
>> So my understanding, that IETF is developing security model need to look wider.
		
>> That's actually operating system we shouldn't be using anymore.  
>> For us, I think we've taken the trusting computing, 
>> We're having a trusted, a TV module, load verified boot which then loads a verified browser.  We haven't taken it to the point of doing remote of the service that you're talking to.  
>> So someone like, a streaming video provider 
>> Somebody might want tow know you're a web browser that represents a 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 sou do you do a das station that doesn't provide a fingerprint of me across the web.  So we've looked at T C to the point of getting a known good operating system and browser running, and doing, starting to explore how we do a das station to a third party.  We haven't looked at combining a das station into third party environment back into the client environment.
		
>> Yes, this is actually the way in which we also move in our research.  Using trusted platform, insure integrity, and after that, incession, you can protect the session based data and privacy.  
>> Hannes, I wanted to pop back to Dave Crocker's point on the bad guys and stuff.
		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 stuff and there's financial money flows, well, 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.
		And there's people particularly stev fan savage at University of California San Diego, are doing research on tracking down the money flows that are behind that nk figuring out how to shut them off.  And they use technology to figure out who their acquire bank is for example, and putting pressure on them is not a technological problem.  And they're actually seeing some success in their results.  And it's quite interesting and something to keep in mind.
		
>> 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.  
>> And stev fan is merging the two.
		
>> Yes.  
>> Ben dikt, freelance err.
		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.
		Or in other words, we've seen a lot of crypto systems that were considered secure to be broken but we still have to see somebody prove that weak crypto systems are actually stronger than we expect.  So we have a fundamental problem here the way we think, and we should really keep this in mind.
		Unless I'm totally mistaken, in Germany, we've had a problem or we do have a problem, whatever.  We now have identity cards, national identity cards that you can get, certificate with, chipping with them.  And this certificate is secure.  By law.
		
>> That works?  
>> Yes.  It does.  If somebody messes up with your ID card and doing 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 prove able to be safe.  We know even, less about our implications and well then complaining about users being too stupid to use them or politicians, doesn't really give, well, it's sort of unfair, because we have our problems and our, 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 swampd 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 get negative security impact from using them.  So, 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 Dee, to do denial of service attacks against https server 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 expecting it to try to decrypt things.
		If you do things in plane 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, whatever, strong crypto is not always the easy solution it may seem.
		
>> I think the only thing I'll say to that, I mean, you made a number of points, but the one about crypto may not be as strong as you think it is, we have cipher sweets that we no are not strong and we know are broken but we cannot turn them off so that makes me even more Dee expressed 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.  
>> Actually, go ahead.  
>> So actually, I sort of, I'm not sure I'm entirely convinced by your argument about things not being as strong as we think they are.  I think, you know, obviously, you know, things change but the history of the (inaudible) are remarkably encouraging.  So even the algorithm you were just siting, is relatively weak, it's basically no known good attacks on (inaudible) and, so, while people may dance in the number of systems they help if remarkably well and remain long past their expected design life.  So it's true we don't have nawd proof systems but the sukts that they're likely to be weak is not convincing.  
>> 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.  
>> Of course.  
>> Sure.  
		(Several people talking.) 
>> But the issue is, what EKR is saying, is that, the crypto algorithms are not our problems, at least from those talks and also from a workshop we had last Friday.
		So, 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.  But I have to cut the line -- 
>> If your suggestions is 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.  
>> That's not what I propose; but I propose if you travel by car, you drive carefully you, 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.  
>> I'm just going to over generalize what you're saying, pass crypto a little bit.  Because, you know, 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 breakdown eventually, and so we've taken a strategy of assuming compromise and assuming that we have attackers now amongst us.  
>> From an operational point of view.  
		(Several people talking.) 
>> We now need to, we have only a few minutes left.  We need to quickly, and keep your questions short and to the point.  
>> I just thought I'd give some information about that storm surge that hit Google when they disabled that algorithm.  That was point two percent of the servers on the net.
		Plus or minus a little.  R C-5, L C4, with M.D.  Five.  
>> Okay.  
>> That was, that was probably point two, point three, point four percent of the servers out on the net.  
>> Okay.  
>> 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, but you have to weight them by the amount of traffic they get when you do the analyses.  
>> 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.
		And that's bias to word million sites.  
>> Okay.  
>> Max, NYU.  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 crypto graphic 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.
		It's not, let's say that they give up, in, in doing their job, a very fine, in verifying who is trusted or not.  And ultimately the user doesn't trust the C As.  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.  
>> So 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 C R Ls, they're too large and O C L fails.  If you try to hard fail you break the internet.  Also the median O C S P response is on the order of hundreds of milliseconds.  So we do not actually have, I would argue a reasonable revocation mechanism.  We have people trying to develop them but there is no deployed reasonable revocation mek nis many at the present point in time.  
>> We also don't have good trust control systems.  
>> I understand the problems, but while you were referring to especially for C As that don't do their job, actually you control your trust list, which is a mechanism that is like 20 years old 
		(Several people talking.) 
>> That's a great question.  If ver sign does something bad should we revoke the certificate.  
>> If your 
		(Several people talking.) 
>> If you don't trust ver I sign, you will.  Yes.  
>> 
		(Several people talking.) 
>> No.  We, so, 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 all dij note tar would have taken down the taken down the Dutch government.  They said, we have no indication that the other C A is bad.  And they came back and said, we think the other C A is bad.  So take the whole thing down.  So dij gee no tar is still in our list.  (Inaudible) 
>> Important to remember, the problem is not, the people that are being pushed is not just the C As it's the users relying on the certificate issued by the C As 
>> And the developers.  
>> Mic.  
>> Mic.  
>> Actually, there's no queue.  The queue is closed already.  
>> So stop talking.  
>> That's true.  
>> Okay.  So, we have to, so I think you weren't there previously, and so, you weren't either so we are done.  
>> I've been here before the queue was closed.  
>> Okay.  So are you guys finished?  
>> 
>> So I think -- 
>> Take the last question.  
>> Okay.  Yes.  
>> I was here before the queue closed.  wes and I'll make it brief.  The brief point is your marketing department is broken.  And it's very broken because the thing is, all the applications these days end up, getting in these raises and the raises are badly prioritized because what happens is, one mavrkting department says, our X application and everybody knows what we're talking about but 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 ltion to use this algorithm anymore because we get too many bug reports.  And you refuse to say, it's not our problem.
		I kind of wonder, I'm amazed that nobody at this point has started turning off windows fire walls because it shaivs off a few milliseconds to speed up packets to the web browsers.  Somebody needs to say, ours is more secure.  That's where we need to start the raise.  We will safe you from maliciousness on the internet.  And right now, that's not where the focus is.  
>> 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.  
>> No.  I'm talking about everybody.  Because 
		(Several people talking.) 
>> I think there's lots of browsers out there right now that are focused on security.  If you look at even internet Explorer who I used to love to poek fun at.  I E ten is much more secure.  Chrome, we put a million dollars on the line, for our recent security conference, and ex exploit competition that we sponsored.  I think we are doing a lot to make sure that security is a priority.
		And I reject the notion that we're trying to shave off security for speed.
		Not turning off R C 4128 with M.D.  Five is not a matter of speed.  If you break a significant portion of the web, A, you kind of 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.  
>> One last point 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 DNS SEC for every request, because it will slow you know it down.  We will not do extra security because it's slower.
		
>> I think that you include in that statement the assumption that DNS SEC is actually extra security.  
		(Applause.) 
>> That's the second thing.  What do you mean?  
>> So, let's not go there.  
>> Let's go find a bar.  
>> 
>> Is there time?  
>> Well, quick question?  
>> Bill mils.  You had, you 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 cook e ee space and security model in the browser where things are SSL obl only and you have things that are less trusted.  Is there a trade off therein terms of pulling everything into the TLS side or are we, would be we be potentially pulling in things that are less invested into someplace where we had things that were more secure or more valuable, that was it.  Thanks.  
>> 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.  
>> Completely agree.
		
>> Okay.  I guess we are finished.  Let's thank the panel members for their presentations for their discussion.  
		(Applause.) 
>> I'd like to ask the RFC, the members of the IAB and Leslie to come up to the stage and then we'll have our open mic as well as all the members of the IAB including Mary.
		As well as Lars, if Lars is still here.  Come up Leslie.
		Incoming and outgoing IAB.
		
>> R 
>> So the first thing I'd like to do is introduce the new members of the IAB, the incoming members of the IAB.  Jari Arkko.  
		(Applause.) 
>> Mark plan Chet.  
		(Applause.) 
>> And Mary Barnes.  
>> Incumbents, Alissa Cooper.  Joel Halpern.  Russ Housley.  IETF chair.  David committees sense.  Danny McPherson.  Jon Peterson, Dave they'll thail ler.  Bernard Aboba.  Ross Callon.
		Spencer Dawkins.  And Hannes Tschofenig.  Thank you, for the plenary, Hannes.  We will be thanking our outgoing members.  I thought I would note who they are.  We will have our presentation Wednesday.  Olaf, he's not here at the moment, because he's representing us in Brussels, I believe.
		And then an drai robe.  And our outgoing is Dow Street who is not here and we like to thank them.
		And so, at this point I'd like to open up the floor to presentations about any of the IAB report, the IRTF, liesly's world IP v6 day and the RFC.
		
>> Nothing on your mind?  Are you all hungry?
		
>> No questions about RFC formats?
		Bernard, stop.  You shouldn't have said that.  I take that back.  
>> Why do you have to throw the new girl under the bus?
		
>> Because I'm quick.
		
>> Since we have to have at least one question, we'll be asking questions of the audience if with you don't get at least one from you.  Hopefully we have some good ones.  Dave.  
>> I'm always good for a question, whether it's good or not.  Can you, 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 you, what your honest opinions are, I mean, what are your opinions on this?  We're going to all have opinions too, but you know, if we can, if we were doing a BOF and pology you, is there general polling you, is there general consensus on your end yet?  
>> No.  
>> But, thank you, for the question.  
>> Anything else?
		
>> Do we have a question for you?  
>> Excuse me?  
>> Over here.  
>> Go ahead.  
>> I have a question regarding the IAB workshop, you know, we know that occasionally there are some workshops before the IETF meeting that is organized by IAB, suchs for example, that we have the smart object security this time, organized by Hannes.  I just want to know, what's the policy about the organization of the IAB workshop?  I mean, how, how we can make the workshop and things happen with help of the IAB, and possibly, you know, back end sponsor?
		
>> Okay.  That's a very good question.  Thank you.  So first of all, so there was a workshop last Friday smart objects security and I will send the papers and all the slides around.  But I have to say, well there were a couple of folks from IAB and also others involved it was actually not an IAB workshop.  It was just a couple of us thought that we should really get together and talk about this.
		On IAB workshops, and, it's pretty much a community driven approach, as we of course, we are ourselves working in give working groups and we see problems and we need further discussion, other people could say, I could host something because somewhere, we have to get the money from.  So we do this.  So it's very interactive.  So for example, if you would like to host a workshop where you have proposals for topics or anything else and your input is appreciated and of course, it's a message not to, to speaker only, but I don't know where he want, but to everybody else, so if you think there's a workshop topic, 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, sort of workshop is not the only possibility.  Every one of us in the IAB is open for working on documents review, so the IAB documents are, despite the common belief it's not only written by IAB members.  So if you have anything that goes sort of beyond the IETF work, come to us and work with us.  
>> One thing I would sigh is that we have these programs and initiatives which are up here, and we've been trying to get critical mass so that we don't just have a workshop and abandon the topics.  So on smart objects, we've got enough people working on it where there's actually some follow through.  So that's one aspect.  We're looking not just to have a workshop and abandon the topic, but to get a program or initiative together to follow through and accomplish some set of goals over time.
		
>> Go ahead.
		Hi, my name is Andrew Sullivan.  And before I start this, I want to acknowledge my, my part in the responsibility for the thing I'm going to talk about.  Recently, you mentioned at the beginning, 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 ID N labels in the route or U labels I guess we should call them.  I don't want to cast any as spertions on what happened there but the communication went to ICANN rather late in the process, and, I'm, you know, we spent a lot of time working on that.  But ICANN of course is doing a great number of things in the root zone and I'm sort of wondering if anybody has any ideas so we can make sure a repeat of that does not happen.  What happened really 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 in that but I don't know how to fix that, given our own procedures and the way that we are not in sing with other communities.  And I'd like to know if anybody has any ideas on how to do any ideas in the future.  
>> Dave, do you have a comment?  
>> No.  I'd ask the same question.  I'm in the same boat as Andrew.  We have internationalization program, which is where this was originally discussed and then went broadly to the, I mean, it was also discussed in say the in program that we have, IANA program that we have.  And I don't think I have any bir idea that nk do.  Andrew.  So if other people have ideas, we're open to input.  
>> I think we have an open action item to figure out what next.  
>> Right.  Part of the open access item has to do with RFC 1123 which defines the concept of internet host name and there's some language that says it will be alphanumeric only which doesn't allow --  We're already violating that.  And that's the action item now to make sure that gets fixed because the intent is not to disallow -- because the current RFCs can be read but that's not the current intent and 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.
		
>> Okay.  Go ahead.  
>> 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 the, but, it has several obvious advantages.
		My personal preference would be something relatively close to that, like, 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 -- 
>> There's a BOF tomorrow.  
>> All right.  
>> 
>> It's wonderful how I can do this little trick and things start being said out there.  So, 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 one and only one hour for my BOF, 
>> Did we get you a big room by the way?  
>> Yes, you do did.  Not quite this one; it's where, I think it's one.  IPv6 was this morning.  The M A L L the O T room.  
>> It's in the agenda.
		
>> I 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 RFC interest.  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 what my boy friend he said he won't love me anymore if I don't allow text on dumb terminals.  So see you tomorrow night.  
>> Do we have any questions for Leslie on world IPv6 day?  
>> Launch.  
>> 
>> It's launch.  
>> Launch day.  That's right.  
>> Okay.  Yes.  Richard.  
>> Richard barns.  On the v6 launch I've been enjoying the slogans, this time it's for real.  I wonder if you're interested in hiring the proper voice over actor to go along with those.  
>> Interesting idea.  We'll have to take under consideration for an expanded social media campaign.
		
>> 
		( Me M E O W.)
		
>> 
		(Applause.) 
>> Okay.  Any other questions?
		If not, think you're off for dinner.
		
		(Applause.)  
		( End of proceedings.)
		




Page 1