GAC Plenary: Security Related Issues Tuesday, 27 October 2009 ICANN Meeting Seoul, Korea >>CHAIR KARKLINS: Good morning, ladies and gentlemen. Please take your seats. We are starting the session related to security issues on Internet. We have a very impressive team of experts here from SSAC, RSSAC, VeriSign, ICANN staff. And this team has done excellent homework by arranging the sequence of session, sequence of presentations during this session. And without further delay, I will turn mike to Steve Crocker, who will introduce the sequence and introduce also presenters. >>STEVE CROCKER: Thank you, Janis. It's a pleasure to be here. As Janis said, we have really quite an excellent team of people. And we took the opportunity ahead of time to all get together and try to organize ourselves a little bit to fit within the time to meet your needs. So we'll be interested in feedback on whether we've succeeded. I'm going to stop talking just after I walk through this and introduce people. The first topic that we'll be hearing about will be on the progress toward signing the root. Matt Larson, from VeriSign -- let's see -- sitting here, will take that. And he'll be speaking on behalf of VeriSign and ICANN, I understand, with the cooperation of NTIA. Or if I'm off, you can adjust that. Thank you. And then you've all been hearing about the study on the scalability of the root. Lars Liman was a member of the team that did the primary work. Let's see, I've lost -- Lars is sitting three down from me. And Erik Huizer, sitting next to me, with T&O in the Netherlands is from the group that provided the beginnings of a quantitative model that is under way. Ram Mohan will talk on DNS redirection, which you heard about before. That will be quite a short report, in the interests of time. And then Greg Rattray will talk on the security, stability, and resiliency plans and programs, updating you on that. And then, finally, Ken Silva will talk -- from VeriSign, will talk on DNSSEC lessons learned from the dot EDU environment. With that, let me just rapidly turn things over to Matt and make best use of our time. While they're getting that together, let me express an additional thanks to Suzanne Sene and Shane Tews from VeriSign. The behind-the- scenes work to assemble this session was qualitatively different than in the past sessions and, at least from my point of view, has come together very smoothly. >>MATT LARSON: All right. Good morning, everyone. Thank you, Steve. I am Matt Larson, from VeriSign. And I want to give you an update on where we are deploying DNSSEC in the root zone. So this proposed design that I'm going to speak through, as the slide says, is the result of cooperation between ICANN and VeriSign, with support from the U.S. Department of Commerce, NTIA. We're striving toward various important -- various important goals in the design. And these are three of the most important ideas: That the design be transparent so that the public and the Internet community can know what's going on and can trust the signed root. The design is also intended that everything related to signing can be audited by third parties. And, of course, high security. Let me go over the roles and responsibilities, which you may be aware of already, for changes to the root zone and describe how signing the root is going to change those. So ICANN, the IANA functions operator, its role in the signed root is going to be to manage the key-signing key. So that's a new function. And another new function is to accept DS records from TLD operators. These would be the records that contain the key material for the TLD. And then, as usual, for any change, ICANN will do the due diligence and send requests to the DOC for authorization and VeriSign for implementation. DOC does the authorization. And this follows the exact same process as current change requests are authorized. And then, finally, VeriSign, in our role as root zone maintainer, we will be managing the zone-signing key. And we will then sign the root zone with the zone-signing key and, as and we currently do, distribute it to the rest of the root server operators. This diagram, which is, unfortunately, a little bit hard to read, depicts basically what I just described, but in graphical form. The TLD operator is on the right. It shows the changes flowing to ICANN through D for authorization, and then to VeriSign for signing. And then you'll notice on the bottom, on the right, there's a box called "ZSK management," which is VeriSign's function for managing the ZSK. And then that requires VeriSign and ICANN to interact, which are the two lower arrows to the lower left, ICANN's KSK management role. So I'll have a little bit more to say about that interaction in a moment. The team has been producing a tremendous amount of documentation, which I understand will start to be made available to technical experts for review shortly. And one example of probably the most important documentation that we're producing are two documents called DNSSEC Policy and Practice Statements, or DPSs. And as the slide says, these documents are designed to describe, really, everything involved with signing the root, indeed, the policies that we follow, the practices that are implemented. And the main role for these documents -- well, there are two main roles, I should say. One is to make this information available. And then the second is, the DPS serves as a basis for a third-party audit of the process. And if you're familiar with the way things work in the X509 certificate world, an X509 certificate authority that issues certificates publishes a CPS, a certification practice statement. And so this is very much analogous to that. There are actually going to be two CPS documents produced from the root zone: one from VeriSign and one from ICANN. They're complementary documents that follow the same structure. So they have basically the same outline. But because there are slightly different requirements because VeriSign and ICANN are managing different keys and have different roles in the process, in some cases, the documents will differ. So this, then, graphically depicts, really, the role of the DPS documents. We have ICANN's role in key-signing key management on the left and VeriSign's role in key-signing key management on the right. And on the bottom of the slide, we have the various functions performed on keys. And the most important thing, I think, highlighted by this slide is that the policy and practices statement is sort of at the bottom, describing that. And then, as you can see from the arrows, flows back up to the global Internet community and the third-party auditors serving the two functions of the DPS. Just to go into more detail about IANA function activities regarding DNSSEC in the root, one of those is key ceremonies. And there will have to be a key ceremony to generate a new KSK, which we expect to occur relatively infrequently, on the order of two to five years. And more frequently, there will be a ceremony to process to what we're calling a zone-signing key -- excuse me -- a ZS key-signing request or a KSR key-signing request. And this is a document, a message from VeriSign that requests that a certain number of zone- signing keys be signed, which ICANN then processes and sends back. This is going to occur every quarter. So every quarter, VeriSign will batch up a request of material to be signed. ICANN will hold a key ceremony and send it back. And then ICANN's role will also be to publish the root zone trust anchor, namely, the root zone key-signing key. They're going to publish that on a Web site in various formats and perhaps publish by other mechanisms as well. I want to spend some time talking about the proposed deployment. One issue that we want to address is, as you may be aware, many DNS resolvers today request DNSSEC information. And they're not getting it today from the root because, indeed, there is no DNSSEC information in the root. But as soon as the root is signed, they're going to be -- they're immediately going to be getting that information. And the packets are much larger. So we want to make sure that these larger responses are not going to have any negative impact on any of the infrastructure between the resolver and the root name servers. And rather than deploying the -- deploying DNSSEC to the root zone all at once, we're going to do an incremental rollout. So we're going to roll out on groups of root server letters, if you will, at a time. And the idea is to deploy to -- initially, to one root name server and then monitor and watch what happens, and then deploy to a couple more and monitor and watch what happens, to have a very gradual deployment to make sure that we understand exactly what's happening. And we'll have an incremental rollout to a signed signed root rather than an all-at-once operation. And another key aspect of the deployment is that it will be impossible to actually use the signed root zone for validation. We're going to replace the keys used to sign the zone with dummy keys so that it would be completely impossible for someone to accidentally or deliberately or in any way configure a DNSSEC validator to actually validate the root zone. So there's no way that someone can get themselves into trouble from a DNSSEC validation standpoint based on this root zone while it's being rolled out incrementally. And then, finally, here's the time line. The root zone will be signed on December 1st, 2009. That's the good news. The still good news but not quite as good news is that, initially, the signed zone is going to stay internal to ICANN and VeriSign. Also on December 1st, ICANN and VeriSign are going to begin testing this KSR processing bit. That is the interaction where VeriSign sends the zone-signing key information to ICANN to be signed, and that's returned by ICANN. We're testing that now in a test environment. But starting December 1st, we're going to be doing it at the actual time scales of the root, how it will operate. So that is, we'll have two full quarters. And that will allow us to test things like rolling the zone-signing key and rolling the key-signing key during this interval. So that happens during January to July. So two things actually happen at that point. ICANN and VeriSign are performing this KSR processing to validate that it works as expected. And then also, the incremental rollout of the signed root that I described a moment ago happens at the same time as well. And then, finally, the big, most important day is July 1st, 2010, which is when -- which is when we intend to roll from a test key- signing key into a real key-signing key that was generated with a proper ceremony and is the key that we intend to use. The trust anchor corresponding to that key will be published. And that will be when we have a signed root. >>STEVE CROCKER: We're going to watch the clock. But rather than defer questions to the end, which probably will be too big a span, we'll take some questions now with each talk. So if there's questions with respect to the signing of the root, this is the time to dive in. No questions at all. Let's take the opportunity and scoot; right? Let's get -- Thank you. Good job, Matt. As I mentioned at the outset -- oh, there is a question? Is that you, Suzanne, with your hand up? Or are you just praying? [ Laughter ] >>STEVE CROCKER: Sorry. Is there a question somewhere? Is that what you were -- >>CHAIR KARKLINS: No. I thought that -- Bill, no? >>STEVE CROCKER: Okay. Thank you. The -- so moving on to the scalability of the root, a combination of the Root Server System Advisory Committee, the Security and Stability Advisory Committee, and ICANN staff were asked by the ICANN board to undertake this examination. We formed a steering group. Matt Larson and Suzanne Woolf, vice chair and liaison to the ICANN board from RSSAC, respectively; Ram Mohan, who is liaison to the ICANN board from SSAC; myself as SSAC chair; and a handful of others, 11 in total, formed a steering group which set the terms of reference and initiated the study. We engaged a team of people, headed up by Lyman Chapin. We have here today Liman -- not to be confused with Lyman -- to talk about the bulk of the study. And along the way, there was a quantitative modeling process that was initiated at T&O. And Erik Huizer is here as the chief scientist of the portion of T&O where that work was done. Let me turn things over to Lars. >>LARS-JOHAN LIMAN: Thank you, Steve. My name is Lars-Johan Liman, I work for Autonomica Corporation in Sweden, who operates the I-root server, one of the 13 root name servers. I would like to thank you for giving us this opportunity to present some of the results from the root scaling study. The study team was put together by the steering group, as Steve mentioned. And there were six members. Two of us are here today, myself and Bill Manning, who is somewhere in the room, I believe. We also contracted T&O to do a quantitative model to -- mathematical model where we could try to give different types of numbers as input and see what the consequences would be. Erik will present that model in more detail. We were given the task to investigate root zone expansion in four different fields, one of them being new resource records for secure DNS or DNSSEC. The second one was the introduction of internationalized top-level domains, names written in other scripts than Latin. We also were given the task to see what would happen to the root server system if new address records for I.P. version 6 were introduced, and, most importantly, to look at what would happen to the root zone if the root was extensively expanded by adding new TLDs, new top-level domains. Adding new top-level domains will have two important consequences, which is, of course, very natural. But the thing that is probably not so obvious is that the larger database leads to a larger -- an increase in the change rate to the zone. The bigger the zone, the more often it changes and the bigger the changes are. And that turns out to be an important factor. Next slide, please. When we did the theoretical analysis, we have this model in front of us. And this is pretty much what Matt explained to you before. On the left-hand side, we have the provisioning side, where top-level domain operators send in change requests to the IANA function. And they cooperate with the Department of Commerce, the NTIA function, and VeriSign to produce the root zone, which is the database that is served by the root servers. On the right-hand side, there is a picture of the root server system itself, where the data is picked up from VeriSign and distributed to the various letters. There are 13 servers, in theory. But several of the servers are -- have identical copies spread over the globe, using a technology called Anycast. Next slide, please. The findings of the study team in the short bulleted list are that we found that the root server system is a highly decentralized dynamic system. If you look at it at a given time, it's very hard to give a -- how do you call it? -- give an estimate of the capacity of the system, because the system is designed by 12 different organizations, and they each use different ways to design their part of the system. And they all maintain a certain headroom so that they know that the capacity of their part of the system is more than they need to handle right now. And that headroom varies in different parts of the system. But it's also very adaptable. When changes happen, and they do, frequently and in different places, when changes happen, the system will adapt. The engineers working with the systems will notice, oh, something has happened here. We need to change the system. And that is going to continue to happen. So, therefore, it's very difficult to say how much can this system handle, because the more -- the higher the requirement is, the more it will be able to handle. But the change rate is something that is a very sensitive point here. We also want to note that the -- any change in increase or any change in rates or type of data or such changes involve risk. And it can be a big risk or a small risk, but it's always a risk. So everything is a question of risk management. We also believe that the root system oversight should focus on early warning systems rather than threshold prediction. Instead of trying to say we can handle this much so we need to stop before we reach the number X, we should say let's build a system that tells us when the root server system is under strain. When we start to see a warning light coming on, we're getting near the point of too much. And we also came to the conclusion that there are some critical sections; changes to the system that once you start them, cannot stop until you have reached a stopping point which may be far ahead. You can compare that to driving a car in a desert. When you enter the system, you have to know you have enough gasoline in the car to reach the next petrol station. Because if you don't, things will go bad in the middle. And one such thing we note is if you want to add famous trademarks to the root zone as top-level domains, you have to be prepared to add all of them. You can't stop halfway and say, no, we can't take anymore, because the other half who didn't get theirs will be very upset, and rightfully so. Next slide, please. There are a couple of operating regions. We noticed that there are changes that you can make to the system which the root server system and root server operators can handle in normal operation. We know changes happen. There is preparation for handling changes, but to a certain degree. An increase in the zone is a normal thing. We know that it grows. We are prepared to deal with that. And if we're given heads-up information, a lead time, we can deal with those things without having to do anything out of the normal. Next slide, please. There are changes that lead to substantial replanning in the root server system. The operators will have to redesign the system, they will have to do upgrades to the system, and such changes will have to have a one- to two-year lead time, because that's the time it takes to do the design, buy the systems, and ship them all across the globe. That takes more time than you would like to think. Next slide, please. And the third region is where the changes are so substantial to their type or to their size that the entire root server system will have to be redesigned. And that includes the provisioning side, that you includes the IANA function, the NTIA DOC, how they handle the system, and also at VeriSign. And it will also probably lead to revisiting the funding situation for the entire system. And this would -- This is a process that would take several years. So before introducing so big changes, the root server system as a whole needs to be warned several years beforehand. Next slide, please. On the provisioning side, we found that the ability to scale the root is dominated by the steps that involve human intervention. Today, human intervention is in place at the IANA function, at the Department of Commerce and at VeriSign. And every time a human needs to look at the request, it takes time. And that's where the resources are limited today. On the publication side, on the root server side, the scaling primarily affects poorly connected Internet locations. Today the root server operators serve the root zone from somewhere between 170 and 200 places across the globe. Some of them are more well-connected than others. If the root zone increases in size, more data will have to be transferred to these serving places from where the data is served, and it will also have to happen more often. And the connectivity, the links to these places are often a factor that limits the amount of data we can send over given time, during a given time. The risks associated with additional of a few hundred TLDs can be managed without changing anything in the system today. Doubling the size of the zone, even tripling it, is totally within the limits of today's system. If we start to talk about an annual increase of the root zone on the order of thousands of new entries, we need to make changes to the current arrangements, at least within a number -- if not all, but a number of the actors involved. Next slide, please. The root server operators maintain a certain headroom, and some of the changes have a property that they are step functions. Some changes make a very sudden change to the system. And the typical such change is DNSSEC, secure DNS. It will suddenly add a lot of data to the root zone. It will make it grow by a factor of three or factor of four. It will be four times as big suddenly. If you have a very small zone when you make that change, four times small is still fairly small. But if you make the change when the zone is bigger, if you let it grow and then make the change, four times big is a lot bigger than four times small. So that may actually run into the headroom that is maintained today. So if you make that type of change when the root zone is small, the effects are not as drastic and the headroom can be maintained. The headroom that is the safety margin that everything continues to operate smoothly. Whereas if you wait, maintaining that headroom becomes much more complicated. Next slide, please. We also tried to make a table of what type of effects the various changes would have. You can see here that adding new TLDs will increase the number of TLDs in the root zone, and that's obvious, and it will increase the size. But it will not increase the amount of data per every TLD. The average amount of information per TLD stays the same. And it doesn't change the number of variables, the number of type of data per TLD. And it doesn't change the number of changes per TLD per year. There is roughly -- If you look at averages, every top-level domain makes changes to the root zone every year. If you look at DNSSEC, it gives different effects. It doesn't increase the number of TLDs, but it does increase the root zone size because there are new records that need to be added. And DNSSEC increases the amount of data per TLD. IDNs will increase the number of TLDs and also the amount of data because they tend to be longer. IPv6 addresses will change the properties and increase the size, but only with a rather small factor. Next slide, please. I am not going to go through this entire table because that will take a while, so I will leave that and hope that these slides will be sent out to you so you can look at what effects this will have on zone transfers between the root server systems and effects between the IANA operator and VeriSign and so on. Next slide. Finally, a slide giving links where you can find all these reports if you want to read them. There are also systems at the ICANN Web site where you can leave comments on the report. And it also points to the TNO report, which is kind of hard to find on the ICANN Web pages. So with that I will conclude my report and thank you very much. >>STEVE CROCKER: Thank you very much. Before opening up to questions, let me ask Erik Huizer if you want to add any words about the modeling site or other aspects of the study. >>ERIK HUIZER: Yes. If I may, I'd like to add a couple of remarks. We did the modeling to try and clarify the consequences of policy decisions about the root. And we didn't develop a model to answer the question how much is too many. And so that fits what Lars just said. And if you look at the conclusions in our report, we think we have a good model which can be used not only this time but all along any policy changes that we make. But the main challenge we found is that we need to improve the quality of the model by improving the input data. A model can be as good as it is. Rubbish in means rubbish out. And so one of the challenges here is to get really good data. And, in fact, that adds to what Lars said, what he calls the early warning system, is where you have to start getting good data and not just once, but keep monitoring that and improve the quantitative model so that you can keep a tap on how the system is performing while policy decisions are made. And having said that, what we found based on the current set of data we had fully supports what Lars just presented. Maybe I should add for people -- maybe should have started with that -- what TNO is. TNO is. Dutch national research organization, founded by the government, which is independent of industry and the government itself. And it's comparable for, for people who know about Fraunhofer in Germany or CSIRO in Australia, things like that. >>STEVE CROCKER: Thanks very much. So now is the time for questions. I had heard this is a topic that would engender a lot of interest. So I am looking forward to having lots of lights or hands or.... >>AUSTRALIA: Thanks. As so often in my job, my formal studies are not in this area, so this might be a dumb question. It seems to me, and I don't know if you actually looked at this as an issue that we have got a number of potential changes that are coming that could affect the performance of the root. We have got DNSSEC, IPv6, IDN ccTLD, and the new gTLDs. And you from what you are saying the full effect of these things might not be known for some period of time, because the full implementation will actually take some period of time. I just wonder if you have given any thought to a priority listing out of these potential changes to the process, to actually saying that perhaps one of the most important things we need to do is DNSSEC. Let's give that absolute priority. And then we have given agreements on -- or we have to respond to the IPv6 question. Let's make that number two, and so on and so forth. I wonder if you have looked at that question at all to maintain the stability by giving some sort of priority approach. Thanks. >>CHAIR KARKLINS: So that question came from Australian GAC representative. And on my list is European Commission, Sweden afterwards. But probably Lars you want to answer this one. >>LARS-JOHAN LIMAN: Yes, we have given some thought to that. But it's really not up to the study team to give that. That said, I do have a personal opinion which is that changes that make step functions as I described should be done early on, because things that do a gradual change to the root system are easier to manage and easier to regulate the speed at which it happens. And since the step function is a step, you want it to happen when the root zone is small, and that would make it prudent to make step changes before you start to increase the size in a gradual way. Then again, that said, we already have a plan for DNSSEC. And I'm very pleased to hear that. And IPv6 is actually already in the root. There is already a process tool to add IPv6 records and several TLDs have already done that. So that is a gradual change where the little step of adding a new type of record is already done. So we know that it works. And we can gradually take on new such requests. With IDNs and gradual expansion of the root, they are both gradual things that can be done later on. That's my personal opinion. >>CHAIR KARKLINS: So Suzanne Woolf. >>SUZANNE WOOLF : Thank you, Mr. Chairman. To that question also, it's important to note that the report is part of a larger process, begun by SSAC and RSSAC, and not yet completed. Both committees are deliberating what specific advice to offer based on this work and the other things we are hearing. So thank you for that question because that does point us towards what advice it would be useful to give. >>CHAIR KARKLINS: Thank you. European Commission. >>EUROPEAN COMMISSION: Thank you. Just I had a couple of questions but I will now chain on what Suzanne said. Suzanne, advice -- what is the timeline for advice? >>SUZANNE WOOLF : This topic, I can only talk about what RSSAC has discussed so far, which is that this is the major topic for our face- to-face meeting in Hiroshima in two weeks. And from that I hope to see the initial parameters of the discussion and a timeline, which we will pass back when it's given to me to do so. >>EUROPEAN COMMISSION: To continue -- >>STEVE CROCKER: Let me just give the complementary answer for SSAC. We're aiming for a December opinion advisory. Whether we can actually accomplish it or whether it will go faster or slower remains to be seen, but that's the timeline we have set ourselves. >>EUROPEAN COMMISSION: Thank you. On some of the remarks, you talked about rubbish in, rubbish out, and the modeling, and I am very impressed that you come up with a model already, because when I remember having discussed it the last time in Sydney, things weren't very clear. And that is a very short time frame. And that brings me to the question, are you satisfied with the model? Is this reliable? Secondly, you mentioned driving into the desert and sensing the monitoring of what happens. Now, what would be the timeline for an implementation, the rollout of something that would allow us to sense where stress is in the system? The second question, technical question, is regarding DNSSEC, which seems to be the most demanding issue for the system. And I would like to know whether that is dependent -- the stress is dependent on the actual rollout of DNSSEC, apart from implementing it in the root, rollout in the field and the use of DNSSEC, what is the relationship between that and the stress on the system? And finally, you were very careful in formulating, saying one should do this first in order to keep the root small. It makes a lot of sense. If I reformulate it, would that mean that if you put in DNSSEC, you would have to wait with all the other things that are not yet in the root? Or to change the argument from the other side, you can do everything if you don't do DNSSEC? It's very provocative in this way. And lastly, picking up what VeriSign presented, we are, in real life, only in the middle of next year -- even after the middle of next year, first of July, what would that mean if one takes that technical approach, let's go with DNSSEC, see what that means, because only after July we really know what happens, and what would this mean for the rest. Thank you. >>LARS-JOHAN LIMAN: I have a bit of a problem keeping all of these questions in my head at once. I'll try to work backwards, actually, from them. You are right in perceiving that I think it's prudent to take one step at a time, because we are making changes to the system. We want to measure the effects of the changes. And if you make several changes at one time, it's very hard to measure the effects of each single change, because there will be noise from the other change, and that makes the measuring more difficult. We already know most of the effects regarding IPv6 because it's already in there. Regarding DNSSEC, yes, you are probably right that we want to do that without introducing any other changes, because that's such a big thing that we really want to carefully measure what happens and have a plan to roll back if things start to go wrong. And with the current plans, as I hear them from VeriSign, that would mean no significant other changes during the period until, say, July. And you probably want to measure somewhat after that, so somewhere into the autumn of next year, I would -- Just a general feeling I have. I'm not saying that we cannot make any changes to the root zone, but we want to be careful with the amount of changes that we make. Can you please quickly remind me just what the two other questions were. >>EUROPEAN COMMISSION: Two other questions. When can we go into really -- first is reliability of the model as it stands. Are you progressing in that. Second, when will we be in a position to measure in some way, in a meaningful way, the stress in the system? You mentioned that. And the last question was DNSSEC, is the stress in the system dependent on the actual rollout on the ground and the use on the ground, or can you already measure it just by the introduction of the root signing function at the top? >>LARS-JOHAN LIMAN: Regarding the rollout of the DNSSEC, I think, yes, it depends on the rest of the Internet, on the systems of the Internet, because when the root servers start to deliver DNSSEC data, there's no way to know how all the systems on the Internet will handle that data. There will be hiccups. There will be systems where the programmers have made errors that will be triggered by changes. And by measuring as it's being rolled out, we hope to see the effects early on and be able to go back, investigate, try to find ways to solve the problems before the system is fully deployed. So, yes, there is a relationship between them. I do believe that the root servers, as such, can handle a rollout of DNSSEC without much problems. And I think the problems are going to be in the end-user systems, if there are any significant problems. With regard to the TNO problem, I think today it is a very coarse model, it is a block model. It's not a fine-grain model, and there is room for improvement there, and probably a lot of improvement because it was produced under very short -- during a very short time frame. That would be very interesting for the future evaluation of the root server system to have a better model where we can give better input and where the model itself is also more fine grained and more detailed. That would give us better ways to test where the points of stresses are in that system. And then you ask when we can start to have this early warning system. That I don't really know. It's an idea that has been brought up fairly recently, and I guess the root server operators need to sit down and see what can we do, what types of measurements can we do, when can we do them, what time -- how long time would it take to roll that out and so on. But it's definitely a matter of at least one year. >>CHAIR KARKLINS: Next is Sweden and then New Zealand and then U.K., and then I believe we need to move to the next. >>SWEDEN: Okay, thank you. Thank you so much, Lars for your very, very interesting presentation. It's really -- well, it's not too early to do these investigations, I think. Maybe it should have been done a long time ago, because I think this certainly, certainly affects a lot of other policies and activities for what ICANN is doing. So the only thing I would like to say is of course we need to know what's going to happen with all this information or the advice that is going to come from the steering group. And also how it's going to affect all the other things that are happening, because I think it is very good information, and it's very important that we take this into account, as far as I can see. >>CHAIR KARKLINS: Thank you. New Zealand. >>NEW ZEALAND: Thank you, Janis. I would like to congratulate the team on having made so much progress in Sydney, actually. It's actually a much more reassuring picture than we had in Sydney. At least we are having a feel that somebody knows what is going on, which is great. I just want to clarify one thing. I understand completely the need to assess the changes, especially after something like introducing DNSSEC, but I take it from what you are saying that the earliest introduction of IDN top-level domain would be late next year, at least 12 months away, if the changes introduced by DNSSEC are going to be embedded in properly. That's the first question. The second question is a note that you are saying parts of the system which you can't predict may be under stress, particularly, presumably, parts of the less developed world where communications are not as good and updating the servers in those parts of the world may well suffer as the root grows. I am just wondering what impact that will have on the introduction of ccTLD IDNs. Thank you. >>LARS-JOHAN LIMAN: With regards to the introduction of IDNs, yes, you're right. If you are going to take this the strict way of doing one change at a time, that would mean waiting with IDNs until after DNSSEC has been introduced and evaluated. On the other hand, there are already test domains in the root server system. So we kind of know that it works, to a certain degree. And I personally believe that the problems with IDNs are more on the user side, in the applications and the systems on the user side, than on the server side. With one caveat, and that is if you want to do IDNs using an alias system referred to as DNAME, that would mean -- that would mean a principal change to the system because we don't have that kind of record in the root zone today. If you want to use IDNs with the normal name server delegation, NS records as they are used in the test system and as normal zones are delegated, that would be a smaller change to the system, and it would be easier to drive that through the system. Or you could want to do it the other way around and do the DNAMES and the IDNs first and hold on and wait a bit for DNSSEC. Because I don't see IDNs as expanding the root with a large amount of data. It might double the zone, it might triple the zone, but that's still within the same order of magnitude that we already have, so we could probably live with that. But these are my gut feelings, and I give you these opinions as one of the 12 root server operators. The others may have different opinions, and you should go and talk to more people about it so you can build your own picture of it. At this meeting, there are five root server operators represented, Suzanne being one, Bill Manning being one, also John Crain and ICANN is one root server operator, and there is another one. Matt Larson, of course. >>STEVE CROCKER: Bill Manning is eager to talk. >>BILL MANNING: Bill Manning. And I believe that your statement about we can double or triple the size of the root zone is reasonable, and still do DNSSEC. So in sort of pragmatic terms, at least from our perspective as a root operator, we believe that a root zone of 500 or 700, and then do DNSSEC, is within our operational bounds. So as long as it's a slow, gradual introduction of new delegations and a slow, gradual introduction of new IPv6, then DNSSEC in July of next year is not a problem. >>LARS-JOHAN LIMAN: Yeah, I would like to continue with your second question, which was the effect on remote sites where connectivity might not be so good. >>LARS-JOHAN LIMAN: I would like to continue with your second question, which was the effect on remote sites where connectivity might not be so good. And that actually continues on Bill's answer. We have to realize that the Internet responds and grows and improves in all parts of the world. And if we were to keep the root zone at the exact size and change rate that we have today, the improvement of the general Internet connectivity would make it possible for us to serve from new areas where we cannot serve today, whereas, if we increase the size of the root zone, it becomes a balance. If the root zone grows too quickly, we'll have to stop serving places where we can serve today. If it grows gradually, in the same way as the Internet continues to improve, we can maintain the system we have today. If it grows slower than the technical development of the Internet, we can serve in more places than we serve today. So it's a balance where we, as root server operators, we continue to test and try and try to find places where we can serve. But it will lead to differences. And there's a balance where policies, ICANN policies, actually can have an impact. >>STEVE CROCKER: Suzanne. >>SUZANNE WOOLF: Sure. Yeah, as a root server operator, I'm sort of happy to point out that what we're hearing here is a -- another thing I would hope that you could go away with in your minds is that the system has been demonstrated over time to be significantly resilient, significantly adaptable. And what you're hearing is some of the discussion around how to use that adaptability and resilience to the greater benefit of growing and preserving the Internet. So this is really just the beginning of a great deal of back and forth. And I feel obligated, as the RSSAC liaison, which is a very different and slightly more official hat I wear here, that this is the beginning and fairly speculative and that we will have more concrete things to say as this conversation continues among the people with responsibility for the operation of the system: The root server operators, ICANN, and so on. >>CHAIR KARKLINS: So the last question in this series will be from U.K. >>UNITED KINGDOM: Thank you, Chair. First of all, very briefly, on signing the root and DNSSEC, I'm sorry I didn't come in when there was the opportunity. It's not a question. It's just to say that the U.K., first of all, thinks that that's been long overdue. But the plan is cautious and well thought out, and appreciate Matt's updating of us with the timetable and so on. So appreciate that. On root scaling, we also very much appreciate all the work that's been done and the very clear exposition of the issues in the reports and the presentations to us here in the GAC, which we have then circulated around our administration and got technical advice on. It seems that basically the report is saying there is capacity for extending the root, but there's not as much room for maneuver as some people might have thought. Is that a fair characterization of the situation, is perhaps my first question. Not as much room for maneuver. Secondly, I note what you say about alert points and so on. But nonetheless, there must be some expectation that there's going to be a scalability barrier which has to be encountered. And our feeling is that, you know, we should not lose sight of that in your assessing the step changes and risks and the impacts and so on. So that's a comment, whether you agree with that. You may wish to comment. The third point I guess we're making is that there's a lot here contingent on the ability of the root server operators to propagate a larger and more frequently changing root. And we -- we, the U.K. Maybe the GAC colleagues would agree -- that we need further advice on the capacity of the root server operators to meet the challenges. Fourth, final point. This may be a naive question about individual zones. Dot com has something like 60 million registrations. If there were other new gTLDs gaining sufficient impact in terms of numbers of registrations, does that become a factor in all of this? The size of individual zones, if -- once the gTLD process, whenever that is, the policy to expand it, once that starts to roll out. Thanks. >>LARS-JOHAN LIMAN: If I start from the top, the interpretation that there is room to maneuver, but maybe not as much as some would like, yes, that is the message that I tried to convey. If we continue with a barrier, I'm not so sure that there is such a barrier, because this is -- someone made the analogy with a frog. And if you try to prod the frog with a pin, it will feel the pin and it will jump away. So the system will adapt. And it's like asking, how fast can your car go? Well, it can do 150 kilometers per hour. Okay. How fast can any car go in the future? We don't know. Is there a barrier? Can you drive a car 1,000 kilometers an hour in 50 years' time? We don't know. So it's not obvious to me that there is a barrier if you just do the development slowly enough. But if you go too fast, the balloon will explode and we will run into problems. Propagating a large root zone more frequently. Yes, that is something that needs more investigation. And, well, I can only give the message that there is a balance between the size of the root and how far you can propagate it and how often. Whether a new, popular top-level domain would affect the root, actually not so much. Because the (inaudible) does not take up more room in the root zone than any other TLD. The effect it has is that because it's a very popular one, the root servers receive many queries. But the query rate is not our prime problem. We can handle the number of queries. Because by using the Anycast system and by using large servers, we can handle the number of queries per second. So that's not the big issue. So my answer is, it does not have a big impact. >>STEVE CROCKER: Thank you very much. So I think that brings this session to a close. Thank you, Lars. Thank you, Erik. Thanks very much. And appreciate all of the questions. Let's move on to the next talk. Ram Mohan, following up on the previous discussion about redirection and what the impact is. Ram. >>RAM MOHAN: Thank you. Just wait for the slides to come up. Just as a background, in -- at the Sydney meeting, the ICANN board passed a resolution that suggested that all TLDs -- redirection of additional wildcards in TLDs should be banned, both into the gTLD space as well as to recommend that into the ccTLD space. One of the sets of feedback that returned from that was a request for what breaks. We understand that there is this resolution passed. But can you explain a little bit about what breaks. So that's what this is about. If you can go to the next slide. This is the -- the SSAC advice, just the very short of it, is that redirection, wildcarding of DNS records at the top level of the domain name system causes a clear and significant danger to the security and stability of the DNS. And the next slide. What actually happens is that most basic Internet tools break. The tools that are listed up on the screen, things like spam filters and Web link validity checkers, they expect to see if a domain name, if a host name is valid or not. When a top-level domain is wildcarded, all domains underneath that -- that zone, whether they exist or not, they appear to be valid. And that breaks the fundamental functionality of some of these tools. In addition, if you look at mail that is mistyped, in today's world, you expect, if you mistyped an e-mail and you sent something, you expect to get a bounce-back message or a message that indicates that, you know, this destination doesn't exist or the user at this destination doesn't exist and you get a response back. With a domain name that is mistyped, as long as the zone is the same, in a wildcarded zone, that mail will get delivered and potentially could be read by, you know, whoever gets it. There is also an impact on search engines. The other piece is that if you look at root operators, you look at IANA or, you know, government research labs, other organizations that today monitor and look at the TLD name servers as well as zone computation, they use tools, they use applications to ensure -- to monitor the health of the system and to ensure that the system is working fine. Those tools are likely to break as well, because they make assumptions about what is valid and what is invalid. On the next slide. The other thing is also that we believe that every current and future Internet application is affected, because what you're doing is, you're taking what really is -- the intended effect of redirection is to help users on the Web who are mistyping something to take them to the right spot. So that is something that is done at the -- what is called the HTTP, the application level of the Internet. But the change itself, wildcarding is something that is -- that was being proposed, is being proposed to be done at the DNS level of the Internet, a level, a protocol, that is intentionally kept neutral. Applications that depend upon the DNS, protocols that depend upon the DNS, the way they currently are engineered, the way they might be engineered going in the future gets affected as a result of redirection. On the next slide. There is also an architectural violation here. There are some fundamental principles, one of which is that DNS itself is intended to be neutral about what protocols to respond to, what protocols to answer. In addition, if you look at future protocols that depend upon the DNS or that assume the DNS working a certain way, the design and implementation of future protocols gets affected by redirection. As an example, HTTP, Web, if you will, as a protocol, HTTP was not developed until just recently compared to the DNS itself. Because the DNS was intended and built to be something neutral and work in a neutral way, the later innovation of HTTP came through, and the -- and the DNS allowed HTTP to work in a pretty seamless way. And we believe that kind of architectural purity should remain. On the next slide. There are more problems than just what I've explained here. There's a small list right here on the screen. I'm not going to go into each one of them. But there are implications of this far beyond just the pieces that I've gone through. So with that, there are some reference documents in the next slide. It's a little hard to read here. But these slides are made available to you. There are some reference documents. And there is actually now a wealth of information about what the behavior is. And we're now starting to put together information on what happens if this advice is not heeded because things that are fundamental to the Internet actually start breaking. Thank you. >>STEVE CROCKER: Thank you very much, Ram. Julie, let me ask you to put Greg's slides up while we take a question or two, if there are any, for Ram. Thomas. >>NETHERLANDS: You want to have a question now on this subject or? Okay. One general question, which maybe I have technical background, but I try to be now more from a policy point of view setting this question. Isn't it possible to have both ways? Let's say to return to the -- the -- the one -- the part you have a inquiry to return with a message that "This domain doesn't exist" or a standard message, and also giving a message that, "Okay, there are these other options," eventually. Maybe this is a stupid question, but trying to question whether there is -- you can combine both things, a protocol and the user request. Thank you. >>RAM MOHAN: As far as I understand, if you wildcard the zone, you're basically telling every query that is coming through, especially for domain zones that do not exist underneath it, "Here is a generic response, and go here." And there is not, as far as I know, an ability to differentiate and say to just the person who asked, "Here is a real answer, and this domain does not exist," but for the others, take you somewhere else. So I think that kind of functionality is better done -- if you look at the Web, for example, is better done -- there are plug-ins that are available. And you'll find some ISPs, for example, that do that kind of redirection on the Web site. And, you know, we're not commenting about that. We're commenting about a fundamental problem, which is, if you're a top-level domain registry and you implement this kind of change, every user, every user, registrant, et cetera, underneath that chain is now bound to your changes, with no choice and with no alternative going forward. >>STEVE CROCKER: Yeah. I think that's a very key point. And it's a useful question to help illuminate that point. DNS is at the very bottom of the protocol layers. If a change is made in the registry, then it necessarily affects all the users who request and all of the applications, no matter what they are. The way to get the differentiated response that you're asking about is much closer to the user and much higher up in the protocol chain. So the proper answer out of the registry is a very straightforward, "No, it doesn't exist." It's a code. It's not even a -- you know, a linguistic format. It's just a bit set in the response message. As that message makes its way back to the user and up through the protocol chain -- layers, then the applications that are -- have made the request can interpret that and decide what is the useful answer to give back to the user and whether or not to offer alternatives and so forth. But that must be done much later and much higher up in the protocol. Is there another question? >>CHAIR KARKLINS: So if I understand, Ram, the protocol itself allows wildcard or DNS redirection. Wouldn't that be first step to do to change the protocol, and to take out this possibility of redirection before asking to do something which is on top of the technical solution. Otherwise it looks a little bit like a situation when we are asked to impose the law which does not exist. >>RAM MOHAN: Thank you, Janis. That's a great question. You know, DNS is certainly applied at multiple levels, both within organizations, across the Internet, inside intranets, other places. Redirection by itself is not necessarily evil. You find situations where redirection is actually essential. In some cases, you'll find inside of intranets or inside of corporations, they actually use redirection. And that, by itself, is not a bad thing. So I think if you're designing a protocol, you try and keep as flexible as possible. And redirection, the wildcarding by itself is not a bad thing. It is when that is used at the top level of the -- of a domain name system that the effects of it are really bad and it must be stopped. Because the outcomes of it have large-scale impacts not just for now, but for a long time going forward. >>CHAIR KARKLINS: If I may. Thank you, Ram. In fact, you are not the first whom I ask this question. And for GAC members, I -- once I got a very interesting answer which would be maybe understandable for all of us. It is about like drinking alcohol. Drinking alcohol is not prohibited, as such. And if you drink, you can easily walk away from the restaurant and nobody will say anything about that. But if you, after drinking, take your car and drive, you put in danger all those who may walk on the side, because you are not paying any more that attention. So that's about the use of wildcards, rather than wildcards by itself. So just a side note what I heard. >>STEVE CROCKER: Okay. Let me turn things over to Greg Rattray, from -- chief ICANN Internet security advisor, on the security, stability, and resiliency program. >>GREG RATTRAY: Thank you. And, Janis, thank you, and the GAC, for taking what is going to be a very brief update. I understand we are a little bit behind schedule, so I don't want to take longer than necessary. I think it's essential, at least as the lead staff person on ICANN staff, as we develop plans and programs in this area, to have a vigorous dialogue with the GAC and understand -- let you know the types of things we're thinking about, both at the planning level, as well as operationally, and then get feedback on those plans and programs. And so with that, I'll press to the next slide. The fundamental document for this has now been established. We developed an ICANN plan for enhancing Internet stability and resiliency over the past ICANN year. And it was approved in Sydney. There was a session here at the GAC where I presented the broad outlines of that plan. And the plan was approved as presented. It is integrated in our strategic and operational planning on an annual basis. So we will be doing review and update to that plan. And I want to ensure that as we do that, we are bringing that to the GAC. The first plan was very much an effort to try to get our hands around all the different very important things that ICANN has done for a long time in the security, stability, and resiliency area, get those done as a foundation for community understanding, as well as be very clear about what our planned activities and resources were in what is now the ongoing ICANN fiscal year. It starts in July and ends in June. So we're in fiscal year '10 for ICANN. Just recently, with the signing of the Affirmation of Commitments, security, stability, and resiliency is one of the four major aspects of those commitments. This plan is specifically called out as the basis for the review under the Affirmation of Commitments. So, at least from my perspective, making sure this is right, making sure this is what represents the -- all the ICANN stakeholders in terms of what ICANN is doing, certainly the views of governments related to what ICANN's role and responsibilities are, this plan is a fundamental piece of that, and therefore, you know, ask for continued engagement and will be working with the GAC to be sure -- as well as the Security and Stability Advisory Committee, to ensure that all the ICANN bodies have had an input to this plan. The current plan is available at the Web site detailed there on the bottom of the slide. Next slide. Then I quickly wanted to also, you know, inform the GAC about some of the things that are the focus areas within the ICANN staff in this area. Certainly with the continued maturation of the draft applicant guidebook and the new gTLD and IDN initiatives, we are spending a considerable amount of time hearing community concerns about mitigating malicious conduct and trying to put measures in place in the programs that will address those concerns. And we had a session on -- a lengthy session on Monday that addressed our plans currently for doing that. Also, in the -- both in the wake of Conficker, which is not done, we are continuing our engagement, particularly with the ccTLD community, related to information-sharing that enables them to continue to deal with that one very specific threat. But we've felt that that is only just -- that that is an example of a broader set of things that require collaboration in domain name system security and therefore are working in a number of venues to establish standing response mechanisms. We have within the ICANN construct a DNS Collaborative Security Response Group which would allow us to identify and begin to react to situations like the Conficker situation. The ccNSO has a working group on incident response. They have made progress between the Sydney and the -- and this meeting here, and plan to continue that work, which will be very important work ensuring that we can make a broad range of connections across the CC community when situations involve the ccTLDs. And then we're very much working with the broader cybersecurity community, particularly with a focus on FIRST, which is the global forum on incident response teams, which helps encourage collaboration is coordination with national and enterprise community emergency response team. So we feel like ensuring they understand the challenges in domain name system security and they are a place to go for everyone in the ICANN community, particularly operators that may need close-in, geographically collocated cybersecurity help. We want to ensure that ICANN's helping the CERT community provide that assistance to the DNS operational community. And then, finally, we've had a set of programs, but particularly a joint training program with the regional TLD associations and ISOC that is intended to try to increase the understanding and the capacity of TLD operators in order to improve their basic security, but also resiliency to different contingency that may affect the domain name system. So I know that was a pretty quick update. But if there's any questions. >>STEVE CROCKER: Bravo. Excellent. Thank you. Any questions? Great. Thank you. So let's move to VeriSign presentation on DNSSEC experience with dot EDU, I think is the proximate title, Ken Silva. Thank you. >>KEN SILVA: Yeah, it is. Thanks, Steve. We've talked a lot about DNSSEC, and I don't know which you'd rather hear less about now, DNSSEC or WHOIS. But right now we're talking about DNSSEC. Sort of following on with the theme we've had, the resolution piece of DNSSEC is where most of the research and development has been focused over the years in terms of how that is going to get into zone files and how ccTLDs and gTLDs will roll that down and implement that. But we were also -- we've also been concerned, as have others, with respect to the registration process and how that's going to be managed and how keys will get into the system and what that flow is going to be and where potential breakages are there. So in conjunction with EDUcause and a few of their channel parties, if you will, mainly universities, we launched an initiative to start a test bed where, basically, from -- from registration all the way through to publication, we can track where potential issues might arise. And this is really just to sort of summarize what we got from that. So we've had the test bed up since September. So really since last month. So it's been up for just a few weeks. This system is really an end-to-end test with Educause's registrars. Educause themselves, VeriSign, and then ultimately, the ultimate publication of this. So there is a registrar front end, which Educause has -- or, excuse me, which the universities have, where registrants will enter their data. That then gets handed back to the registry backend, which we operate. And then pushed out to the resolution name servers. Next slide, please. So we had a test, a number of of test points here, that was the registrar and registry interface, which is between Educause and VeriSign. We had to test the specific changes which were made to the EPP protocol which allow these changes to be made. So the EPP protocol prior to some changes wouldn't allow these DS records D go into the zone. So, essentially, that's the key material that has to get published into the zone. So we had to test all the EPP commands still functioned, all the old ones, and that we could delete and modify DS records as necessary. The registrant-to-registrar application, so there were -- there have been no major issues that have surfaced there. They simply had to add the fields for the registrants to put that data in. And then, of course, we had to deal with the zone file updates and make sure that we didn't run into any scaling issues, that we didn't run into any issues with data becoming corrupted or somehow dropped out of the system. And then, of course, ultimately, the name server resolution for those name servers that have a sufficient version of BIND to be able to do that and to be able to support NSEC3. So, basically, in the end-to-end use testing, we've been able to do all of this successful. Educause had to do some changes on their frontend because, ultimately, they're the first to receive the data. We have been able to use different cryptographic algorithms. We changed actually algorithms a couple times just to make sure that we could. We used the allowed record digest types of SHA-1 and SHA-256 so that we could make sure that we had a range of cryptographic algorithms that we could use in the registration process. And we also had to make sure that anything that wasn't supposed to get through didn't get through. So, in other words, we had to make sure that if the DS records weren't appropriately validated, that they couldn't go into the system. And then, of course, we had to make sure that the resolution worked properly once all these changes were made. And then, of course, it's got to correctly resolve after we do key rollovers. So we've been doing all of this testing in the expectation that when dot EDU is signed, after the root is signed and dot EDU, that the entire registration process isn't broken. So right now, I think we have seven or eight of their -- of their registrars, mainly, like Harvard university, Berkeley, University of Pennsylvania, Johns Hopkins University, and a few others involved in this test bed. We chose this using it with dot EDU first because we were dealing with universities who were fairly well versed in this technology. They're pretty bright people. They can leverage their computer science departments to help them through some of these problems. It's a relatively small registrar communities. It's a relatively small zone to work with. And so we felt it was a good test model to start to work with, especially in the registration process. And we're pretty happy with the testing so far. We have now -- We're now to a point where we think we've ironed out all of the problems and ultimately, when we switch this live, we'll simply be moving what is essentially a copy of the test system that we have into the live system today. That's it, unless there are any questions. All right. >>STEVE CROCKER: Very good news. Glad to see the progress there. Have you done any testing with respect to transfer of registrations? Although I suppose that's -- >>KEN SILVA: That's the next phase. That's the next phase. So we don't really have that as a huge problem in the dot EDU domain, but that's an area which we are working on in preparation for net and com. >>UNITED KINGDOM: Thanks. U.K. Is there a process of translating the best practice you are picking up to other operators, to ccTLDs and so on? Is that something you are contemplating as the next follow-on step? >>KEN SILVA: That's exactly why we are doing this now, is to learn from all of this, try to establish at least a baseline of best practices, work with others who have implemented DNSSEC to come up with those best practices now that we will have three or four that are there, and we will publish those as we what we consider to be those best practices. And hopefully the ccTLDs will look forward to reading those and applying those as they roll it out. Okay. Thank you. >>STEVE CROCKER: We took a fairly dense agenda. We worried about whether we would be able to get through it all within the period of time, and now we are in the embarrassing position of having completed early. I don't know what to do next. [ Laughter ] >>CHAIR KARKLINS: We cut short the discussion on scaling of the root. And we certainly can go back to that if our panelists on this issue would be ready to continue. So I see nodding. So there was Italy and then Netherlands. >>ITALY: Okay. Something has already been said. Okay. Of course we expect that at the end of the study, in a determinate time, you will end up with a recommended number or rate per year of new TLDs. Because this is something that the community expects, and we learned yesterday that the community got the impression or the certainty, let's say, that the start of the process connected with Doug will be postponed. And, also, another point is the connection with DNSSEC. This is a problem for ICANN. Because, of course, if ICANN could well put adopting DNSSEC in the contract with new gTLDs. Maybe this is not something to be advised. Because of course the two effects are interacting, and then increasing the load on the root server system. So I think that there is a great responsibility here to be able to advise ICANN on how to progress with the new gTLDs program, because it is quite clear that the expectation of the applications will be higher, much higher of what will be in the end, recommended number of addition of new gTLDs per year. Thank you. >>LARS-JOHAN LIMAN: Thank you. I don't really know, actually, what to respond to that. And to be quite frank, I think I am not the right person to respond, because the root scaling study team was given a task to produce a report by the steering group. And I think it's actually down to the steering group to bring the recommendation to ICANN. I can have opinions, they would be my own opinions, and I don't know how useful they would be. So in this case I would actually like to step back and leave to others to give the answers. Sorry about that, but if Steve wants to make comments. >>STEVE CROCKER: I guess I will step into the breach here, the point that you are making that everybody would be well served by having some specific number on the table and having a specific expectation I think is a message that is now pretty clear and has been socialized quite a bit. And I think it falls well within the standard guideline that one should always try to set expectations, and that that's a very helpful thing. So certainly I can say that that idea has been understood and received. I'll stop short of saying, and yes, now the number is going to be the following, because that would give me a fast exit out of here and never to be seen again. But I think that that concept is gathering quite a bit of momentum. So I'll just leave it at that. >>NETHERLANDS: Thank you, Chair. My question is very much related to Italy's point. And I think maybe we can share with you also the discussion we had with Kurt about the DAG 3, because I think at least we, from Dutch side, we have a concern that your message, how it will be taken up by the -- let's say the policy people in -- within ICANN who are, let's say, making -- or finally the DAG 3. And I think the point which we discussed there is that of course implicitly, everybody knows it won't be a very dangerous and steep amount of increasing TLDs, because the fees are high, there's application -- rather high application demands. You have to scale up the whole system, organization for it. So implicitly, it looks like, well, we don't have a problem. But in practice, in reality, I think we have to -- especially ICANN, giving message to all applicants worldwide for the next five years that there is a danger. And that even you could have a scenario -- I think the IAB said this in their reaction, that you should, at any point in time, revoke gTLDs out of the root, for example. So I don't know how you -- I understand you don't have an answer for this, but my question is more is this kind of thing also sensitized within your own community and in the direction of ICANN, also? Thank you. >>SUZANNE WOOLF : Yeah, as you say, we're not in a position here today to move that forward in any detail yet, but I do think the important -- one of the important principles and one of the things that I am taking back to my constituency, to my colleagues, is that we do have to avoid a situation where everybody thinks it's somebody else's responsibility; that the responsibility for watching what's happening to the system overall lies with someone else. And that is a formulation that we do need to take back out of these conversations to every part of the community, because there's this tendency to pay attention to our own piece of the puzzle. But one of the things we have here is a convergence of multiple policy processes and initiatives that are converging in a way where many of the effects are not clear from any individual vantage point. And that's the situation we have to learn from. And it just is my personal take- away from these discussions. >>CHAIR KARKLINS: Yeah, please. >>LARS-JOHAN LIMAN: I would also like to stress that the most important message we are trying to convey is don't enter into a situation where you cannot regulate the pace, the speed at which things happen. So don't say it's now open, because you don't know how that's going to happen, what's going to happen five years from now. So what would be appropriate to say, according to my personal view, is we are now carefully doing something where we may have to limit the pace, limit the speed at which things happen. But we are starting the process. And to reserve the right to either stop or at least temporarily make a stop in whatever process we are engaging in. >>CHAIR KARKLINS: Thank you. I have still a number of questions, so I have Singapore, then Senegal, and then back to U.K., and Denmark, and Sweden. >>SINGAPORE: Thank you, Chairman. I just want to raise the question on another topic, and that is Mr. Ram Mohan's redirection issue. I take it that the issue is with the wildcarding at the TLD level. Then how about if the wildcard is done at the client side, is the same expectation that we also have to discourage with the wildcard facilities at the client side? We do come across a few cases, and is the same expectation on the TLD to enforce the wildcard features at the client side? Thank you, Chair. >>RAM MOHAN: Thank you for the question. I think there is a fundamental difference, and your mileage might vary. Some registries might take it upon themselves to talk to application vendors and to ISPs and to actually tell them not to do wildcarding. But really, our focus is much more on the TLD level. On the application level, whatever happens, that's -- firstly, it's a little bit of out ICANN's remit. But secondly, at that point, users actually have choice. While at the top-level domain, which is what, really, we are focusing on, the user choice is removed. And that's why it's a bad idea. >>CHAIR KARKLINS: So thank you. Senegal. >>SENEGAL: Thank you, Chair. I have a question, because if I look at this study, the advisory is to start with DNSSEC. My question is at this time, how many -- what is the percentage of domain which are signed right now? >>STEVE CROCKER: Yeah, I have been keeping track. I'm sorry? Do you want to -- >>LARS-JOHAN LIMAN: No. >>STEVE CROCKER: I believe keeping track of the TLDs that are in various stages of signing. I don't have complete data right in front of me, but we're somewhere between a half a dozen and a dozen, depending on how you count, some that are in test and some that are partially signed and so forth. Sweden was the first, and then Bulgaria and Puerto Rico and Czech Republic. And the pace is picking up. But I'm not sure that that is directly relevant with respect to the question of whether the root should be signed or what the impact will be. There is a minor, small technical relationship between the number of signed delegations and unsigned -- versus unsigned. But primarily, it's an independent kind of question. >>CHAIR KARKLINS: Okay. Denmark now. >>DENMARK: Yes, thank you. We are very worried about this after reading the studies, especially as we were earlier assured that there wouldn't be any problems with scaling the root related to the new gTLDs, for example. So what are the steering committee's expectations from the board in reacting to the committee's recommendations? >>STEVE CROCKER: the prior statements about the scaling were focused very strongly on the impact of the name servers themselves to be able to handle queries and whether their memory and bandwidth would be sufficient. And I don't think there's anything in the current study that runs counter to that. The current studies have been focused considerably more strongly on the provisioning process, what does it take to put these TLDs into the root and maintain the information, what stresses are there on the IANA process, what stress is there within the constellation of Anycast services within each of the 12, 13 root operators. There's not a high degree of precision at this point as to where those thresholds are, and I think what you are hearing is an abundance of caution. It isn't -- I mean, if we started to put some real numbers on the table, it isn't clear that there would be as much of a collision as there is the prospect of. But I don't want to make -- I don't want to try to confuse things further and suggest otherwise. But I think this will get sorted out relatively quickly. Do you want to continue? >>DENMARK: Yes, but then shouldn't the studies have been made beforehand? It just seems to me this is really the ground of everything. >>STEVE CROCKER: Yeah, lots of things are nice to do beforehand. (laughing). >>CHAIR KARKLINS: So in our part of the world, we say better later than never. So U.K. and Sweden, and then I think we will bring this session to the close. >>UNITED KINGDOM: Thank you, Chair. I think Denmark's point is a very salient one. And perhaps this highlights either an institutional or a process issue that we might be touching on here, which may be resolved if the technical experts and those, in particular, on security and stability of the whole DNS do articulate some set of principles. There has been talk here of some principles that should be borne in mind when undertaking a project of this size. I mean, in addition to taking due caution with regard to the speed of implementing change that ICANN is proposing, a set of principles could be devised which set out that -- I suppose from a start point, nothing should be done to the root which creates any kind of operational or procedural instability, and that there should be a full risk and threat analysis undertaken right at the start, which is the point Denmark is I think very usefully reinforcing at this meeting. The set of principles could also require that you have some kind of exit strategy for a plan that is going wrong or the rollout of that plan reveals new stresses or the rollout coinciding with another key strategic initiative creates that stress. And that seems to be the situation. That latter situation, scenario, is what we are observing now. So maybe this is a suggestion from us that yourselves, the ICANN community, including us in the GAC, might want to look at the formulation of a set of principles that ensure that the technical and stability issues are right there at the top, at the genesis of any major ICANN initiative that's going to have such a significant impact on the root. Thank you. >>CHAIR KARKLINS: So I take that this was rather comment than a question. Sweden, Maria. >>SWEDEN: I very much like to say pretty much the same thing that Denmark said. We are also worried about this, of course, listening to the presentation. And we also listened to Kurt Pritz's presentation on Sunday, I think it was, and I actually had a question also, like you said, Lars about the speed. What kind of mechanism you can actually -- can you adjust the speed when you actually start on this gTLD process. And actually, I got a feeling that the answer was no by them, if you remember, my other GAC colleagues here, which makes me even more worried, actually. So the proposal that you have from U.K., I think it's very, very important. Thank you. >>STEVE CROCKER: I wasn't here to hear Kurt's presentation, so I won't comment on that, but I think the aggregate of the comments from Denmark, from the U.K. and yours are well taken. I mean, I appreciate the point. I'm necessarily in a highly supportive position because in addition to sitting on the board I have been chairing the Security and Stability Advisory Committee. And not everything that we say gets listened to, and so this strengthens our position in that respect somewhat. So I am pleased to hear it. I worry a little bit about overreaction, because caution is an extremely good thing. Extreme caution goes too far and undermines the credibility of the system. So I think it's important to stay sort of in a reasonable range of the right amount of caution. And that now is a trickier business, because then one has to actually know what the facts are and dig in, and we are only getting the real facts to emerge at this point. But I think the larger point is absolutely right, that the right homework should be done and technical due diligence should be done. And I think that's a fine message. I like that message a lot. >>CHAIR KARKLINS: So that leads me to the very pleasant duty to thank all panelists here. It was a very interesting and useful session for us. Thank you very much, indeed. And I believe the panelists deserve a round of applause. [ Applause ] >>CHAIR KARKLINS: Now we're breaking, and lunch will be served in this room in 10, 15 minutes, so please come back. We will have a short exchange of brief statements from hosts, from KISA. And then I ask also the representatives of law enforcement agencies to entertain us during the lunchtime, and they will tell us some stories and we will have a chance to ask them questions. So thank you very much, indeed.