Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/wgig/public_html/igf/website8/web/cms/libraries/joomla/database/driver.php on line 1946

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/wgig/public_html/igf/website8/web/cms/libraries/joomla/database/driver.php on line 1946

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/wgig/public_html/igf/website8/web/cms/libraries/joomla/database/driver.php on line 1946

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/wgig/public_html/igf/website8/web/cms/libraries/joomla/database/driver.php on line 1946

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/wgig/public_html/igf/website8/web/cms/libraries/joomla/database/driver.php on line 1946

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/wgig/public_html/igf/website8/web/cms/libraries/joomla/database/driver.php on line 2022

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/wgig/public_html/igf/website8/web/cms/libraries/joomla/filesystem/path.php on line 143

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/wgig/public_html/igf/website8/web/cms/libraries/joomla/filesystem/path.php on line 146

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/wgig/public_html/igf/website8/web/cms/libraries/joomla/filesystem/path.php on line 149

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/wgig/public_html/igf/website8/web/cms/components/com_fabrik/helpers/string.php on line 264

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/wgig/public_html/igf/website8/web/cms/libraries/src/User/UserHelper.php on line 621

Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/wgig/public_html/igf/website8/web/cms/libraries/cegcore2/gcloader.php on line 63
 Welcome to the United Nations | Department of Economic and Social Affairs

9:00 A.M. ‑ 10:30 A.M.


The following is the output of the real-time captioning taken during the Eigth Meeting of the IGF, in Bali, Indonesia. Although it is largely accurate, in some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but should not be treated as an authoritative record.

Thank you very much. Good morning to everyone, my name is Sebastian Bellagamba, I'm with Internet Society and I'm glad to be here to moderate this open forum, the open forum regarding the IETF, Internet Engineering Task Force. We have three speakers for today. And on my left, Jari Arkko, who is chairman of the IETF, then it's Peter Resnick, he's the area Director for Applications at the IETF, and Andrew Sullivan as a representative ‑‑ member of the Internet Architecture Board, the IAB.

     So we're going to start with the presentations now. We are going to make four presentations and then we drop in for questions and comments. Thank you very much.


     So, I just wanted to start off with couple of slides on why are we all here.

     And, Sebastian, you going to go to the next slide?

     I guess the main thing is that we want to enable this Internet innovation as soon as possible; that is all the wonderful things we have today. Not just those, but the wonderful things we'll have in the future that we don't know yet about. The sort of idea is that it's easy to create new things. You don't have to ask permission from your government, your mother, or your provider on creating something new, whether it's a web page, or a post on a forum, or some great new applications, to create something. If it's good enough, maybe there's a billion users in a couple months or couple years down the road.

So that's the main thing, enabling this communication.

     Sebastian, the next slide.

     So, standardization the Internet way. We, of course, believe in broad input. So this is not some small set of people, a set of participants like only the governments or only the vendors or some such. We actually want to have wide‑ranging input ranging from users to various entities building stuff, and, yes, even governments and other people. We, of course, operate on the principle of rough consensus and running code. We might be able to talk about that a little bit more later.

     We have a document on that matter. So people have been referring to the rough consensus document by Pete. And this week ‑‑ and it's a very good document, I recommend you read it. If you haven't read anything, go to the IETF it's probably worthwhile reading it.

     And openness, the reason for all this is that we want to enable this board to less communicate, support less e‑commerce, support less innovation.

     Next slide.

     And I'm just finishing here, basically giving you a taste of some of the things we are working on at the moment or topics that get a lot of attention today. I mean, there's obviously a lot of different things worked on by the IETF. There is over 120 working groups. But some things are hot topics, include pervasive monitoring ‑‑ by the way, we'll be talking about that a little bit later. And Andrew is going to cover that issue, give you a little bit sense what the technical community is thinking about that topic and how we feel ‑‑ what do we feel that we can do as technical community for the rest of the world on that topic.

     Then there are a couple things we can do. We're also quite a lot working on the web protocol stack. Maybe more the basics are old, but in the last couple years and this year and last year in particular there's been quite a lot of work on the protocol stack. Maybe a revolution, but significant change is coming down the line. So that's interesting. Many things happening right now.

     The Internet of things. Quite a lot of work on that. It's really practical, making it possible to do the Internet to connect new types of link laters, making it possible to use the web protocol stack again on devices and not just human communications. We've been working on putting real‑time communications, phone calls on your browser. That's a pretty interesting thing for the regulators as well. It sort of opens up the market. IPv6 is still a big topic. The basics are done, but we're trying to make it easier and easier for special types of operators to add to it, as an example.

     Not just technical things, but we're also being interested in the IETF to reach out further in the world in terms of geographically, you know, where we visit, where we have meetings and where our attendees come from, and reaching out to new types of participants.

     We used to not think we really need to talk so much with the regulators or the policy people, but we're kind of realizing the world has changed and some things overlap and we actually need to talk now more to each other.

