Open SSAC Meeting Cairo, Egypt. 03 NOVEMBER 2008 >>STEVE CROCKER: Welcome, everybody. My name is Steve Crocker. I'm the chair of ICANN's Security and Stability Advisory Committee. This is our regular feature that we provide at ICANN sessions where we try to present the current work that the committee has been carrying out. We're getting a late start and we're going to make a little bit of adjustment to the schedule. There really are two activities that we want to cover here. One is, as I said, presentation of current work that we've done and that is underway, but the other is that this is an opportunity to interact in a -- at least to a limited extent, with us, with the committee members. I'm going to talk very briefly, just a few introductory remarks, and then move right into the substance of what we have to cover today. For anybody who has come to these meetings before, you will have heard these words before. We are an advisory committee. We don't have a natural constituency like most of the other components of ICANN. We're an external group of security experts. We try to give independent advice to the board, to the staff, to the other parts of ICANN, and most importantly, as well to the community at large. We don't have any specific authority. We can't make any rules. We can't cause anything to happen. I view that, actually, as a strength rather than as a weakness because it gives us free rein to say the things that we think need to be said, and it gives a natural counterbalance, so that the quality of what we say and the merit of what we say is checked by others. I think that's a very important part of the structure. There is a formal external review of SSAC in progress, and I will mention a bit more about that later. That's a -- required by the bylaws as a -- every part of ICANN gets reviewed on a regular basis. This is the first round. They take quite a while. We're in the middle of the pack. Several have taken place before, and there's a few more to come afterwards. Here's the current list of SSAC members. We have a kind of a very stable group in which every so often we get new people joining and some people who are leaving. I'm pleased to welcome Christophe Reverd sitting in the front row here, who is joining us, and I -- for people who follow all of the intimate little details about how ICANN works, I've been selected for the ICANN board and will be joining the board formally on Friday. I have been sitting in the dual role of chairing SSAC and also the -- filling a spot on the board as a nonvoting liaison from SSAC. I vacate that position and Ram Mohan, sitting to my left here, is now filling the liaison role, and attended his first meeting yesterday and doing so very ably. Are there any other changes? I think that's the only substantial changes. Who are the SSAC members who are here? It would probably be helpful to identify. Jim Galvin on the staff sitting there. Patrik Fältström. Whose hand is that? I can't see well enough. Daniel, is that right? And, oh, Jeff Bedser, and Shinta and Ray Plzak, our vice chair, and Suzanne Woolf and Roberto. All right. Robert. Thank you. We're a shy crowd. We just sort of melt into the background. We have a number of other people who participate: A number of people on the ICANN staff and various invited guests and liaisons from other groups. We've been producing a batch of documents. Dave Piscitello, to my immediate left, is the principal author of these. They just come out -- they just keep getting cranked out on a regular basis, and I commend them to you. Each of them is intended to be quite substantive and, hence, worth reading. They don't make very many headlines. Maybe they should. In red at the bottom is the pointer to the Web site. It's on the ICANN Web site under the committee structure. Today, we're going to have a presentation on -- very briefly -- updating DNSsec statement that we started last time. We're going to truncate that, in the interest of time. A very interesting report on protecting high-value domain names, a report from Ram Mohan on the rise of phishing attempts against registrars. Kim Davies, to my right, on addressing DNS vulnerabilities. This is the follow-on, or the results of the Kaminsky work identifying how to attack DNS ever more efficiently. Dave Piscitello on fast flux and DNS. And then Greg Rattray, who is buried back in the middle, introducing new initiative within ICANN on security, stability and resiliency efforts. And with that, I'm going to turn things -- well, no, I'm not. Two related meetings coming up. I mentioned that there's an external review of SSAC. The external team is going to be meeting in an open session Wednesday morning in this room at 8:30, and that's their meeting, not ours or mine, but I'll be here. And then we have a DNSsec workshop, a very, very packed, content-full agenda. There's proposals to sign the root zone, there will be a brief address by Ms. Fiona Alexander, the NTIA associate administrator. There will be presentations by TLD operators and some product development activity. Microsoft made an announcement last week and we're going to get to hear more about that very directly, so it will be a quite full and substantive agenda. That will be in the main room downstairs, I believe, at 1:00 on Wednesday. And so with that, let me turn things over to Dave. We have a new and improved system that we haven't figured out how to use yet. Okay. Thank you. >>DAVE PISCITELLO: Okay. Thank you very much, Steve, for introducing me. I'm Dave Piscitello. I am the senior security technologist at ICANN, and full-time member of the SSAC. Before we start, I just wanted to add one other related meeting to Steve's list. This evening at 6:00 in the Al Manial Room, there is an impromptu e-crime birds-of-feather session where some members of the anti-phishing group, a representative from the FBI, and several others will be talking about e-crime and some of the relationships between e-crime and the domain name system and registration services. And I think that will be fairly interesting. It's going to be very free form and I encourage you to attend. The first of our presentations today is on DNSsec, and earlier in the year SSAC had produced and published a statement to ICANN and the community on deployment of DNSsec, and what we attempted to do in that statement was identify issues and make recommended actions for several groups of people: IANA, the gTLD and the ccTLD registries, registrars, and then we also took on some homework assignments of our own. There were seven key areas that SSAC agreed to study, and what we were attempting to do was evaluate the readiness of DNSsec in these key areas. The key areas in green are those that we have actually made some progress in: Implementation and deployment testing, end user application development, and availability of DNSsec features on nameserver platforms. So I'm going to focus primarily on those, and as Steve has indicated, we are running very short on time so I will not go into too much detail on this. This is an interim statement and we will have a report probably in the February time frame of 2009. One of the things that we attempted to do early this year was do a survey of how many nameserver implementations were capability of supporting DNSsec. We contacted 40 nameservers. It was a vendor assertion survey, not a test or any other sort of evaluation process. And we asked them about three particular areas of interest: What RFCs they supported, what interoperability tests that they had performed, and what ancillary tools they provided in the realm of key management, encryption, and administration. We received vendor assertions from 13 commercial vendors and approximately 17 products. Unfortunately we did not receive much responsibility -- or I'm sorry, response from the open source development community, so one of our tasks ahead is to try to get more engagement with that community. If you go and you look at the summary, you'll see that approximately 65% of the commercial products that responded support DNSsec. Five of those products support NSEC3, and eight of the product developers had indicated they'd done what we considered significant interoperability testing. Of the 17, 11 products also offer some form of key management applications and DNSsec aware utilities. If you visit the SSAC Web site, you'll see in the report and the publication three tables. One illustrating the RFC support and some of the granularity of support that we asked in our questions. One on interoperability testing. And one on key management, encryption and administration. We'll continue to add these as we get additional vendor assertions and open source community responses. The second area that we had some very substantive and positive testing results for, was in the area of implementation and deployment testing. And here we had an outside agency and some staff at Nominet in the U.K. do testing of 24 residential Internet routers and SOHO firewalls. And the devices were selected based on most commonly used devices among broadband service providers. We used the control test bed to determine whether each unit did -- correctly route or proxy any number of DNSsec queries and DNSsec-related queries and responses. I won't go into details here, but the report is published on the SSAC site and it is quite detailed. Every one of the test procedures, the entire test methodology, is documented and all the raw results of the tests are also available for download. A quick summary of the test findings, again, I'll highlight here is that all 24 units could route DNSsec queries addressed to upstream resolvers. That means a resolver outside the little box that was the middle box where the Internet provider -- provided access to broadband service, without size limitations. When we started to look at how the proxies in these routers and firewalls actually performed when they are in line and doing some sort of DNS participation or processing, we had varying degrees of success. If you further go down, one of the things that we felt was very significant is that only 25% -- one in six -- of the units could operate using the default settings and process, you know, with any form of DNSsec compatibility. That means that a lot of subscribers or a lot of service providers are going to have to actually go in and make some changes as to the implementations as -- or the installations as they've currently implemented them in order to make subscribers, you know, have unfettered access to DNS service when DNSsec becomes more prevalent. So that's a significant result that we have to pay attention to, and we've already seen some vendors who have seen this report, you know, reply to us and indicate that they'd like to have us continue doing some testing or continue to test themselves to make certain that their products can process DNSsec in the future. The final area where we've done initial exploration is in the area of end user application development. Most of this information is relatively informal, communication directly with, you know, developers and vendors of end user applications. One of the things that we have discovered is that currently DNSsec is not a part of the standard operating system in application builds in the Linux community. There is no Windows OS support in XP or Vista or Windows 2008 server currently, but if you attend the DNSsec session on Wednesday, there will be a presentation by Microsoft and you'll hear some more recent news about what Microsoft has planned for both server and client implementations with respect to DNSsec. You can find DNSsec resolver and validating libraries available as open source or custom builds for Linux, BSD, Solaris, and Mac OS X and there are validation libraries or patches or RPMs -- you know, packages -- for Firefox, Thunderbird, several FTP clients, an IPSec client called OpenSWAN, which is very popular, and OpenSSH. The four remaining items that we have, you know, a fair amount of work to continue to explore are in the areas of protocol completeness, key rollover processing, trust anchor repositories, and performance and error analysis. Okay. I think in the interest of time, I'd like to hold questions until the end and, you know, certainly I'll be willing to stay and talk with anyone who wants to ask any questions about any of the presentations I give, and I imagine that's true for any of the other speakers. The second presentation I'm giving today has to do with an area of study that SSAC began following the spate of security incidents relating to domain name hijackings over the summer, and one of the things that, you know, many of the members were discomforted by was the degree to which some of the recommendations we had made several years ago in a domain name hijacking report illustrated that some of the recommendations that we had made hadn't been fully embraced by the community and that perhaps it was time to look again at the entire registration process and take a look at what kinds of measures might be available or used to improve the registration process and further mitigate or further reduce the probability that, you know, high-value domain names would be hijacked. So let me begin with a definition of a high-value domain. There was a suggestion yesterday that perhaps we should call this "mission-critical domain" as opposed to making an assertion that there's some monetary value associated with the name. And we'll take that into consideration. But our working definition is that a high-value domain is, you know, one or a set of names, a portfolio, so to speak, which define an organization's online presence. It's also a set of domains that an organization expects to register more or less forever, and without interruption. For example, any of the Fortune 100 companies would gladly pay, you know, a serious amount of money to never have to worry about reregistering any of their domains in their portfolio and I think that there are probably some small organizations that would do so as well. Essentially it's a name that an organization cannot do without. It's online presence. You know, it is defined by that name. So it has a particular value as a to the organization, or the organization. Unfortunately, that also makes the domain a high-profile or attractive target for hijackings or attacks or defacements or some sort of statement against the organization. The three attacks that we felt were significantly high-profile illustrate that it happens to a lot of different industries. Comcast, you know, had an attack where the attacker impersonated a Comcast technician and convinced the registrar support staff to reset the administrative password, and then the attacker modified the DNS and used DNS hosting to do a Web defacement and interrupt Web mail services. ICANN itself had a similar incident where an attacker gained control of a domain account via ICANN's registrars, and the attacker redirected traffic to a protest Web page. This happened during the ICANN Paris meeting. PayPal.com had a very, very significant, you know, registrar error where, as a consequence of a request to take down certain phishing domains, the name "PayPal.com" had been taken out of service and as anyone can imagine, a domain like PayPal.com not resolving is a fairly significant event for a company like eBay. So one thing we've concluded -- and we're not interested in pointing fingers and we're not interested in calling out names and saying bad things about anyone -- is that everyone in networking makes mistakes and registrars are no less prone to errors than any other business. That doesn't make it easy for us to explore all the dimensions of the problem, but it does make it less adversarial. The questions that we started to ask were in the nature of what curative measures, you know, what sort of preventive measures could we consider as a community that would allow the holders of high-profile, high-value domains to have greater assurances that their domains would not be hijacked. So we started looking at the kinds of measures that a variety of registrars offer today, and tried to determine whether the minimalist set is sufficient, whether the broadest set is -- you know, is complete, and tried to understand in sort of a matrix I've illustrated in kind of a pyramid figure how do you actually fit the kinds of services that are available today with the willingness to buy and the need of various customers. The way we've conducted this study so far is that we've interviewed representatives from the attack victims, the registrants and the registrars -- because both are victims -- and then we also expanded our net to speak with some registrars that offer protective measures that are not typically seen when you go to a registrar who is more or less a high-volume, high-transaction registrar. We are going to continue talking with some of those kinds of registrars and we're also going to talk with some medium-sized and large organizations that have high-value domain portfolios but currently view the cost of some of the top tier or the brand equity management registrars more than they -- more than the risk justifies. So the idea was to examine the existing and candidate measures and complement those with measures that, you know, we came up with in the committee looking at some other models for management, to see whether there are better measures for protecting against unauthorized access, unauthorized transfers, internal staff or process errors, bad acts by disgruntled employees, to try to provide avoidance mechanisms, to prevent nonrenewal or deletion of a domain name, protect against DNS configuration abuse, and improve and maintain information accuracy and integrity with respect to registration records. Our initial findings is that there was actually a pool of -- you know, or sort of a bipolar distribution -- bimodal, rather, distribution of the kinds of registration models that exist today. You have a basic service and the basic service is relatively inexpensive. It's oriented to consumers. The emphasis is on a high transaction rate, and the processes are highly automated. Human intervention is usually only for exception handling and is not something that the business, you know, seeks to have, you know, a high number of. At the other end of the spectrum are these premium or extra protection services. These are usually offered in a package or a bundle along with some sort of brand equity protection. They're actually companies that do this that are not registrars and there are registrars that do this. The emphasis here is on handling individual transactions with a low probability of error, and the human assistance or confirmation is often a mandatory aspect of the service. When we started exploring beyond what we saw being offered today, one of the things that we attempted to do was look for other models in understanding how to manage the risk associated with domain name portfolios. Now, an obvious set of management models exist in security in asset and risk management. So if you start with the premise that a domain name is an asset and you start with the premise that customers must treat anything that is an asset within the context of a threat model, you have one way to look at, you know, domain name portfolio security. You can also consider provisioning management. You know, DNS configuration is a vital aspect of the way that organizations operate when they have domain names, so dropping DNS, dropping the ball on configuring DNS is a very, very problematic task for any organization. And so it became obvious to us that we had to not only look at the registrar, but look at the registrant, and see whether there were measures that we could recommend to people who were managing domain portfolios as a partnership between the registrant and the registrar. One of the things that we looked to do was to identify some possible measures for registrants that would allow them to create checks and balances within their own organizations. So without going into the detail of all these items, examples would be having multiple parties identified in the administrative and technical contacts in a registration record, and requiring that those multiple parties both receive and both process a change request to any aspect of a domain name registration. Similarly, any aspect of a DNS configuration. In addition to that, you know, we also thought that it would be useful to include contacts for domain name registration in the employees resource management process, so when a company fires an employee, if that employee happened to be, you know, one of the administrative contacts, the ERM process ought to be able to flag and say, "You need to change the domain name record." That's just an example. We thought the registrars could offer complementary services in this range. Especially to improve authentication, you know, forcing a multifactor authentication would be valuable for a registrant. Requiring multiple identities as contacts and registrations might also be a valuable service opportunity for a registrant. Notifying multiple contacts upon any implementation of a change or prior to an implementation of a change is something that might be valuable to a registrant, that a registrar could offer. Okay. The similar kinds of treatments exist for preventing loss of domains and transfers and nonrenewals, so the basic process is to have checks and balances each leg of the path between the time when a request comes in and the actual change is executed, to make certain that the change is one that is authorized and one that was -- should be permitted by the parties that are making the request. The same kinds of checks and balances exist for protecting DNS configuration, and the same recommendations apply here. When we looked at this, we realized that there might be an opportunity for a third business model. Today, if you look at the business model, you see the costs are very, very low in one grouping of registrars and the protection is commensurately low, whereas there are a very small number of players where the cost is very high and the protection is considerable or very, very high. What we're suggesting is that maybe there's some play in the middle where you provide significantly more protective measures over the high-volume, high-transaction kind of registration service, but not something that is so expensive that it is beyond the reach of small and medium businesses. So, you know, we're talking about something that is in the hundred dollars a month range -- I'm sorry, hundred dollars a year range as opposed to hundred dollars a month range. And that would be affordable for a lot of people and would be something that a lot of companies might -- you know, might be very interested in, if they could get, you know, a good set of protective measures that would relieve them of worries of hijacking and loss of presence. Our next steps are to continue interviewing HVD owners and registrars to try and isolate and identify some small and medium-sized businesses and talk to them about the validity of our premise, that they would be interested in this and then also to discuss the feasibility of these broader range of protective measures with more registrars and resellers than those we've already talked with. And, again, we are not looking at this as a policy initiative. We are looking at this as creating some industry buzz or some industry interest in perhaps expanding the kinds of opportunities that exist for registrars in terms of registration services and protections. And that's it for that one. I think Ram is up next. >>RAM MOHAN: Thank you. Following up on Dave's presentation on high-level domains, we wanted to speak for a few minutes with you about the registrar phishing threat. And some of it is material that we've covered before in earlier reports, but it's particularly timely given a new rise in -- or an increased tide of phishing attempts aimed at compromising domain name accounts. Typically criminals target -- they phish registrars to steal names or to steal accounts. And the reason that's valuable is because you can create phishing sites which obviously help make them a bunch of money and help you lose a bunch of your money. And in general, phishing, as you know, hurts consumer confidence, customer confidence. It decreases the trust in online commerce in general. It hurts brand name if your domain name got phished and got taken over and something unsavory got put on it and at the end of the day it costs real money. As I mentioned earlier, SSAC has provided a number of reports that are primarily focused on registrant protection. These are -- you can get the actual reports up on the SSAC Web site, but you'll find the reports going down from 2005 all the way to now and the high-value domain report that went up as well. If you look at the recent phishing attacks from October 29, a few days ago, Network Solutions reported a large-scale phishing attack and eNOM was also targeted in the phishing attack as is moniker. All three of these are domain name registrars accredited by ICANN. Between them they have in excess -- in accounts I have seen, in excess of 10 million domain names under management. So it is a pretty significant number of domain names that could indirectly come under threat. October 30 of this year, just, again, a few days ago, especially with Network Solutions, registrars and registries took concerted effort and actions at that take down most of their identified phishing domains in this set of attacks and this is a process that worked quite well. To get to some details, the lure from Network Solutions, the bait that was put out there, the subject line said, "Attention, your domain name will be expired soon." As you know, that's usually a pretty good give-away, bad grammar and bad English. The e-mail body says, "Renew domain now" and the link points to NetworkSolutions.com. But when you actually look at the link that goes to Network Solutions.com.com42.Asia. So, clearly, it is another domain name. But even for casual -- at a casual glance, it looks like it is a NetworkSolutions.com. The URL is listed in the new URL. The eNOM lure, the support@eNOM.com was the e-mail address. The subject line says, "Inaccurate WHOIS information." As you know, ICANN has a process by which registrars are required to connect with registrants if there is a complaint about inaccurate WHOIS information. That's being used obviously by phishers to go and compromise domain names and accounts. The message body -- in the message body, there is a link that says, "Please verify your contact information." The link says eNOM.com. Actually points to eNOM.com.com62.biz. A couple of common factors. All of the domain names that seem to be involved in the phish seemed to follow "com" and then two numbers. They used dot Asia, dot mobi, dot biz that has at least been reported. In a quick study, we certainly found domain names in com, net as well as info, org, all of the major gTLDs. Registrations were made. We don't know if they were made by the same registrants. We know this for sure, many of the major gTLDs definitely get targeted and some of the ccTLDs did get targeted as well. So as you can imagine, when you click the links, it takes you to a fake set that's dressed up to look like the actual registrar site, including the logos and the SSL, you know, trusted by whoever signs, et cetera. And it requires you to type in the username, password combination. At least in the ones that were tested that have been reported, you type in the username, password combination obviously that's been captured and then that returns an error code. And it says, please give more data, you know, and asks for more credentials from you. By the time you're done, you have given your credentials, all of your identification information and you've basically compromised yourself even to the point where if a domain name registrar asks for a specific validation and other information, if you've actually gone through this entire process, you've handed that information over. So that's the -- that's what happened. So we have some recommendations, many of these, you will find them pulled from our other reports that we've done since 2005. Most of these are not exactly brand-new but they are very relevant. For registrar or reseller, we recommend that you upgrade your -- review and upgrade your account access methods. Dave in the prior presentation about high-level domains was talking about multifactor authentication. Two factor or more is a good thing to do and it ought to be done. The other thing is to create some sort of a mechanism, if it doesn't already exist, of a three-strikes-and-you're-locked-out system. I found in at least a couple of registrars, not the ones mentioned but a couple of other registrars who were accredited, the username is the e-mail I.D. which can be gathered from looking up the WHOIS record for a domain name, okay? And the password, it actually -- it does not have a lockout after a certain number of attempts fail. So theoretically, you could get one of these free software programs and launch a dictionary attack on the account and compromise the account. So that's obviously not a good thing. We suggest that you create some sort of protection mechanisms and alerting mechanisms if you are a registrar or reseller. We also have in the past recommended the creation of an emergency action channel at your organization. It is a channel that has a 24/7 ability to provide intervention when problems are detected. We also suggest -- have suggested, we recommended if you are a registrar or reseller, please acquire emergency contact information for your registrants. And also establish some sort of validation criteria from these registrants. And in terms of mails that are going out in an earlier report, we had suggested that, you know, you think of implementing digital signatures or some sort of source validation method so that people who are getting the e-mails get trained to expect that e-mails coming from the authoritative source shall be identified in an identifiable manner. We also suggest that, you know, that if you're a registrar or reseller that you train your support staff on dealing with social engineering efforts. In more than one case, we found that high-level domain names or other domain names have been compromised, not by hacking, not by some, you know, sophisticated or primitive online efforts. It's been done by a social engineering attack calling up a support person on the phone and making it look like you are actually the owner of the domain name. We also suggest that you define and communicate the procedures if a domain account has been compromised, what does the compromised owner have to do? How do they establish who they are? And then how can you actually go and get the domains back for them if they have been stolen, transferred or lost in some way? We have some suggestions in the registrar impersonation phishing attacks report and the anti-phishing working group has also issued a best practices report for registrars that provides a set of specific guidance on things that a registrar can do when they're a target of being phished. For registrants themselves, some -- what seems common sense suggestions but it is amazing how much this is still being ignored, if you get an e-mail and it has a Web site link in it, don't click on it. Find the address and type it into a Web browser yourself. Yes, it is a little more work but at least you are pretty sure where you are going, for the most part, if you type it in yourself. Get upgrades to your software or download plug-ins in your e-mail software that will actually automatically identify phishing links. In fact, you know, on the -- out here on previous slides where I was putting the links, my e-mail client would not let me -- with my presentation software as well as my e-mail client would not actually let me put the phishing link in there. I had to type it in. That's a very good thing. And these are available from your software vendor. You should just get that and apply it to your software. If you are going to a registrar Web site and you are going to be giving information in there, make sure you are on a SSL-protected page. That at least means the communication to the registrar is encrypted and typically on an Internet Explorer browser you will see that with a lock symbol. Keep in mind that some of the more sophisticated phishers now issue their own certificates and you will get a similar lock except they are giving encrypted information to the wrong guys. This next recommendation will probably cause you a little bit more inconvenience, but we suggest do not store your credit card information at your registrar or reseller. What's in your control is far easier for you to exercise some caution over. And as Dave said in his prior presentation, identify, you know, what domains -- if you have a portfolio of domains, if you are a company, if you are a corporation, an organization or even an individual, identify what are your mission-critical domain names, names that would seriously harm you or your business if you lost them or if they got stolen, right? Make sure that they get renewed ahead of time. Ask your registrar to lock these domain names for you and follow several of the recommendations that we've put out in the high-level domains report. These are fairly straightforward things that you ought to be doing already but if you aren't doing it, now is a pretty good time to get started. And, of course, select -- select someone who is reputable, select someone who's -- who has a good history of doing stuff. You can research most of this online. In summary, phishing itself is not new but obviously the threat seems to have gone from simply losing your domain name to losing your entire account. And if your account is gone, then, you know, obviously names can get transferred in, transferred out. You don't have control over your entire portfolio. So it is kind of expanding. So that's -- the effect of it can be pretty significant. Please exercise care when you're registering or renewing your domain names. If it is an important domain name, you know, there is no reason for you to keep renewing it one year at a time, unless you are trying to get a 40-cent discount, which if it is a high-level domain name shouldn't be a consideration. Please exercise care in disclosing your access credentials to your registrar and reseller accounts. Clicking on an e-mail and then going to a Web site, not checking where it actually takes you is not a good thing. You can get hijacked. You are going to get hijacked if you don't exercise sufficient care because the bad guys are out there and they are clearly trying to take over -- they used to be -- they used to try to take over your domain names. They are now trying to take over your accounts. And just please exercise care. Thanks. >>STEVE CROCKER: Thank you very much. We turn now to Kim Davies from ICANN. >> JAMES GALVIN: A question in the Adobe connect for this particular presentation. Kieren has a microphone. We have a question from someone in the Adobe Connect room from Robert Guerra: Are non-profits being considered? He asks because high-level domain names, you know, many have high-level domain names but would not be able to afford hundreds of dollars a month for protection. >>RAM MOHAN: I guess my first thought is that it shouldn't cost you hundreds of dollars a month. Some of the practices, locking down your domain names, renewing them ahead of time are fairly straightforward and transferring a name to a reputable registrar if you are not at a reputable registrar right now are now high-cost approaches. You know, in earlier reports we had also suggested if you have an authorization code, you know, what's called the AuthInfo code for domain names, we find in some cases registrars use the same authorization code across multiple domains. If you are a registrant, go in and ask for that code to be changed. That's a password to your domain name itself. But at least from our perspective, a high-level domain name is, a mission-critical domain, are not automatically linked from a lot of money being extracted from you unless you lose them, of course. So, you know, the measures that we're suggesting, we believe, are kind of the basic measures that you can take without costing you extra money. Certainly there are registrars and others in the marketplace who offer extra protection for extra money and, you know -- and as Dave said in his earlier presentation, you know, there is perhaps an extra -- a new area where service providers can think of offering specific services aimed at noncommercial sector that have -- and offering them at a lower price. But, you know, most of the suggestions that we're making are suggestions that don't cost you either any money or cost you very little money. >>STEVE CROCKER: Let's take one more question and then move on. For the transcribers, will you say your name as well. >>MIKE RODENBAUGH: Mike Rodenbaugh, I'm a councillor on the GNSO. I appreciate your comments today and the report's focus really seems to be harm to the registrant and obviously that's significant harm. There is also a broader harm when those domains are then, in turn, used for phishing attacks on a broader community which could be quite a higher magnitude than the harm to the registrant. And I'm wondering whether SSAC or any of you personally have a view -- I know you recommend things. You don't have the mandate to require things. But the GNSO potentially does. I'm wondering if you have a view whether the harm to the community, existing or potential, might mandate that some of your recommendations become requirements on registrars. >>STEVE CROCKER: That's a very interesting thought. I'm not sure I can give you a direct response to the way you phrased that. But you open the door to a possibility of a GNSO policy development process, for example. Let me ask you to repeat that thought in other settings. I mean, hold that. That's kind of -- that opens a large door and, and I think we can find other times and other places to go through that. The focus here is really on the identification of a specific threat and the broader consequences beyond the already-large-enough consequences that we see in phishing against the registrar, I think, is worthy of a separate exploration. So thank you, Ram. With that and keeping in mind the press of time here, let me thank you and we'll move on to Kim Davies. >>KIM DAVIES: Thank you very much. What I'm intending to do with this presentation is to talk to you about the DNS cache poisoning vulnerability that became well-known, you might know of it as the Kaminsky flaw. It became publicly known after our previous meeting in Paris. It was certainly something discussed in the corridors during the meeting. But in that time it has certainly taken on a life of its own. Before I start, I want to put in the caveat that this presentation is designed for a management audience. But being a SSAC meeting, I realize many people here live and breathe the DNS protocol so I wanted to apologize. I have done some great oversimplifications in this presentation to get the essence of what we are talking about out there rather than being exactly correct on the technology and the terminology. So how do you attack the DNS? Well, it probably helps by explaining what the DNS is and how it works. That's an interesting error message. [ Laughter ] The DNS is a question and answer protocol. A computer has a question that needs an answer to. It sends off a query. In the simplified model we have a computer asking the question "where is ICANN.org"? In response, it gets an answer back "ICANN.org is at this I.P. address." That's conventionally how the DNS works in a very simplified way. The protocol is quite simple. It sends one packet to the server and one packet back. So when the question is sent "What is the I.P. address of ICANN.org," the computer when it receives a response back it looks at the nature of the response it receives back. It has certain fields and certain information in the response it receives back. If those pieces of information match, it trusts that the answer received is correct. The question -- the answer might not be correct but as long as those elements are of the response received matched, then it is deemed to be correct. But this is the Internet, and the Internet provides many different ways for traffic to be inserted, to be intercepted and rerouted. And that's really sort of broadly what we're looking at in this vulnerability. So by intercepting or impersonating that response coming back -- and if you can match those certain elements of the response -- the answer is trusted. So let's look at -- sort of an example of how that would kind of work. The computer again asks the question, where is ICANN.org? It sends it off to the server that it expects a response from, but it gets a response back from another server. I have colored it red, but this is sort of the server that's trying to introduce bad data into the DNS. So it sends a response. The computer got a response. It matches the criteria for a response, and it accepts that as the answer. Now the computer originally I sent the question to will respond with the correct answer but vulnerabilities like this rely on the fact that the answer received by the correct computer actually arrives later than the answer that is sent by the attacker. So the DNS doesn't have any mechanism to allow for a later answer that might be correct to overtake the wrong answer. But all these kinds of vulnerabilities rely on the attacker getting that answer back quicker than the authentic server. So that's, basically -- very, basically, how one would attack the DNS. But the twist is that to improve efficiency, DNS servers at ISPs, at network boundaries and so forth, often store the results of DNS lookups in a cache. The reason this is done is to speed up future DNS lookups. Rather than sending a request across a network every single time you need a question answered, if you store the results the first time you need a question answered, you can look at your local copy to introduce time-saving and better performance. And this is very typical. It is what's done at every ISP, every corporate network. Now, if an attacker can do the attack I showed in the last slide by getting that wrong piece of information trusted by the querying computer and then that piece of information is cached, that incorrect result can be repeated over and over and over again. For example, in the context of an ISP, that ISP might be tricked into remembering the wrong answer and that wrong answer can then be served to all the customers of that particular ISP. Therefore, one successful attack, whilst just in response to one individual query can have an effect, that can poison many different users by having that incorrect result stored in the cache. Now, I'm going to be a bit more detailed than the previous slides to show exactly the attributes of a question and answer that I actually checked and what implication that has. When a question is sent to a DNS server, it contains an origin I.P. address, it contains an origin source port number and obviously it contains the destination I.P. address and the destination port number. This is kind of like an envelope and address where you have the "to" name, the address, and on the back you have the sender name. It also has a unique reference number and it has the actual question that's being asked. So this example we have 1.2.3.4 to 2.4.6.8. The reference number is 12345. The question and answer are the same as the previous examples. Now, the first thing that should match is the "from" address of the question. It should be the "to" address to the answer. It is two computers talking to one another. Where it comes from is where the answer should go back to. Similarly, where the original computer sends its question to should be where it gets the answer from. That reference number that I mentioned should match in both the question and the answer. And, also, the question that is being asked should be the question that's being answered. So those four general attributes of question should be matched in the answer that's received back. Now, there is many different combinations and different ways those numbers can be implemented and represented. It is useful to now look in the context of working out how possible it is to do this kind of attack. So look at how easy it is to guess and what the number of different combinations are for those different fields that I mentioned. Firstly, the from I.P. address from the response is roughly about one in three. It is actually the number of name servers for a particular domain. On average, there is about 2.4 name servers for an average domain on the Internet. There is 13 name servers, for example, for the root server. But the probability there is roughly the number of name servers for a particular domain. The "to" address there is 1 in 1. You know the I.P. address of the computer you wish to attack so, therefore, it's not a problem for the attacker to know what that number is. Now, there is about 65,000 different combinations of that reference number that goes in the question and is in the answer response. That number is the most diverse number we have and the hardest to guess in a DNS transaction today. In full randomness for that number, there is about 65,000 different combinations, so you have got about a 1 in 65,000 chance of guessing that number correctly if you wanted to try and attack that answer. Port number, the "from" port number in a typical DNS transaction is 1 in 1. It is always port 53. Similarly, 1 in 1 for the destination, the source port number, where it comes from, where it goes back to. And then, finally, the question, if you know the domain you are trying to attack, you know the domain name that you're trying to attack so that, again, is a 1 in 1 probability of guessing that particular field. So all up there we have really one random number in all of that and the rest is relatively easy to guess in the typical scenario. So what's been discovered about this recently? Well, a security researcher, Dan Kaminsky identified there is a relatively straightforward way to flood the server with lots of answers. All those combinations can be exhausted very quickly so you can actually achieve that right combination of those different fields very, very quickly. In fact, in just a few seconds. And the way it works -- I won't go into any great detail, but you query random hosts within a particular domain that you are trying to attack. You send multiple queries. Eventually one of those will be successful. How successful? Well, this is a graph produced by an expert in the field showing actual real-life tests where he tried to attack a server. He tried to attack it many different times. It is a plug. It is a histogram how successful he was in executing the attack. The median time to execute an attack based upon those numbers is 1.3 seconds. So within 1.3 seconds on average he was able to compromise a server for a particular domain. Obviously, if you are really lucky, you get that combination quite quickly and it might be a fraction of second. If you are more unlucky, it could take six, eight, ten seconds. But on average just 1.3 seconds. Now, it is worth mentioning here the impact this can have on authoritative name servers. Authoritative name servers are slightly different configuration of name servers to recursive name servers. Recursive name server which is largely what we are talking about here are those name servers that sit at ISPs that remember the results of DNS lookups for efficiency purposes. The authoritative name servers, on the other hand, are those name servers that know the contents of a domain. They are the ones that are being queried to find out what is the contents of dot com, what is the contents of your domain. If those name servers actually share both responsibilities, that vulnerable portion of recursive name servers can actually influence the authoritative portion of that name server and have a wider impact than it would on a typical recursive name server. The basic net result of this is that if you have shared responsibility from recursive and authoritative, you can actually insert a modified domain data within the domain insert on an authoritative name server. So that's a brief summary of what the issue is. So that's a brief summary of what the issue is. I'm now going to talk about some of the short-term solutions and then the longer-term solutions to this problem. Firstly, I showed you the different fields in a domain name packet. Most of those are not random. There's 1 in 1 chance of guessing it correctly. Very easy to do. But there are ways to increase the amount of randomness in some of those fields. Firstly, that transaction number, that 1 in 65,000 number, that quite possibly was much easier to guess in the past, but that risk was identified quite some time ago, and most, if not all, DNS implementations have a highly randomized number in that field. Secondly, I mentioned port 53 earlier. Port 53 is actually the port number for the DNS service that's been assigned by IANA. However, it's only required that the destination port be port 53, not necessarily the source port. So we have two copies of that port number but only one of them needs to be 53. So if you randomize that source port, you actually add some extra randomness to the query. The patches that you've seen for this particular vulnerability in the last few months have mostly focused on randomizing that source port, so it adds extra randomness to the packet. So if we look back at this slide that shows the different randomness -- randomness of the different fields, by randomizing that port 53 as the source port from the originating computer, you actually increase the amount of randomness there by an additional 1 in 64,000 or so. It varies from implementation to implementation. The second thing you can do is disable open recursive nameservers. One aspect of this attack is by allowing someone outside your network to use your nameservers. It actually makes the attack much more easy. So turning off open recursive nameservers is a definite improvement on your exposure to this particular attack. It's actually a very good idea to do this anyway. There's other kinds of attacks, such as denial service attacks, that can be executed by having open recursive nameservers, so irregardless of this particular vulnerability, it's good security practice anyway. Thirdly, one thing that's been discussed is to add uppercase/lowercase differentiation, to add additional randomness to a query. Conventionally, as part of the DNS protocol, domain names themselves are not case-sensitive. If you type in Google.com in lowercase, Google.com in uppercase, it should arrive at the same place. However, in the actual transmission of that question and answer across the Internet, it is case-sensitive, and it should be preserved on the exact same casing on the way through the server as when it comes back. And by utilizing this preservation of the capitalization of a domain, you can actually add a little bit of extra randomness that way as well. I'll give you just a quick example. So again, here the computer is asking for ICANN.org but some of the letters are capitalized, some are lowercase. Now, in the original attack scenario I showed, here's the attacking computer sending its response but it hasn't got the correct capitalization. So under this methodology, if it's implemented, that would get thrown away. When the original -- the correct server responds and it has the correct capitalization, that would then be accepted as correct. So if we add that into the mix as well, we've added a bit more randomization. Roughly speaking, the amount of randomization there is the number of bits available is the number of letters in the domain, so here we have eight letters. You know, ICANN.org, so that's two to the power of 8, that's 256. That's going to vary quite substantially, depending on the length of the domain. The longer the domain is, the more variability in the capitalization you have and the more secure it can be. So the net effect of these short-term solutions I mentioned, with the un-patched server prior to this vulnerability, if we went back six months, we had roughly 16 to 18 bits of entropy, so you had about 2 to the power of 16 to 2 to the power of 18, a combination of different variables in those domains, and by introducing these measures I just mentioned, it's 32 bits or more, depending on the length of that domain. By having more combinations that an attacker needs to try, quite simply it makes these attacks harder and these attacks are less viable when more different combinations are required. But it does not prevent -- to be clear, if you guess those right combinations, you're still going to be able to successfully launch an attack. None of these proposed patches or workarounds solve the problem. They just make an attack more difficult. And we know that computing processing power increases as time moves on. We know network speeds increase over time. Therefore, the amount of packets that an attacker can send to a computer, the amount of responses it can generate are always going to increase over time, therefore making these kinds of attacks more viable. So let's look at long-term solutions. If we know that these short-term solutions aren't a long-term fix to the problem, we need a fix. And the fix is adding security to the DNS. The DNS was not designed, necessarily, with security in mind. There's no system in place historically in the DNS to be able to certify that the data that's received is actually correct. DNSsec is designed to do that. It's designed to ensure that the answer received wasn't tampered with in transit, and ideally there's no way for an attacker to impersonate that response because it can be cryptographically asserted that that response is not correct. And basically, this attack provides a clear incentive to deploy DNSsec. DNSsec is a technology, as we all know, that's been around for many years. In fact, about 15 years. But this is the first time that I've seen in the community that people are rallying around it as a solution to a problem. We now have a very viable attack method with DNS. DNSsec is a way of introducing security to the DNS to make such attacks unrealistic. I wanted to talk a bit about my area of the world, which is top-level domains. In IANA, we operate the DNS root zone and we interact with top-level domain operators every day. Once we became aware of the vulnerability, we scanned all the authoritative nameservers for the top-level domains. We found at that time there were 72 top-level domains that had at least one authoritative nameserver that was providing open recursive name service, and at that time almost all of them were very vulnerable to this attack. There was no patch implemented. They had very weak randomization of those different fields. ICANN at that time contacted all those 72 top-level domains. We explained the situation. We encouraged them to fix it quite urgently. We made them aware there would be public announcements of this vulnerability in the near future. We provided advice to some of those top-level domains on how to implement solutions to the problem. As you know, there's a lot of top-level domains in emerging countries that don't necessarily have the technical skills to deal with these kind of issues, so we tried to assist where we could. And in the event that the root zone actually needed to change to remedy the situation, we expedited those and made them go as quickly as possible. Another thing we did is we implemented a checking tool. Initially when we did those scans, it was a manual process. We were contacting all those top-level domain operators more or less manually. Many of those came back and asked, "Can you rescan our servers? Can you check again?" This was becoming a bit burdensome so we refactored that tool. Instead of being something we ran manually, we made a Web site where they could just go to and run those tests over and over again. This tool is not necessarily top-level domain specific, I should add. It can be run on any top-level -- any domain. So just a quick screen shot. The Web site is available at recursive.IANA.org. You simply type in a domain, hit submit, it will scan that and provide a result. And the way it works is relatively simple. Firstly, it checks does the nameserver provide recursive name service? If it doesn't, it's deemed safe. There's no way to execute this attack by poisoning non-recursive nameserver, because a non-recursive nameserver doesn't have a cache. If it does provide recursive name service, it then checks the randomness of the source port. If it's deemed that the source port is random, it's marked as "vulnerable." As I mentioned earlier, we know that even if you have a patched server, it is vulnerable. It's just more difficult to execute an attack. However, if there's weak randomization or no randomization, we then report the nameserver is highly vulnerable. Much to our surprise -- and this figure is about a month old. It wouldn't surprise me if it's much higher now. We've had over 100,000 domains tested with this tool. So for something that was designed for a very small community of top-level domain operators, the response has been quite high. So our work continues on this vulnerability. There's still some top-level operators that haven't been patched, that haven't remedied the situation. Some of them are not in a position to apply immediate fixes. For example, the nameservers that are vulnerable are not under their control, or that have her obstacles to having that fixed. Our goal, of course, is to reduce the number of top-level domains to zero that share authoritative and recursive name service. It's anticipated we'll revise our technical requirements for top-level domain nameservers to prohibit open recursive name service. That's likely to be a change we'll implement sometime next year, assuming that the community agrees. And of course as mentioned, the long-term solution to this is DNSsec. We're working on signing the root zone. We're working on many -- on DNSsec as an initiative for many different fronts and I want I won't talk about that in any detail because there is a workshop later this week. So hopefully I've illuminated some aspects of the vulnerability. It's really, quite simply, there's not enough combinations in the combination lock on a particular DNS answer, and it's very easy to exhaust all those different combinations very quickly. We can add more combination locks but it's still a problem. We need something better. So thank you. >>STEVE CROCKER: Thank you very much, Kim. That's very helpful. These attacks have been sort of a major eye-opener. We've been pushing DNSsec and it took us a long time to figure out how to structure these attacks in order to get some attention. [Laughter] >>LOUIE LEE: Steve, could I ask if there are any questions? >>STEVE CROCKER: Oh. We have a question in back. >>LOUIE LEE: Hi. Thank you for that presentation. My name is Louie Lee, and I am the ASO Address Council chair. I wanted to mention that while, with these short-term/near-term fixes, the attacker would need to guess at the numbers, there has been presentations recently in the operator community that an attacker may not have to guess, as long as they couple this attack with an attack where they route the traffic, the actual DNS query, through their own network first and then redirect it back out. Then they actually receive the information and can fake a response. So this highlights the importance -- I don't want to scare you, so much as highlight the importance why we need to drive towards a long-term solution much faster, because it is possible to couple this attack with another attack to get around the short-term solution. >>STEVE CROCKER: Thank you. That's -- you're singing my song there. Anything else? Okay. So we move on to a discussion about fast flux activities, an attack of a different sort. >>DAVE PISCITELLO: Okay. So we've taken sort of a long and winding road in studying fast flux. We began somewhere in the summer of 2007 discussing fast flux hosting in DNS with the APWG, with Spamhaus, and our original characterization of fast flux attacks was that fast flux was an evasion technique, and there were, you know, several characteristics that at the time appeared to stand out and distinguish, you know, a fast flux attack. The two most prominent that we could see at that time were the frequent changes of nameserver records and the use of short times to live were typical indicators of the potential abuses of domain name services. So one of the things that we concluded early on in the process was that automating changes to DNS information and changes that set longer minimum TTLs for nameserver A records were -- appeared to be effective in reducing the number of people who were going to use fast flux attacks. Since that time, we've done a lot of studying and a lot of collaboration with several other groups, and we've developed a much more robust picture, you know, in parallel with the community, studying fast flux, somewhat intently. One thing we've learned is that not all fast flux attacks are really fast. In fact, some of them use rather normal or typical times to live. And so that was one very, very interesting indicator for us. Another bit of information that we obtained along the way in studying networks that used short times to live was that we could find short times to live in nameserver records in legitimate production networks as well as attack networks. We also found that in several production networks, they changed the IP addresses of their nameservers fairly regularly and those characteristics that started to emerge made us pause for a second and say, "You know, our original set of characteristics don't distinguish attack networks from production networks very well. They're too coarse and too few." So just to give you some quick examples, you know, if you go and you look at AOL.com or gmail.com or IRS.gov, ackanai.net, these are all examples of production networks that either have short times to live in A and C name records and longer times to live in nameserver records or they have short times to live in A and C name records. Now we decided, "Well, let's step back a minute and start to think more using the attacker mentality." So if we're going to, you know, adopt the know-your-enemy approach that the Honeynets project has adopted in the past," we started to think more about the personality and the tendencies of attackers. So most attackers think, you know, in the following manner: Why should I use my resources when I can use yours? And if I need a public IP, well, any public IP will do. I don't have to find one that is necessarily going to trace back to me. If you go to a very interesting site called Robtex -- R-o-b-t-e-x -- .com, you can do some fascinating lookups and get some really interesting graphs of DNS traffic flow through nameservers for a particular domain. And if you go to Robtex and you look at eBay.com, you'll discover that they have multiple IPs in their assigned IP allocation blocks. So in this particular case, you'll see that there are six A records in one ASN, and all those A records are from IP allocation blocks that are assigned to eBay. Similarly, if you go to look at dupont.com, you'll find that their IP addresses span multiple ASNs. Neither of these networks are attack networks. One of the distinguishing characteristics that you quickly observe if you look at dupont.com's name, or IP addresses and ASNs, however, is that there are no consumer broadband allocation blocks that Du Pont uses regularly in their routing. In you go and you look at a sample fast flux attack domain, you'll see that the nameservers are running on dynamically assigned IPs; that there are many IP addresses from consumer broadband allocation blocks and these are hosting either proxies or they're hosting Web servers; and that the IP addresses span multiple ASNs. We're still in a sort of area of gray with these IP addresses and ASNs. However, if you go and you look at some of the networks that have been taken down that were demonstrably fast flux and taken out of service by registries and registrars as a result of, you know, law enforcement and takedown organizations, we're talking much larger numbers. So if you look at betcasino.com here, they have 377 ASNs. That's a whole lost more than what Du Pont and eBay are using these days. If you look at the number of unique IPs per domain, they're looking at, you know, order -- 1500 to 1700. So one of the things that we can start to think about is, wow, this is a very different scale than what you typically see in enterprise networks or in large production networks that are using these same characteristics. The findings we draw from these are that certain techniques associated with fast flux are common to attack and production networks, but there are additional characteristics that we can start to study that allow us to positively identify and distinguish attack networks from production networks. The characteristics have to do with the member nodes, with the distribution of the member nodes, and with domain name registrations. As part of some of the work that the GNSO fast flux working group has done and as part of continuing to study, you know, characteristics of fast flux attack networks, we've come up with a fairly long list now that -- of characteristics that may be present. Perhaps not all of them, but many of them that help us distinguish attack networks from, you know, production uses. Typically, you'll find network nodes running on compromised hosts. This is not the case for eBays and Du Ponts of the world. You find that the IP addresses change frequently via DNS and low TTLs. You'll find that the distribution across multiple ASNs is fairly significant, very large. You'll find that there are multiple IP allocation blocks that are present and that many of those IP addresses will have IN-ADDR records that point back to consumer broadband allocation blocks. If you look at the WHOIS carefully, the domain registrations are typically recent -- for some value of recent -- the contact information quality and accuracy is poor, and often, the registration was either fraudulently altered as a result of compromising a domain account as we discussed earlier or purchased using stolen credentials, and then later having the registration information modified so that you couldn't trace back to the original credit cardholder. So why do we -- we also wanted to pay attention to why good actors fast flux, and there are some legitimate reasons here. Fast flux is actually a really, really cool networking technique. It allows you to do resilient and adaptive networking and these are very desirable characteristics in networks that want to remain online 99.999% of the time. We do know that the good actors use these three characteristics that we've talked about here, and that the good actors also exhibit some good acting behaviors. They typically use IP space that has been assigned to them. They typically don't hack other actor systems. They don't hack into registrar account log-in pages. They don't use stolen credit cards. And they don't host name and Web servers on dynamically assigned IPs. So we're building up a -- you know, a fairly good distinguishing model here. This has helped us focus a little bit more on the kinds of things that we'd like to study in the future: Ways to reduce fraudulent registrations, ways to accelerate domain name suspension and algorithms and automated means of detecting names that are used in fast flux attacks. A little pause here. So here's an example of fast flux detection formula. The formula says that I can determine whether or not a network is a fast flux attack network by multiplying the number of unique IP addresses I've identified by, you know, a factor of 1.32, and then adding the number of ASNs I've identified as being participating in this network by a factor of 18.54. If the result is greater than 142.38, then the network is a fast flux attack network. The accuracy of this -- you know, this algorithm has been fairly dramatic, and it's being used today by a number of organizations that do, you know, track and identify and bring fast flux attack networks to the attention of law enforcement and to the attention of registrars and registries. Now, a lot of people don't like the notion that automation is the only way you identify and take down or suspend a domain. But you can complement automation with other factors that help you get a little -- you know, a little bit more or better quality result, and so manual inspection, along with the automation, tends to provide you with greater confirmation. One of the things you can do is you can go to URL block lists and you can see whether URLs, you know, that are associated with that domain are already being phished and already being identified by anti-spam and anti-phishing software and are being added to block lists. You can check to see whether or not the nameservers are actually, you know, operating at the addresses that are listed. You can check to see whether the domain name records contain things like an organization of FDSDKMQPLM -- or any other kind of mumbly information. And so there are lots of -- you know, there are lots of ways to ratchet up an automating method to have an even greater degree of certainty and comfort among people who don't want to see a domain name suspended incorrectly. So I think you can get a very high accuracy rate out of the complement of automation and manual inspection. That's pretty much a summary of where we stand at this point. I'd like to hold the questions until Greg Rattray has an opportunity to give his presentation and then I'll be happy to stay and answer questions for anyone. But thank you very much. >>STEVE CROCKER: Thank you very much, Dave. We started this session fairly late because the welcome ceremony ran over, and we are -- we've made up some time but we haven't made it all up so we're going to run over a little bit but we'll try to hold it here. So I'm pleased to introduce Greg Rattray from ICANN, and I'm just going to turn things over to you but we've got to get your presence up here, don't we. Let's see. So that's this, and then... This. There we go. >>GREG RATTRAY: Okay. Steve, how long would you like to try to keep this to? We're about 5 till. >>STEVE CROCKER: Yeah. You wanted 20. If you can do it in ten, you're a hero. [Laughter] >>STEVE CROCKER: But I think it will be self-limiting, right? We're going to watch -- >>JIM GALVIN: Microphone for Greg. >>STEVE CROCKER: Yeah, this is your microphone. >>GREG RATTRAY: My voice generally projects fairly well. >>STEVE CROCKER: But we've got -- >>GREG RATTRAY: Right. Steve, you know, I think what I'll do is I'm hesitant to -- the speed at which I'm going to go through this at a 10-minute level is going to be pretty dramatic. I will start off with the statement that I actually think what's happened here on the panel is illustrative of how we approach Internet security, which is: We've spent a lot of time on a lot of key issues that are fairly technical, practical, you know, Level, but the whole is not overview. You know, one of the things that I'm trying to work on within ICANN right now is understanding ICANN's general role in Internet security, so I'm going to go through that kind of holistic view in a pretty rapid fashion. I put the statement in the ICANN bylaws right up front on the slide. This presentation is a subset of a longer presentation I've used both with the board and with the SSAC membership to try to get our hands around what is the framework by which ICANN, you know, manages and hopefully conducts its activities related to Internet security, stability, and resiliency. I would argue that the bolded portion of that statement is one of those things that you see in a lot of constitutional statements which could have either a narrow or a broad interpretation and that it's not, you know, patently clear exactly how broad or narrow ICANN's remit is in this regard and it's something that the organization needs to work with its entire community and stakeholder base in order to define. I will highlight an issue that's come up kind of in a couple different ways already in the deliberations at this panel. This, I am going to go right through. Basically, what we are working on is, you know, a framework for terminology -- security, stability and resiliency -- that tries to focus, in addition to misbehavior not occurring, the notion that the system itself needs to be resilient under stress. I'll talk a little bit in a couple of other slides about the particular, you know, focus on resiliency and, you know, the notion that ICANN has a responsibility, as the coordinator of the unique numbering systems within the Internet, to ensure that those systems are resilient as critical portions of the infrastructure. And a -- with a limited, you know, effort that ICANN can apply organizationally, you know, where is its relative focus among all the bad things that happen in and across the Internet and where should ICANN focus its activities. At any point, you know, those who would like to give me feedback on these working definitions, that would be appreciated. One thing that I thought was useful to do, ICANN has initiated a strategic and operational planning process. One thing I thought that was useful to do, ICANN has initiated a strategic and operational planning process and I thought it would be useful to just identify what is in particularly this year's operating plan for ICANN. One thing I would state to the community at-large is these plans are meant to be, you know, reviewed, inputs taken. There are processes both at the committee -- or the advisory committee and supporting organizational level for input as well as the community as a whole to input these. We are already starting the next version of the strategic plan, so we would like the community to provide input on what ICANN is going to work on in these areas. So specific to security -- and this is the mandate that I have within the staff organization -- is we are culling out and going to issue a document that outlines what we believe our role is in the broader security, stability, resiliency space and that document is in progress and in part built on some of the things I am talking about today. It is still probably a few months away from any sort of public dissemination and, you know, comment period. But we definitely plan to do that. It clearly identifies a community-wide effort in order to do that. We have also begun the process of trying to work with all the people, including the good work that's done internally within the SSAC, on DNS risks and how to mitigate, you know, trying to wrap our head around the entire DNS system and the different types of risks, both technical and operational. And we plan to hold a symposium. We are shooting for the February '09 time frame for that. It is a work in progress. We've started to identify kind of the key themes and outputs from that symposium. We've initiated a couple of different efforts in the top-level domain space, in the country code space. We have a workshop program that brings in managers and hopefully eventually the technical personnel from the top-level domain ccTLDs in order to provide them information about attack mitigation and business continuity planning in order to increase their capacities, particularly in those that don't have deep pockets for these sorts of activities. In the gTLD space, there is a registry continuity plan; and there is going to be a registry continuity exercise building on some activities that occurred over the last year. And then, finally, also within my remit is to make sure that ICANN does its own business well in terms of security. I want to point out, really the bumper sticker across the bottom talks to what would be the left-hand side of the slide which is while there are some specific initiatives in ICANN's plans for security, there are a whole set of activities that go on in the advisory committee and across the staff and other supporting organizations and advisory committees. And one of the things that's challenging for ICANN, as the profile of security and resiliency rises and ICANN's accountability to its community and its stakeholders, whether they be commercial, governments, the registries, registrars themselves, is that we need to make sure we wrap our hands around all the different sets of activities that are going on from what Kim Davies does with DNSsec and the activities in IANA through the types of activities that I'm doing vis-a-vis what Steve and SSAC has led in terms of the advisory committee. This was a build slide. As it got PDFed it now actually comes across as obviously a single slide. I am going to jump off. Can everybody still hear me? I will speak up. Just real quickly, this was a notion as we worked internally to ICANN to try to get -- thanks Ram -- to try to get our hands around what is core and directly under the control of ICANN in the blue. What particularly through direct contractual arrangement -- agreements, contracts we have with the kind of core set of people within ICANN and the RIRs but particularly the registries and registrars where a lot of the focus has already been today, as parts of subecosystems within the larger Internet and addressing within the DNS, that ICANN can't solve all the security, stability and resiliency problems for the Internet but that it needs to focus on what it's directly responsible for, what it can partner with its community to help solve in the systems that are directly within its mandate and then service the larger Internet community as a whole. It is really a conceptual framework to guide how we organize and focus and prioritize our activities. So -- I'm actually doing better than I would have thought, though we haven't started the dialogue on this. I identified in this kind of review of how ICANN conducts its activities and the types of things we're doing and the types of things we need to take on a set of strategic issues that I did brief the board in the vein of issues, not solutions or answers at this point. And really I say this, we are in a phase of trying to take active consideration of are these the right issues? What are the range of approaches that can be taken to managing these issues? Some of those are internal at the top of the slide, issues are internal. There is another slide in addition to this. But for your awareness of the type of issues that are being presented in terms of how ICANN should play its role in this area, there is again a number of things that ICANN directly has an influence over through its operations. One of the things that we're striving hard towards is more of a risk management approach to how we conduct our operations. There are a number of things, some of which have been discussed already today. And certainly DNSsec will be gone into in even more depth during the course of the program here in Cairo but also there are a number of -- root zone management, I think, has been touched on but certainly is an active dialogue both operationally and at the policy level. ICANN does a number of things operationally. The core question that I've been struggling with is the question that was raised -- I actually had stepped out briefly and when I came back in, the issue of what are the requirements for registrars, also I would say registries, in terms of dealing with some of the security phenomenon that were raised today. I mean, should registrars have to do X, Y or Z? ICANN's arrangements with the registrars is, basically, governed by the registrar accreditation agreement. What is the nature of the provisions that should be in these agreements, contracts with the registries, registrars, other elements of the ICANN system that speak to security, stability and resiliency concerns? That is a community -- Steve kind of punted that issue, and I think that was appropriate. In some ways, that is the issue that I'm also highlighting here. That is a community determination as to what the specific nature of those arrangements should be and one that needs to be engaged in. Then, you know, the further set of strategic issues that have been raised, ICANN operates most effectively in terms of when it partners with others to build energy and consensus through the community to grapple with problems. In the security/stability area, it works with ISOC and training programs. It works with and is part of the IETF and issues regarding DNSsec and RPKI and the implementation of the right protocol structure at ICANN's level to enable the community as a whole to improve their security. One of the things that's clear, at least in my mind, is that the stakeholders set for ICANN does include governments and we need to work with governments in both critical infrastructure protection and law enforcement realms as we have already in order to make sure that those facets of what ICANN -- that ICANN is a contributing player in making sure that infrastructure as a whole is resilient and that it contributes to efforts to tamp down malicious activity. Instead of reading all the bullets on the bottom of the slide, again, we're in the process of developing an explicit strategy and plan for how ICANN engages on Internet security, stability and resiliency issues and that we'll be soliciting the community's input on that. One of the things that, I believe, we've started to talk a lot about, but we haven't come to an answer on, is the focus on the Internet has unique identifier systems, and those systems are central to the ability of that system to function; i.e., they need to be stable and resilient in order for the Internet to work. And that really is the focal area and the appropriate place for ICANN to focus its effort. Will it continue to do the types of things that it has done? Particularly in the efforts that have been reviewed today and coordinating with the anti-phishing working group and understanding issues of fast flux so that people throughout the system can do the right things to protect themselves, I think the answer is patently yes to that question. I think the question is, you know -- the relative balancing across all three areas of activity that ICANN plans to do. So, Steve, I was, I think, 13 minutes. >>STEVE CROCKER: Heroic effort. Thank you very much. I was pleased to see that everybody is still here, and the other fear that I had was that there was another meeting waiting to happen but apparently we have not been booted out. So we can take a few minutes for questions if you're interested in any of these presentations or on general SSAC matters. The floor is wide open. And lunch awaits, I can tell what's -- Mike. >>MIKE RODENBAUGH: Just a real quick question. You mentioned they are planning to take community input on a document. I am just wondering when you're expecting that. >>GREG RATTRAY: The question was we're working on, as called for in our operating plan, a strategy for ICANN's role in Internet security, stability and resiliency. My intent is to, I would say, before the Mexico City meeting. You know, it hasn't been determined whether the board will review it and it will be out for public release prior to that meeting or maybe, you know, that would be something that would occur at the Mexico City meeting. But I think that's the timeline that's been discussed. >>STEVE CROCKER: Anybody else? Barbara. >> BARBARA FRAZIER: I was wondering whether the SSAC committee itself, or council itself, has done a tremendous amount of work in understanding what the security and stability and I would say also resiliency issues have been over the years. I would hope that -- this is to you. I would hope that actually one of your major efforts would not be to reidentify or reestablish or redo any of the work that's already been done but rather to establish and define a mechanism for how we would incorporate perhaps new requirements into the registry or registrar agreements. And have you given any thought to that? This goes back to Mike's comment a little bit earlier in terms of some of the security steps that are actually quite easy to make or changing defaults and so forth when perhaps domain names are registered. Have you given any thought to what the procedures are or will be or could be? >>GREG RATTRAY: To the first point, I have talked a lot with Steve and worked with Dave. I agree that we need to take the work that's already been done and the types of strong practices that Dave's identified in his reports. Then the question is to enter those into basically the policy-making process within ICANN that determines things like the Registry Accreditation Agreement and have the community work out what's appropriate to be contractually mandated in an agreement like that vis-a-vis what might be provided. And I think a useful thing -- and this is Greg working off-the-cuff and that's something I discussed a lot -- is more effective education awareness. The types of things that have been identified need to get out to the full set of registrants and registries, even if they're not mandated activities that the market itself through better information, you know, might result in more secure behavior for those that choose to go that route. And those are the types of things that I think we have to explicitly deal with in this strategy and identify kind of where ICANN, you know, mandates versus where ICANN enables. Does that kind of get to the question? One thing I can't say, I can take the list of practices that have been identified and -- and drive those through to some mandates down into the registry, registrar communities because that's not how ICANN functions. That's not how those agreements are formed. There should be an input to those processes. >>WENDY SELTZER: Thanks. Wendy Seltzer speaking here as an individual here. I want to thank you for the good work, good technical analyses and good analysis of how this fits in with community work and ICANN's limited role because many of these security problems, as you've identified, have false positives and legitimate activity that can be misidentified as unlawful or abusive activity if merely automated processes are used to find it. And so while there is an important role for the algorithms and the automation in analyzing and assessing problems, we need human review and it is often more appropriate, I think, for these to be voluntary self-protection measures than mandated from the top everyone-must-adopt measures that may then lock out legitimate activity. >>STEVE CROCKER: Thank you. And Dennis behind you had a question. >>DENNIS JENNINGS: Dennis Jennings is my name. I'm an ICANN board member, but I'm speaking personally and definitely not on behalf of the board. Many of the things that I've listened to are of the nature of better locking your door, better securing your property. And I'm interested from the perspective, the ordinary man in the street. And I imagine that that perspective is that, you know, there are bad guys, there are criminals out there. And I'd expect that there would be more than just locking the door would be done. There would be detection and prevention and arrest and punishment associated with breaches of -- with criminal behavior of this sort of nature. Now, I know it's not ICANN's role but I am more concerned -- I'm concerned about what ICANN is doing to make effective the whole cycle of security, which is from protecting yourself through detection and arresting and stopping the criminal behavior and suitable -- it is not ICANN's role -- but suitable intervention to prevent these individuals, these criminals proceeding. >>STEVE CROCKER: I'm going to take that because you've touched on a topic that I would think is large, important and one that, I think, is quite appropriate. You're absolutely right that what we focused on in these presentations and what we generally focus on within SSAC is preventive measures of the form of better locking of doors and better architecture, both operational practices plus improvements in architecture. But you are completely right that that's only a piece of the spectrum and that the rest of it has to include the legal framework and the law enforcement framework. Mr. Kamel made reference to exactly that, I think, in his remarks this morning. And I was very pleased to see that. There is now -- this is Crocker speaking personally as opposed to an official position of SSAC or board or ICANN or anything. But my view is that we do not have a strong enough international framework in place yet. There is cooperation that has developed over a period of time. Law enforcement authorities are generally more and more cooperative over time. We don't yet have the maturation in that process and the uniform coverage over the world that, I think, is a necessary part that goes hand in hand with the global coverage of the Internet. And that's something that ICANN can only be a portion of the solution, can't be the control. ICANN has the interesting position, possibly positive or possibly hazardous, of being one of the most visible and perhaps the only visible organ that appears to be part of that solution. But there certainly has to be more, and I think that's one of the interesting challenges in front of us all. Question from back there. >>MIKE O'CONNOR: My name is Mike O'Connor, speaking as an individual and Obama fan. [ Laughter ] Just to add on to your comments, Steve, I think another thing that would be very helpful as a leadership role for ICANN to play, you talk about improving the international cooperation. I think another area that ICANN could really take a leadership role in improving cooperation is in the security community itself. One of the things that we ran into in the working group was that it was very hard to get good information early on. And if we can encourage more sharing amongst some of the people who are gathering information, not just the security providers but also registries, registrars, et cetera, et cetera, so that we can get better identification, more quickly based on higher quality data based on better analyses, that will also move the ball forward. >>STEVE CROCKER: I think that's a great comment. And let me pass that over to Greg with a very pointed comment. There you have, I think, a pretty good suggestion for input to your symposium in February. >>GREG RATTRAY: I think that's fair, both as input to the symposium and also input into the more general what is ICANN's role in general security. Certainly taking leadership in the passing of data to the appropriate, you know, mechanisms, analyzing these threats I see as not problematic and not resource implications but we certainly should be able to do that. >>STEVE CROCKER: Good. Going once? Going twice? Lunchtime. Thank you everybody. [ applause ]