So with that, I think I'm not going to speak anymore. I'm going to get to the other presentations and the discussion and I think that those are the important things. So I want to make an observation, so I'll be stepping in and out of the room. I need to be in two other sessions same time. Thanks guys for organizing this. Nicely for me. But I'm sure we have that intense discussion. So I'm going hand it over to Pete.

     So the Internet Engineering Task Force, or IETF, is the thing that designs the protocols of the Internet. That's where we develop them. The important part to remember is that the real overarching goal for the IETF is interoperation. It's not standards, not conformance, not making sure that this is a free thing, like royalty free or anything like that. Overall goal is interoperation. There are some other things we worry about, but interoperation is our main thing. We do this through overdevelopment and rough consensus. So rough consensus is not everybody in the room. I don't need to tell everyone here that.

     Our common goal is to make the network better. It's not to make the world better. It's not a policy forum. It's about network protocols. This leaves out a whole lot of the rest of the world. Then there is this IESG, the Internet Engineering Steering Group, who are normally the leaders, except that in the IETF there are no kings. So it's better to think of this as the management layer.

     Next, please.

     So the IAB is Internet Architecture Board. This is external affairs department for the IETF; that is the place where the IETF talks to the rest of the world. So liaisons to other organizations are appointed by the IAB. In principle also, although some would complain in recent years not so much in fact, but in principle the IAB is also supposed to look after the architecture system. How these things hang together, if you do this or that to the Internet, what does it do to the way the rest of the system works?

     An importance difference between the IAB and the IETF is the IAB speaks for itself. So when something comes out from the IAB, it's not a statement from the IETF, it's not a pronouncement from the technical community; it's a bunch of people saying something. They have been selected and presumably have credentials, some of us fewer than others. But you really should take IAB statements as a statement from the IAB and not from anybody else.

     Next, please.

     So the IETF is really about protocol and not about policy. And the reason I want to emphasize that in this environment is that it means that sometimes the IETF, the protocols of the IETF builds enable policies that perhaps nobody in the IETF would like to happen. But, nevertheless, it's supposed to be a policy‑neutral environment. And that policy, therefore, lives elsewhere and the IETF just enables it.

     The IETF makes its protocol registration. So there's some other organizations you hear about, IANA, ICANN, RIR, so a couple things about that. The real thing IANA does for the IETF is it manages the protocol parameters registry. So they have various little bits that are necessary and you need somebody who keeps track of, oh, this is option number one, this is option number two. From the IETF's point of view, that's what IANA is for. They do other things like the root zone and so on. But from our point of view, it's a protocol of parameters registry.

     They'll say thing like the IANA function. What they're talking about is not everything everybody has described as the IANA function. They are talking about the parameter protocol registry. I heard that several times this week and it occurred maybe that they didn't know the distinction. This is just a book keeping division.

     The IAB can provide observations about how other's decisions affect the network architecture, and this is something you sometimes hear. So the IAB will make statements about other people. That doesn't mean that they're telling them what to do, they're not the boss of the Internet, but they will make from time to time comments; so and so is going to make this change and we think it hurts in this or that way.

     Then ICANN, Regional Internet Registries, all of those players are actually managing resources on the Internet. And that is none of our business. That's another function on the Internet and that has much more to do ‑‑ there's an interplay between sort of pure technical coordination and policy there that is not really the ‑‑ not really something that the IETF takes a great deal of notice of. The IAB, of course, will take notice of those kinds of things, particularly when they have some kind of effect on the way the network is working. So that is everything I have to say about these players and how they interact with one another. Thank you.

     So the governments and IETF must understand the different roles they're playing. We're going to provide the tools, but not how they're used. What governments have to give to the IETF is those functional goals, not technical specifications of those policies. This has become a matter of confusion very often because we speak different languages. I've been pushing the point to many people this week that there are great strengths among the different stakeholders and we must take on the things that each of the stakeholders is strong at and leave to the other players the things that they're strong at.

     We do see different parts of the same elephant. A ‑‑ for governments, they think in terms of laws and regulations, and those have applicability to protocols, but they are much different aspects. For the IETF we see those laws and regulations simply in terms of the technical requirements for any given protocol.

     Next slide.

     So with regard to regulators in particular, I think this is what comes up most often, we think of those regulations codifying a particular policy. And what we in the IETF need is for those policies to be translated into protocol elements. Quite often we can figure that out because we do have folks who are adept at moving between the two areas. We have engineers who interact with governments on a regular basis and have to do that translation. Quite often we need assistance.

     The unfortunate thing is sometimes policies look like protocols and we jump all over that and try to implement the policy instead of implementing the protocol and it's one of the things I'll talk about in a moment when I get to examples.

Again, we have to understand each other's roles and bring the expertise to the table that we're good at.

     Next slide.

     So let me talk about the two instances that I'm a little familiar with. The first I'm a little familiar with, the second quite. The first one is our ECRIT working group, Emergency Contacts Resolution with Internet Technologies.

     If you don't know about IETF working group names, we always come up with acronyms that are somehow either pronounceable or cute. And we end up with sometimes completely stupid names, but because the acronym sounds good, we like it. This is one of those.

     This is about emergency calling for North American folks, the 911 system, for other folks the 112 system. But calling using Internet protocols either voice or other technologies over IP. We've been working reasonably well with NINA ‑‑ oh, Lord. The Numbering Authority of North America ‑‑ and ETSI for input to these. But we ‑‑ this working group is chartered so that it can deal with emergency calling in any jurisdiction. What this says to me, and what I think is a good reminder, is that even if we work with particular regulators who come and say we have this need, quite often we charter these groups to make sure they address needs around the world. So as other regulators wish to come in, we find that exceedingly helpful. So, just because we're working with one set of folks doesn't mean we're excluding others.

     In this particular group this is one where the participants are very good at translating policy and protocol. They've been working with NINA and ETSI for quite some time. They understand what those policies mean and can figure out what tools are required in order to instantiate them.

     The other example is one of my working groups, which is PAWSD, the Protocol to Access White Space Database. Again, one of our wonderful acronyms. This is a working group ostensibly, you would think, to work on radio white space from the TV spectrum, except this is one of the big problems in chartering. We're only providing the tools for this. So radio white space is IEEE and error regulator kind of area. That's not what we're doing. What we're doing is providing the ability for these devices that are going to be using the white space to contact the regulator and say, what frequencies are available over the Internet? And so this is basically a database access protocol.

     The problem we've been having in this working group is actually the opposite of the one that you'd think. It's not that regulators are coming in and saying we insist on the protocol looking like this. The flip is happening. The engineers are looking at the policy requirements, the regulatory requirements and saying, oh, we have to implement that policy, and aren't translating it into protocol requirements, but thinking that they have to follow the words that are provided by the regulators.

     So one of the challenges we have is to say, no. We need to understand what the policy means, but what does that mean when we translate it into protocol speak. And getting engineers to recognize this distinction has been quite interesting.

     So in each of these cases what I want to make clear is, there is a communication that occurs between the regulators and the engineers, but there's a translation step, especially in this latter case, radio engineers are very used to ‑‑ you look at the regulation, they say you must transmit on this frequency. We tune the device to that frequency. There's a bigger jump when you go from, the regulator says there needs to be a database that con contains this information, and the engineer is quick to say, oh, well, then the database must have these fields. Well, it might have more, it might have less, it has to satisfy those requirements. So this has been the interesting interaction.

     I think that's all I have.

     Yes, I think Andrew does the next bit.

     And one of the things that's really important about this is that it's a multi‑faceted attack on the network infrastructure. The behavior here is different from some of the previous models that we've used.

     Now, I think that we need to be clear that from the point of view of many of the technical community who have looked at this, we don't think that this is unique ‑‑ the recent revelations, any of them, are unique. We also don't think this is the end of it; right? I mean, the fact that some revelations have come out doesn't mean people are going to stop doing this. So there are technical responses we think we need to undertake.

     Another thing that we have I think concluded, and this is perhaps a weak conclusion, but I think it's shared pretty widely, is that there is a really tremendous scale here. This is a threat model that we didn't really historically consider. So traditionally, you know, if you look at a securities consideration document ‑‑ and for the few of you who are not familiar with the RFC series, any protocol has to have actually security consideration section for many years now. The reason for that, of course, is there was an earlier period in which that didn't happen and we ended up with some other kinds of nasty attacks. So there's been a tradition of certain kinds of security considerations whenever protocols are designed.

Typically, these boil down to a few kinds of cases. And the sorts of attacks that we're seeing now are not like that. They're a different kind of attack. The scale is enormous. And I think that this was one of the things that we really didn't just consider historically.

     Now, one of the things we need to admit is that a purely technical response is not going to counter this on its own. Other things that need to happen, behavioral changes that people have to take, conveniences that people have to give up in order to be secured against some of this stuff. But, so pure technical response is not going to counter. Nevertheless, there are things we can do.

     So next slide, please.

     Oh, before I go on to that, I should talk a little bit about where the technical sources are here. So we've got the straightforward one, which is unprotected communications. This is duh at the end because the truth of the matter is if two months ago you thought you didn't need to encrypt your communications most of the time, you should have been disabused of that by now.

     And then there are, you know, other sorts of technical attacks. I mean, there's the direct access to the peer ‑‑ to one of the peers on the exchange, so if you can get to the end point before any communication has started, then you can see the stuff before it happens. You can have direct access to the keys. There's considerable evidence there's been attempts, or in some cases successful typically subpoenas that say, give us the keys and now we're going to look at all the traffic.

     We've got third party problems; right? This is something that is not totally news. We had, for instance, certificate problems. There's certificate authorities that have been undermined, several of those in the last several years. It appears that there are some cases where implementation back doors have either actually been inserted or anyway are likely to be believed to be inserted. I want to be careful not to make assertions that those things actually exist because, of course, we don't have clear evidence one way or the other, but there's some pretty tantalizing evidence.

     Then we've got cases where there have been accusations of standards that have been vulnerable or maybe made to be vulnerable. Once again, I don't want to assert that that has or has not happened. I don't have documentary evidence in front of me that this event has happened, but there's certainly some suggestion that that has happened. One of the most obvious examples is this elliptic curve case where it appears possible that two of the parameters were selected to make the algorithm easier to crack. I want to temper that by pointing out the last time somebody thought parameters had been accepted in order to weaken the algorithm, it turned out they had been selected to strengthen the algorithm to because of an attack that was classified. So let's not be careless about hurling around claims. But there is this ‑‑ there is this suggestion that this has happened.

     Next, please.

     So what is the IETF doing? There are some technical things that the IETF can do, and these are the things we can do. One is not a technical response, it's to discuss the topic openly. One of the things that is super important, generally speaking, in the security business on the network, and traditionally has been true, particularly about cryptography, is that more open analysis tends to be better. Algorithms that are developed in secret by a secret committee in a back room with industry players in the room and nobody else are frequently cracked within, you know, days, weeks, or months of them being released to the public because everybody can design a system that they can't break themselves. The problem is that what you need is a system that other people can't break. And the only way really the tell whether that system is resilient against that kind of stuff is to stand it up and allow those other people to take hits at it. So we want to have this discussion and we want to have this discussion in the open.

     Therefore, we're devoting a significant portion of the Vancouver meeting, which is coming up two weekends; right? We're devoting a significant portion of that meeting to these problems. And that means we're actually working on the problem. It's not enough just to talk about it or to rant, oh, people shouldn't do this, we actually need to tackle the problems that are open. So we've got a Birds of a Feather session in Vancouver that is there, actually, to address specific proposals, changes to particular technologies. There is, for instance, a discussion of selection of transport layer security algorithms. So when you have TLS, you do HTTPS, you go to a secure website that's secured with TLS and there are algorithms that are used for that kind of exchange. One of the things that we maybe need to do is deal with those algorithms and decide which ones are the right ones to use. There is suggestion about elliptic curve that is a problem.

     Also, PFS is initials for Perfect Forward Security, the idea of that is that even if you recover the key ‑‑ the key right now, you don't have the session key. So it prevents this key from being used in the future to decrypt the traffic again. And that is something that is not widely used right now and it's something that I think we're going to probably try to encourage.

     We've also got some ongoing efforts; things that have been around already that were in training long before most of these recent revelations came out. One in particular that there's been a proposal floating around, that the next version of HTTP which, of course, underlies everything on the Internet, would use encryption all the time. So it wouldn't be ‑‑ it wouldn't be possible to turn it off. And so these weird problems that you have, well, are you using security or not? The answer is, well, you don't get to choose.

     And, right, this is an engineering tradeoff. This is what I was talking about earlier how we enable or disable various features because we've got the protocol. We're not making policy. That's a nice distinction in theory, but in practice there are occasions when what you do in the protocol opens or closes various policy options for you. Here would be an example where we would say, no, the protocol is simply going to require encryption all the time. You don't get to have that choice. And the reason is we think that it makes for a better protocol overall; that the technical goals of the protocol are better achieved by doing that. So this is a technical discussion, not merely a policy one.

     Similarly, TLS itself is up for revision, so there's a 1.3 version under discussion. So these are some positive, concrete things that the IETF can do in terms of technology.

     That's the only thing I have to say about this and I think this includes all of preparatory material we have, so I guess we open the floor.

     We have the first question over there.

     Long day. During the afternoon meeting we're going to have IETF tutorial. What I would like to hear from you is what would you like, suppose you are giving the training, what would you like to say to the participants in order to encourage them to participate more in IETF? They attendees is mainly Latin American and Caribbean people. Thank you.

     So for new participants, I try and tell them, come and listen first, especially for Latin America. The language difficulty is just we're stuck with it. English is the language we use to do the protocol development. We discuss on a regular basis, shouldn't we do translation? Shouldn't we figure this out? At least the introductory material, what we call the Tao of the IETF is translated into many languages to get a feel for it. I encourage people to come, join mailing lists, then spend time listening see where you can jump in with a comment every so often and know that there will be someone who is ill‑socialized, and maybe some of us will try and whack them on the nose, who will say, what a stupid idea. This is going to get said.

And the thing to do is to nod your head, read through the content, see what important information this person has said, other than grumbling that you are stupid for some reason, and participate again. It's a strange culture.

     That said, we have had people come in from all parts of the world whose language ‑‑ whose native language is not English and have done incredibly well by persevering, by sitting, not attacking immediately, because we're better at it than most new people are and attack right back, but by just being persistent and saying, I think this is important, and laying out the technical reasons for any particular proposal and have done phenomenally well. One of my working group chairs now is one of these people who came right in, he's from Orishas, former AD came in as a very young person from Russia and has done very well by being persistent and laying out the argument, so. Beyond that, reading the Tao is an important first step. It will get you an idea what the arguments are about and how to formulate those things.

     There are lots of things that people try to bring to the IETF that just don't belong there. Everything that happens on the Internet doesn't have to happen at the IETF. Sometimes people think, oh, they do the standards for the Internet there, I want to control how people think on the Internet, therefore, I should write a standard for that. I'm being cartoonish, right? But the whole point is we sometimes get proposals that aren't really relevant. That doesn't mean you shouldn't understand how the IETF works.

     So that's one class of people who can benefit from learning something about how the IETF works or who can benefit from seeing it, but who don't necessarily need to participate.

     And then there are people who want to participate in the IETF and what I would say to people who want to do that is a key thing you must do is read the drafts. This is a mistake that a lot of people make. They think, oh, the meeting is what's the important part. The meeting is the least important part of all of this. The most important part is to read the draft, some proposal that somebody has, you find something that they want to talk about that's of interest to you. You say, hey, I know something about that thing. You read through the draft that somebody is proposing. Here's how I propose we're going to make this protocol work. You look at it and say, that's a good idea, I think that works. Or you say, I didn't understand this part.

     If you're an Internet draft author, nothing is as valuable to you as hearing from somebody, I didn't understand what you meant here. When you're trying to write a protocol what you want to make sure any random person in the future can read that thing and say, I know exactly what this is supposed to be telling me. So reading those drafts and then sending the feedback. If you're too intimidated to send it on a mailing list, the author's e‑mail address, their own e‑mail address is in the Internet draft. So send the feedback directly to them. They will incorporate it or maybe they won't. Some of them are big‑headed jerks. But most of them are there to get work done, not to grandize themselves. So they want to get that work done and they value the feedback.

     Another nice thing about this, of course, is if you give that feedback and it's useful to people, then some day in the future when you publish an Internet draft and you want to get a review, you tap them on the shoulder and say, hey, you're not an idiot, will you please review this for me. And they'll remember, oh, that person did me a favor in the past, I better do the same back. There's generally a sort of community‑building exercise here that has to do with scratching each other's back because everybody knows if you ever worked on any kind of code or document you've written or anything like that, it's always better from a good review of someone else who looks at it with fresh eyes and says, this passage is completely unclear, or this idea is totally bonkers. You shouldn't do it that way. Here's a simply way to do it. So that's a really valuable feature that you can get into the IETF very easily. It may not be a language barrier in that case because even something that is not perfectly grammatical or something like that, it's still, nevertheless, a very, very helpful contribution. The fireworks at a meeting are less important.

     So the day when I'm following the work of another working group, which is IGS, Intelligence ‑‑ with Alexandru Petrescu. And I asked him, I sent an e‑mail, please, I'd like to be more effective in this group, what can you propose? Ultimately, he send me a proposition. Can you write for us a section in the current draft?

     Oh, I say, yes, why not? And I started to write a section. And now, my name is in the submitted draft to the IETF and ‑‑  


     The first response that any author of an IETF draft sends to any people is, send text. You think there's a problem, fix it. Send me a paragraph to replace it with. Send me a new section. And so this is our weapon against people who make random comments.

     So you did exactly the right thing by asking in the nice way and you got, luckily, a nice person to say, yes, this is exactly what you need to do is send text. So if you want to start participating, I think this is a great way to do so, is go through, look at a document that is currently under development and say, I know about this piece of ‑‑ how to program this piece of protocol and this isn't going to work. We should reverse it, or we should make this clearer. Send a suggested replacement paragraph. That's what works. Much better than just saying I have reviewed this and I think there's a problem here. Fix the problem.

     So the question is, you said the IETF just does protocol and you know, someone else does policy. So way back when, we did that once. We have one good example that I'm familiar which was when the IAB wanted me to look at this gTLD‑MoU stuff, this was before ICANN, then that sucked away 10 years of my life because I became ‑‑

     So what happened was ‑‑ I was the first Vice Chairman of ICANN and we see what happened there. With respect to what I observe right now in the current context is that there seems to be an even need within that community to look at policy, policy of what? And so ICANN just does names, and that's fine. All these other really important issues about policy elements that are, as you've heard in the last week, also occurring. So I'd love to have a question, which is, do you have any idea about what other kind of policy fora, perhaps it's the IGF, I don't know, that really could interact ‑‑ what would be the requirements from the IETF perspective of a type of policy body that you would be prepared to engage in?

     And the reason why I ask that is because I've got a selfish agenda, which I'm also part of this strategy panel, strategy panel on ICANN's role in the Internet Governance Ecosystem. So let me just start with the question.

>> ANDREW SULLIVAN: So that ‑‑ I can't say what the IETF would be prepared to participate in. I wouldn't even venture to guess. But ‑‑ but I can say what I am prepared to participate in. And it seems to me that this is partly related to ‑‑ it's partly a case‑by‑case answer. So there are things that are ‑‑ that need a consistent global policy, like the DNS. Why does it need this consistent global policy? Because it's got this foundational piece that everybody has to share, whether you like it or not. So you don't have any choice there. You actually need a global coordination because there's one DNS root, that's just a fact of math, and therefore you need some sort of coordination.

     There are other kinds of cases which ‑‑ for which we need sort of, you know, best practices, or best ‑‑ you know, sort of kinds of interactions that we need to have an ability to say, in this case, here is the kind of thing that you probably want to do. A good example of that, to push it in the other direction is security practices for sort of end‑to‑end communication for, say, e‑commerce. So, you know, you've got what is very valuable data that you're exchanging there and you want this very valuable data to be handled well all along the system.

     Actually, that's an example of something that, with a few wrinkles has, despite the fact there have been a number of compromises, we actually understand how that's supposed to work, right? You should have strong authentication in both directions. You should have good handling of the sensitive data at either end so you don't end up storing data that is easily compromised.

     What's interesting there is we didn't need a global coordinating body that was a single body, instead it was a group of people who got together and said, we are the ‑‑ we are the credit card people, for instance, whose losses are going to be directly affected by this kind of stuff. So, you will store this data in this way or we will yank your credit card ‑‑ your ability to handle credit cards.

     Well, what we didn't do well was make the security of the browser really strong; that is the client‑side stuff we sort of ditched; right? We ended up with a user interface that is just awful. And we tried three or four different attempts to make that better and that hasn't worked yet. So there's a lot of work to do around usable security for end users. And I don't know where that work ought to live. It probably shouldn't live in the IETF because we're not very good at user interface. But somewhere, good strong user interface conventions probably ought to come about. That's an example of something I would like to see, you know, various industry people come together and try to figure out how to do that.

     There's some ‑‑ there's a group ‑‑ traditionally, there's the human computer interaction stuff. ACM has things around this and so on. It would be nice in those academic studies influence some kind of group that came together for usable securities stuff. And that's maybe something that OS vendors and browser developers and, you know, a few other kinds of things, probably mobile OS people could do a lot of good there. Because if you think the security practices are bad on the desktop browser, you know, look at the way security is handled on phones. It's just a total train wreck. You never know what you're going to get.

     So there's a whole host of stuff there, that's the kind of example I would expect is going to be most effectively contributed to by a true multi-stakeholder kind of thing in which governments could participate by saying, hey, here are some good practices, or here are regulations that we're going to put on in order to do consumer protection, but that doesn't mean we're going to tell you how to do it. The developers can say, we've got all this instrumentation in our system so we can see what is effective and what isn't and therefore we can tell this is working. The credit card people, for instance, are going to say, wait a minute, you're storing Visa numbers in the clearer on the system. Don't do that.

     Those are all examples of a group of people, all of whom have particular expertise, and they should come together and do that. That's a kind of activity that are self‑organizing.

     And then there are other kinds of things, to finish, there are other kinds of things that I think actually ought to be dealt at a ‑‑ you know, literally at the level of national laws and things like that. So there are, for instance, practices of carriers. Historically, those have all been handled at the national level and it's going to be very difficult to change that behavior. And I would like to think that those Federal authorities and the, you know, those national governments are going to be influenced by their population to say, hey, wait a minute, we don't want you interfering in this operation, or we don't want you tapping things this way or any way. We don't want you tapping things in secret this way. We want this to be open or whatever. That to me is something, if national governments are actors in that case and therefore it's really national governments who have to be taking the pressure from their populations to say, hey, here's the kind of thing we're going to do. Maybe that's something that does have to happen in intergovernmental multi‑lateral, et cetera, sort of environments. I don't know, I'm but a geek. I don't really understand how politics works. But I would say it seems to me that these are different sorts of contexts and they need a different kind of answer.

     I'd stay out of policy.

     And one of the things I think I'm closing in on is that it's inherent, particularly in light of what you said, there's a fundamentally different set of approaches. Policy people will ask, who are you as a stakeholder; engineers will ask, what's the problem? And an enormous amount of what I think I see of people talking past each other comes down to ‑‑ and this isn't even characteristic of the individuals, it's characteristic of the framework they're coming into the discussion with. I know plenty of people who can move back and forth between these frameworks. But if you're sitting in one frame of reference and saying, what's the problem, and what you're hearing is, who are you? People talk past each other. Even being aware of that and being able to say that at the right time is actually really helpful in a lot of rooms, whether you're interested in technology or policy.

     And I said, you know, two things about the technical community: First of all, you'll notice that on this issue the technical community has really not panicked at all. They kind of nod their heads and say, oh, we have a tool to fix that. We should work on a tool to fix this. The other thing is we don't think about it in terms of who is the attacker. We think about it in terms of what is the attack. What are you trying to prevent? In many of these cases, no matter which the attacker is, it's exactly the same attack, as Andrew was pointing to earlier. And getting your head around the technical problem as not being about the people involved, but the computers and the systems and the networks involved is a very good way to sort of turn the question so that it doesn't turn into this roiling discussion. It's a different way of approaching the problem.

     They're hearing about it perhaps at the ITU and they're not sure what it is. Once they go, they realize it's a great open forum. They have the ability to talk to key technologists on routing, addressing, other issues of interest to them throughout the world, and it's a careful forum where you're not ‑‑ no one is going to ‑‑ it's almost like Chatham House Rules, no one is going to tell someone you asked this question. So it's a comfortable environment. It's something where you're breaking down the barriers between technology and policy and trying to marry that up. So if anyone is interested, knows government officials that want to go, we help provide assistance to do that.

     So do we have more questions? Comments? A contribution?

     So what I wanted to perhaps explore is, you know, although these revelations are not so much revelations, one thing that I think is apparent to me is that the users now have recalibrating their expectations on what they want. And so as we look into the future, one of the problems with looking into the future in terms of projection model is because that projection model is always based on the current reality. So one of the techniques I use in terms of looking at technology, how technology could evolve, is to do it from the other way around, which is have a look at sort of the end in mind; what we really want, and then to back ‑‑ cast it back and say, what we need is this, what we need is this kind of thing and then fill in the specifics later.

     So I just want to float the idea that instead of just looking at today's reality and today's urgency and all the crisis that we have to deal with today is to also have a bit of a sort of vision. Again, I think we stated the vision in terms of open centers, open Internet, but I'm not sure if that translates to users because they don't really care how we got here. They care about what am I sort of ‑‑ what's the feature set coming forward.

     So what I want to suggest is looking at ‑‑ if you look at the environmental community where they have deep concerns about ‑‑ we all have deep concerns about how the environment is going to pan out. So if you base it from we don't want global warming to have a devastating effect, as an assumption, or the energy community. You know, oil, what have you, as a known constraint and back cast it to where we are today, maybe that might help frame and help communicate the IETF discussions with the rest of the world. And it's that intersection between what you're doing in terms of going forward and what users could be expecting coming back. That intersection may be an interesting place to explore. So what I would ‑‑ I'll speak to you guys off line about this, but that's the concept.

     But there was not a lot of concern ‑‑ and I should say also there was this concern about sort of individual points of attack; right? So you've got, can somebody brute force this key really easy and so on. So there's this straightforward consideration, okay, what is the strength of this thing? What is the expected lifetime of that key or signature or whatever you've got, and what is the expected vulnerability period? Then what you want to do is make sure that the vulnerability period is always shorter than the length of time that somebody could possibly attack this thing. So those are the kinds of attack that people are talking about.

     What we didn't think about is the environment where there's hyper‑pervasive thing where somebody has this net and it's a sort sieve net for the Internet, right? They're sucking up everything and kind of running over that. So what I think we missed in our modeling was a sort of environment where the total pervasiveness of this was a problem. And that ‑‑ and that is, of course, a failure of vision, fundamentally, of the sort you're talking about. That is we didn't think about one kind of way to do this. Or, I think more accurately, if you go and read archives from the periods where some of these discussions happen, what you'll discover is people said, well, yeah, that's a theoretical possibility, but who is going to be able to do that? And it turns out there are people not only able to, but also willing to do that and, therefore, you have a problem.

     So I think that that is the kind of thing that you're exactly right, what you need to have is a sort of vision; well, what else is a serious kind of thing? And this is not the only time IETF made this mistake. Another example is in DNS, an area I'm pretty familiar with. The so‑called Kaminsky attacks that were a big deal, if you look at the history of this, more than 10 years before he had his road show, Dan Bernstein was saying, hey, there's a big attack here. It's totally available. People in the DNS community said, yeah, come on, it's a theoretical attack. It's not really going to happen. Then it turned out it could happen in three packets. And so it turned out that it was quite a lot easier than anybody thought. Nobody had done the analysis and it was a bad day.

     So, it's that kind of thing where, you know, this is a place where the open environment can lead to the sorts of bad decisions. Of course, the nice thing about open standards environment is when you make that kind of mistake everybody can just kind of go in public and try to fix it. Rather than what we've sometimes seen with closed standard environments where the answer is no, we don't believe that's an attack, and by the way, we're going to make it illegal to have those keys anyway.

     There's a fundamental difference in approach here that at least the resilience, or the response in this kind of open environment is a little bit better. But I would prefer it if we have failures that were a little less hard than what we've had. So that's an example of something we can do better.

     So, as far back as I can remember, there were discussions of the engineering tradeoffs of doing opportunistic encryption. That is, you encrypt with some key, whatever it is, and the whole issue of verifying whose on the other end is a separate thing. The security community pretty early on said, well, we could do that but the real attacks, what we're really worried, about is someone being in the middle. And so the first thing you have to do is make sure you're talking to who you think you're talking to and then and only then do you start doing encryption.

     Well, what would have solved this problem very effectively would have been for all of us to have been encrypting all along and do the verification steps later. All software just encrypts. And to make sure you're talking to who you think you're talking to, that's a separate matter and make it a different part of the policy.

     So I don't know that we didn't do that future thinking. I think the hard part is envisioning what's going to be important to users. I think you've framed that exactly right.

And that's a hard head space to get into. We're very good at designing for users who are just like us. There turn out to be exceedingly few of those folks.

     Any other questions? Comments? Rants? Whatever?

     So we would like to thank you, guys, if there is no further comments or questions. Thank you all for attending.

(Session ended at 10:10 a.m.)

This text is being provided in a rough draft format. Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.