SSAC OPEN MEETING 23 JUNE 2008 PARIS, FRANCE >>STEVE CROCKER: Welcome, everybody. This is the public session on the Security and Stability Advisory Committee. My name is Steve Crocker. I'm the chair of the committee. Sitting next to me is Dave Piscitello, our senior security technologist. Is that the new title we have for you? >>DAVE PISCITELLO: Yes. >>STEVE CROCKER: I got it right. And Jim Galvin with his head down on the screen there is -- handles all the logistics, our exec. I'm going to very briefly do an intro, and then we'll dive right into some substance here. How many people here have been to one of these sessions before and have -- know something about what SSAC is? (Raising hands.) Good. How many of the rest of you are here for the first time and are interested to find out what SSAC is all about? (Raising hands.) There is at least a couple people worth saying this for. Here are the things we are going to talk about today, an update on the DNSsec statement we talked about before and two substantive presentations that Dave Piscitello is going to share with you. One on registrar impersonation used in phishing attacks, and the other is on DNS responsible modification. So what are we about? We are an external group of security experts formally within the byzantine structure that is ICANN. If one reads and is attentive to the nomenclature, in addition to the staff and the board, there are what are called Supporting Organizations and Advisory Committees, often abbreviated SOs and ACs. So the Supporting Organizations are relatively big operations, the GNSO, the ccNSO and so forth, Address Supporting Organization. And the Advisory Committees are, in a certain sense, lighter weight, although that's not an absolute bright line there. The Governmental Advisory Committee is fairly hefty operation. So within that constellation of different committees and Supporting Organizations, we're the Security and Stability Advisory Committee. We're unique in that we didn't exist beforehand and don't have a natural constituency. All the other components, whether they're SOs or ACs, sort of represent existing operations of one sort. The Root Server Advisory Committee comes out of the preexisting root server operators Governmental Advisory Committees are representatives of different governments. We are wholly artificial in the sense we are constructed out of thin air from the thought it would be helpful, we think, to have advice and expertise related to security and stability, let's go make one. And in the fall of 2001 and the spring of 2002, the committee was assembled and chartered and have been in operation since spring of '02. Our role is to give independent advice., we don't necessarily speak the party line, whatever the party line might be. We give advice to the board, of course, but also to the staff, to the other organizations and to the community at-large. We have no statutory authority. Nobody has to come to approval for us and there is -- nobody that has to listen to what we say. In a way, that's actually quite a good thing. I take a certain amount of comfort in that because it doesn't put us with the burden of having to have absolute correctness in everything we say. We can -- we can do the best job that we know how to do and then if something goes wrong, we get to say, "Well, but it wasn't our fault, it was your fault for listening to us," right? [ Laughter ] And I say with a certain tongue in cheek, but there is a very serious component to it that I strongly believe in checks and balances in systems. And this is a very natural check and balance and operates in the more subtle way that amongst ourselves if we were inclined to go far afield and say something outrageous, we would know before we finished saying it that it was going to be ignored, and then it would lower our credibility. So there was an internalization of that feedback loop which is appropriate, I think. Plus, we have diversity within our group. And I can tell you for sure that we don't all think about things the same way. So that's the -- our general structure. What do we think about? What do we focus our attention about? Very commonly they are topics that are generated internally. If one reads the charter, it looks like the board tells us what to do and we go off and think about it. That happens occasionally but it is not the norm. More often, in fact, almost all the time, we identify a problem, we think about it and then we issue reports. We've evolved a scheme of identifying our reports into three types. One we call reports. Another are lighter weight and hopefully more quickly developed. Things we call advisories. And third category are documents that we call comments that are comments on other pieces of work or other documents that have come out of other systems. So they are reactive to other work, as it were. There is a review process for all of the components of ICANN required by the bylaws. And that is working its way across the spectrum of ICANN activities. The first one was the review of the GNSO. There is a review of ALAC that has just been posted. There is a review of the board that's in progress. And our turn has finally come. And we're at the very earliest stage. We're drafting terms of reference, a RFP and none of that has become visible yet. That's the preliminary work. That's just starting up, so I invite anybody who has thoughts about us to participate in that and there is multiple ways to do, including there will be some very visible public ways but there will also be -- feel free to approach me or anybody else privately. Here's the members of the committee. That's interesting. The red dots there are leftover from earlier slide where the names corresponding to them were in red which indicated they were new. But those people are no longer new and, I very quickly turned everything black, I thought, except I didn't get the dots turned into black. So next time I will fix that. That's sort of the trace of -- Johan Ihréren, who was a very valued of the member of the committee for a long time has rotated off. Otherwise, it is accurate. I will fix this and get it posted correctly. Too many people to introduce in great detail, but I can assure you this is a very distinguished group of people who one of the most distinguishing characteristics is they all have day jobs that none of them are doing this as their primary activity and they're not getting paid to do this. They're not bureaucrats. They're not attorneys. They're not politicians. All technically rounded. Let me ask the SSAC members who are here to raise your hand or even better, stand up for a minute. Patrick, Rodney, Suzanne, Russ, Shinta, good. And I should recognize Ken Silva who slid into the back of the room who was on the committee from the beginning and the main contributor for a good long time. We have a number of other people who are participate, a number of ICANN staff. I have introduced Dave and Jim. Who else is here? Let's see, Greg Rattray, and Barbara said she was going to come. There is Rick Lamb back there. The lighting is funny. Who else? Did I miss somebody? Okay, good. So that's the end of the introduction about what we're about. Let me now shift into a different topic entirely. I guess I could take questions if somebody wants to ask a question, if there is any -- going once? Going twice? All right. A while ago we issued a short report on DNSsec, so let me say -- let me back up and say a word about DNS security. In the earliest part of our existence, we spent quite a lot of time, we had identified DNSsec as a key protocol that needed to be fostered in advance. And after a while, we came to the realization that it was bigger than we could pursue within the confines of the committee the way we were structured. And we set up a parallel activity, basically, from two points of view. From inside the ICANN perspective, it is under the purview of SSAC. There was very substantial funding from the U.S. government to -- and here, full disclosure, Russ Mundy at Sparta and me as CEO of Shinkuro are recipients of Homeland Security funding to push the deployment of DNS security. So there is a very substantial level of activity both within the ICANN arena and outside. There is a parallel session that we have run almost always at ICANN meetings and this week's will be Wednesday -- what time Wednesday? >> DNS security? >>STEVE CROCKER: 1:00. It is a jam-packed session. 2 1/2 hours of quite a lot of material. Recently we said, okay, it is also time to kind of reassert the relationship between SSAC and the DNSsec activity and have a SSAC statement about the readiness and status of DNSsec. We published a short report and we promised that we would say more. We're not quite ready with all of the pieces of that, but what I want to do is give just an update on what we said we were going to do and how far along we are on that. So our Report 26 says that we'll review the readiness and completion of DNSsec and evaluating several issues, protocol completeness, the key rollover process, and proposals for trust anchor repositories and so forth, implementation and deployment testing, performance and error analysis, end user applications and available of DNSsec on commonly used DNS server platforms and we would report to the community. This is the first of two slides with the quick status on each of those pieces. So we haven't yet started on the protocol completeness. The key rollover process is defined. An RFC is published; nice piece of work. On the trust anchor repository, there is a trust anchor repository white paper that is now published and available for comment, and discussions are in progress. There is also, I should say, a separate mailing list for the DNSsec deployment working group and anybody who's interesting in this topic, I commend it to you and suggest that you join and there is a separate Web site, www.DNSsecdeployment -- DNSsec-deployment.org. Including dedicated test servers and so forth, I wrote "not yet started." Some of the work has started but it is more accurate to characterize it as kind of at the beginning. Performance and error analysis has started but no report yet. End user application development, some has started and is slow. Availability of DNSsec on commonly used DNS server platforms, there is an ongoing survey and early results published in SAC Report 30, that is available on the Web site. And I think that we're going to try to wrap all this up and deliver on what we said at the November meeting in Cairo. We've been doing survey work on a little bit of a nasty problem that it was discovered last year in Sweden, that some small routers and firewalls don't pass DNSsec responses properly. And that's led to a survey work, there was some very nice work done in Sweden and then that has spawned some additional work. And we are gathering those results. Here's a page from the Web site. There's more -- I don't plan to take you through this. Just to give you an example of the kind of material that's available. All of this is publicly available and comes from organized, documented testing process so that anything is welcome to reproduce the results. And if there's discrepancies, you should holler quickly and we should sort all that out because the idea is to get it right. There's no proprietary sense of what we're doing here. Do you want to say anything about this? >>DAVE PISCITELLO: Yeah, actually, the slide that Steve has put up is representative of the kind of information we'll have when we get the testing of the broadband access and security gateway results. This is actually a survey that we've done on the availability of DNSsec features among commercial, Open Source and privately developed DNS name servers. So that is available at SAC 30. And when we get the complementing information regarding the support on security gateways and broadband access routers, we'll have that up as well. >>STEVE CROCKER: Thank you. Yes, I misspoke slightly. So the general pictures we're gathering information on product and trying to understand exactly what the compatibility issues are and, hopefully, wherever there are difficulties that will lead to improvements in the product line on the one hand or opportunities for consumers to adequately make the right choice, as we say. >> BRITT LYSAA: Excuse me. Did I understand you correct that that slide is in the DNSsec report, SAC 30? >>DAVE PISCITELLO: Yes. >> BRITT LYSAA: Okay, thank you. >>STEVE CROCKER: The question is, is the slide that I am currently showing available in SAC Report 30? And the answer is yes. Good. Other questions? Good. We'll now switch over to Dave. >>DAVE PISCITELLO: All right. I'm going to give two presentations. The first is on a report that we've published a few weeks ago entitled "registrar impersonation in phishing attacks." If you downloaded the slides prior to, I think, 1:00 today, you probably have an earlier version that was subsequently updated largely as a result of SSAC deciding that we wanted to refine some of the nomenclature that we were using to make some of this discussion a little bit clearer to people who are not entirely proficient in the DNS and in particular some of the DNS-specific terminology. And I believe the new slides are up and available, so if you wanted to pop up now -- they aren't? I would suggest that the slides that are in front of you on the screen are accurate and that we could use those. Let's begin by talking a little bit about what we mean when we say "registrar impersonation." First and foremost, we are talking about a phishing attack. In this particular style of phishing, we are talking about an attacker who impersonates a domain name registrar or a reseller. And the phishing e-mails are either sent to the registrar's customers in bulk or to a particular targeted customer. In the case where phishing is targeted at a specific individual organization, we typically call that spear phishing. So as you see, I'm paren they sized the word "spear" there and we will talk about those distinctions in a few minutes. The objective of a registrar phishing attack is very similar to the objective of any phishing attack, it is to lure the customer into disclosing some sort of information. In this case the management account credentials that would allow that attacker to be able to access a domain name portfolio held by an organization or an individual and then use those for one purpose or another. Why would you attack or target domain accounts? Many people don't appreciate the fact that domain names anchor most of an organization's online presence. And when you are able to access and either correctly administer or misconfigure or abuse a domain account, you can either enable attacks or you can hurt the particular registrant by disrupting his business. So, for example, if I am able to take possession of someone else's domain name portfolio, I can alter the contact information in that portfolio and then I could hijack a valuable domain name. I might not be able to keep it, but during the time I hijack it, I would be able to do something similar to the come net -- I'm sorry, Comcast.net incident a few weeks ago where I could deface the site or I could redirect electronic mail or I could do any number of other things that would cause reputational harm or hurt an e-transaction-based business. Another reason why I would want to get a domain name account is to either alter or add records in the DNS that would allow me to use the domain for the purposes of some sort of malicious redirection or some sort of flux-based phishing attacks. So if I were able to take over a legitimate site, I have two advantages. One is that I'm using the site and it's very likely that I can hide the deception for a fair amount of time. And the second is that I'm using the site and if law enforcement or people who are investigating phishing activities notify a registrar that this site is being used in phishing, it is extremely difficult to take that site down or suspend it because it belongs to a legitimate business. Other sites may be up and operational that are production sites providing revenue streams or providing information that the company wishes to publish. So the take-down path is longer and more complicated, and it enhances the deception and prolongs the attack. Another reason why I might want to grab a domain account is to obtain information that's not published on the WHOIS. For example, information that's published under a protected or proxy registration. If I'm able to deduce or determine the real administrator of a portfolio and I'm able to dupe him into disclosing some information like his account credentials, then I can go and I can get even more information about the contact information that is stored as part of the registration record. The last, and I think is also extremely important to pay attention to, is many registrations also use the same sort of e-commerce methods of storing credit card information or billing information so that the domain portfolio holder can purchase additional domains very quickly. So he's got a copy or record of a credit card, and what I could do as an attacker is possibly buy domains that I would use for phishing using the stolen credentials. There are many possible forms of registrar phishing and what I want to do is sort of give you the canonical form of how a phishing attack might be performed. The first thing that I would do in any sort of phishing attack is build up a credible customer portal of the targeted registrar, so I want to impersonate the site that a customer would normally visit if he were going to do his typical administration of his domain portfolio. Once I have that site up and operational, as an attacker, I want to lure customers to that site. How do I lure them to the site? I need to be able to generate an electronic mail that appears to be from the registrar and has the ability to convey some sense of urgency or alarms the recipient into reacting faster than his -- you know, his good common sense and his security savvy might cause him to do in other situations. So once I've conjured up this lure, I will then send it, using typical phishing tactics. I will send it to as many people as possible or target it to the specific individual that I'm spearphishing. What I'm then going to do is wait to see if someone falls prey to the deception and visits the site. When he visits the site, he's going to attempt to open his account or access his account. When he tries to access his account, I'll steal the information and I'll use it subsequently for some purpose and for some attack. The lures, most frequently, appear in the message body. In the case of a registrar, the lures are some sort of expected correspondence that don't seem unusual in the same way that you will receive some sort of notice, you know, for a financial institution saying, you know, someone has been accessing your account in an unauthorized fashion or we have a question regarding your credit line. What you would see in a registrar impersonation is something that would look like your typical domain name renewal notice or a transfer notice or an order confirmation. It might be a registration request confirmation. It might be a confirmation that suggests that someone has modified your DNS. ICANN annually requires a WHOIS accuracy reminder to be issued. It could be the accuracy reminder. One that would obviously cause most people some sort of sense of urgency or alarm is a notice that your domain name is expiring or it's been cancelled. Another aspect of trying to make the phishing lures very attractive to individuals is to try to personalize or enhance the deception. This is a very common practice today in other areas of phishing. We would expect that the same sort of personalization would appear in e-mail messages for -- that are impersonating registrars. So here's an example in -- you know, in plain-text ASCII that you might receive or that you might -- you know, might feel is a good example or form of the kind of attack that we're talking about. You get an e-mail that says, "Thank you for your order, thank you for ordering from registrar. Here are the details of your transaction." And the details simply have a customer number, a login name, a receipt number, an order total, some sort of customer service number that might actually be scraped from the registrars via a portal and then it also says, "Please log into your account, you know, and confirm this." The personalized information doesn't actually necessarily have to be accurate. It just has to be convincing. I mean, how many of you have domain accounts and how many of you actually know or have memorized the customer number that you have with that account? Very few of you. I don't. I have -- you know, or how many of you know the customer service number? Or the receipt number? We don't -- we keep these things. Maybe we store them in e-mail. But the idea is that to make it sufficiently convincing that someone is actually going to go and say, "Oh, I better check." Another example, this one uses hidden HTML tags, says, "Oh, your password has been successfully changed." Well, if you haven't changed your password, you might say, "That's not a good thing. Let me go check and make certain that my password actually works." If you look at the HTML here -- I actually can't hover this. How do I get my mouse? Oops. Anyway, in -- if you look at the HTML and you go under the HTML, you would find that it doesn't actually resolve or illustrate that you're -- it illustrates you're going to help.registrar.tld, but within the HTML lags of that HTTP string, you would see that you were actually being directed to either an IP address or http://i'mgoingtostealyourdomainnameportfolio.tld. The purpose of this advisory was to sort of draw in parallel and work in cooperation with organizations like the anti-phishing working group and help people understand, both on the sender side and the recipient side, how to avoid and reduce the risk of being phished. We have a number of recommendations for the registrars who are sending electronic mail that are very similar, and parallel most of the recommendations that the anti-phishing working group makes for financial institutions, online merchants like eBay and Amazon, individual small businesses that might deliver e-mail, and all these recommendations are basically good practices that we would recommend people do when they compose and attempt to deliver electronic mail. So, for example, in order to prevent a great deal of personalization, one of the things that we want to try to convince -- you know, convince registrars to do is include information that's necessary, don't include information that's unnecessary. Don't use hyperlinks that you embed in correspondence with customers that they would click on, because they can be used and are frequently used to misdirect, you know, the recipients of the e-mail to a bogus Web site. In the correspondence and on an FAQ or on a page at the registrar, warn customers that registrars are certainly no less targets for phishing than financial institutions or -- you know, or electronic merchants because they have a commodity that has a significant value, and in fact, has a very, very significant value to electronic criminals. Raise awareness that the registrars are attractive candidates for that impersonation. And then some of the other more advanced mechanisms that we might suggest, that have been suggested for years and still are valid, are trying to get people to implement forms of electronic mail that have non-repudiation of origin. Meaning electronic mail that is digitally signed that can be traced back to an authentic generator of electronic mail that is, in fact, the registrar. Another area where the registrar might want to improve or try to help customers protect their domain portfolios is the won portal. Use extended validation certificates for the Web site. Use multifactor authentication, in particular, for high security minded domain registrants. And then of course provide some sort of abuse and some sort of additional mechanism for customers to quickly notify you as a registrar that there have been attempts to phish -- you know, phish that registrar or phish that registrar's registrants through -- you know, through electronic mail distribution and phishing attacks. Customers can avoid being phished and quite honestly, most of these recommendations apply to almost every facet of phishing that you might see. Don't click on hyperlinks. Employ anti-spam and anti-phishing features. Try to use an electronic mail client that allows you to reveal the hyperlink references that are embedded in electronic mail. Be suspicious of any sort of e-mail that ever claims that an urgent response is required. Always read the message bodies as carefully as you can. Don't trust the e-mail just because it appears to be personalized. I think this is -- this is one of the important nuances that is growing among phishing attacks. The personalization tends to disarm people, and makes them feel like, "Oh, they know this much about my account. Then it must really be the registrar or really must be my bank." Well, in fact, a lot of this information is public domain. A lot of it is, you know, accessible through WHOIS services, through other -- you know, other information that companies put on their Web sites or deduce by smart people. And trust me, the criminals that we're trying to fight are, in fact, very smart people. So you have to be careful when it's personalized. If it is personalized, confirm that the information that is, quote, personal truly is yours. When you visit a site, make certain that the login form is -- actually the login form that you are accustomed to. Hover over it. Take a look and see whether or not it does actually have a certificate associated with the login portal. Check the certificate. Most people don't do this, but it is something that we really do need to raise awareness and -- you know, and increase education among users and subscribers, and, you know, the more we try to do that and the more people get it pounded into their heads that there are ways that you can avoid being phished, hopefully the fewer phishing attacks, you know, will succeed. Use unique passwords, change passwords regularly. If you're choosing a registrar, you know, choose a registrar that looks like they care about security. You know, are they using extended certificates? Are they using -- asking you for your CVV on your credit card before you complete a purchase? There are a number of registrars that also offer what are considered premium or services that are additional fees beyond the basic registration service that include things like additional security measures, additional ways to lock and check your domain name portfolio, you know, additional notifications or monitoring on changes of your DNS information. And those are all very valuable if you value your -- you know, value your domain portfolio. In the case of a company like Comcast, with 200 names, you know, you have to think, "This is an extremely valuable portfolio." And I'm not picking -- you know, picking on Comcast. It's a perfect example, however, of brilliant social engineering, and, you know, you want to -- want to pay very close attention to the fact that all these things can happen to you. So you need multiple checks and balances as a registrant. Sometimes working with a registrar who is going to charge you a little bit more pays off because they may know some of the checks that you do not. That's the end of that particular presentation. Are there any questions about registrar impersonation? >>DANIEL DARDAILLER: So just a question. Once your domain name has been stolen, what are the steps that you have to take to get it back if you can prove that it was a forged e-mail and a, you know, bad HTTP site, you know, not -- what are the recourse for registrants? Oh, Daniel Dardailler, W3C. >>DAVE PISCITELLO: So the question is: What measures would you take if your domain was stolen or hijacked or you had been a victim of a phishing attack of this form. The first that I would recommend is that you actually contact the registrar very quickly. The registrar is in control of that portal, and just as you would if you -- your bank account had been -- you know, had been hacked, you want to get in touch with the party that has the closest control to containing the problem. So I would contact the registrar. Calling ICANN is -- you know, first is probably not the right idea because ICANN has to then try to get in touch with the registrar, so you're simply adding layers of confusion and layers of delay. So contact the registrar, contact the abuse department. Try to make certain that you have a copy of the electronic mail. If you have a good sense of the time and day when the attack occurred, that's very valuable. The more information that you can provide to the registrar that identifies the incident, the faster they're going to be able to investigate, you know, and restore -- you know, restore service or restore the name to your portfolio. >>STEVE CROCKER: Question over here. >>DAVE PISCITELLO: We have one right here. >>STEVE CROCKER: Yeah. >>LUTZ DONNERHACKE: My name is Lutz Donnerhacke. I have -- the first question is: What's the purpose of an extended validation certificate if their certificate is still not checked by the customer? They do not provide any other security because if they use the right certificate, it's extended validated or normally validated all by the wide certificate by a certificated server. So the main question is: How do we need so much accounts? If you buy a domain -- we are a reseller chain. Several registries. We are requested to create accounts for technical, for administrative contacts, for zone contacts that might be customers, might be [inaudible] customers but they need an account on the portal, too, in many registries. And that's a problem because they do not want an account. They have a company, an ISP for them to do this, to do the whole reseller link chain and manage it. So we have a lot of accounts. They are unused, they are unchecked, they have probably good passwords because they are never used, and -- but these accounts create a problem because the registries sometimes bypass the reseller chain, so we get a question from customers say we, "We got an e-mail from blah, blah, telling me that my domain name is going to something. What happened?" So we had to decide if the e-mail the customer get -- and we never see, we never get notice about -- is a phishing attack or it's valuable information or it's necessary information for them. And sometimes those phishing attacks has the consequence that we -- necessary e-mails get filtered out by spam filters because they are trying -- the customer is trying to -- I do not have to do anything. That what my ISP is for it. They have to do it. I do not want to receive them. They must be spam. But it's important information, and the registry bypass the reseller chain so nobody notice that I have to do something. And what about redemption periods after a major change? Sometimes changes are very small or going in a very slow way, and if a lot of information is changed on the registry, what about a redemption period to use the old password to change to the -- or to have about a week to go back without any questions? >>STEVE CROCKER: So it's good to see you here, and you raise multiple issues and I'm not sure I can remember each of them, but I'm going to try, and then if I don't get all of them... The -- first of all, you're raising an issue about registries and accounts and so forth. So maybe it's worth just a moment of review of what that food chain looks like. So the registry is the single point of contact for a domain. It's where the database is kept. But in the -- for the gTLDs and for the system that is set up with ICANN accredited registrars, the direct contact between the customer and that system is through the registrars, not to the registry, and -- >>LUTZ DONNERHACKE: [Speaker is off microphone] >>STEVE CROCKER: And I'm not criticizing. I just want to sort of sort out the pieces. So in principal, the registry is not ever supposed to be contacting the customer directly because that would be getting in the way of the relationship between the registrar and the customer. >>LUTZ DONNERHACKE: [Speaker is off microphone] >>STEVE CROCKER: And then you mentioned resellers, and the resellers have then a contractual relationship to the registrars, and are, in principal, acting on behalf of the registrars. So one element of what you've described is that if there is e-mail going directly to the customer from the registrar without going through the reseller, that is a business problem about the relationship between how the registrar operates and the reseller, and it's hard to get in the middle of that because it's not an ICANN problem directly and it's -- >>LUTZ DONNERHACKE: [Speaker is off microphone] >>STEVE CROCKER: But it's related to the subject, indeed, but it adds some complexity and your point is well-made there. You also asked about accounts, and again, this is kind of a feature and we know from the lingo in our field that sometimes what you call a feature I might call a bug or vice versa, right? That the registrars have this notion that they have a relationship with the customer and so they set up accounts that are their accounts for interacting with the customer, and the subject matter of those accounts is the domains that are being registered, but as far as they're concerned, they have this business relationship and they want to have -- and it's most typical, most common, to have an account that you have a name and a password and account number and so forth to log into before you can change any of the parameters on the domain registration. And then as you also point out, very often from a customer's point of view you don't think about any of that. You have a relationship, say, with your ISP and all of the details for your domains are handled as part of that relationship and in that case the ISP is acting as a reseller, usually, and the relationship with the registrar is behind the scenes. So I empathize quite a bit. I too am a customer in my limited way and I have to figure out all that. And I agree, it's not a very clean, simple system. I wish I had power to fix it in some sense, but I don't. But things start, I think, with just an explanation of how all the parts are there. Now, that's as much as I can remember about all the issues that you raised, but I'm not sure that I've answered a question so much as just given a description of how all those pieces fit together. >>JIM GALVIN: His first question was about the extended certificates and what do you do if the client doesn't have a way to validate them. >>STEVE CROCKER: Ah, yes. >>DAVE PISCITELLO: Well, I mean the reason why extended certificates are useful is because you have to have a little bit more credentialing in order to acquire an extended certificate, as -- you know, as a purchaser of a certificate, as opposed to a raw unsigned certificate that I could use as a hacker to spoof. So if I could at least deduce that this was a locally created certificate as opposed to one that was issued by -- you know, by an organization that I might find trustworthy, this would be a very valuable thing. Now, we're talking about learning -- we're talking about a learning curve that is fairly steep, and I admit that it's a fairly steep learning curve, but I'll point out that, you know, five years ago it was not very common for merchants to ask consumers to turn their credit cards over, copy a credit card CVV value and type that into the Web form before they completed the transaction, because at least it turned the credit card into a physical token and it created, you know, the semblance of a multifactor verification for the credit card. So the fact of the matter is, I belong to the community that says users can learn. It's just that we don't teach them the right way. And the more that we provide education and the more that we make things -- you know, make education the basis, as opposed to automation, I think the better off we are in terms of thwarting socially and -- socially engineered attacks. We can't automate against social engineering. You know, there is -- there are too many nuances that allow people to constantly morph the way that we -- they deceive other people. I mean, we had an argument yesterday about which was the oldest profession in the world, and we've concluded that social engineering is probably the oldest profession in the world, and I can -- [Laughter] >>DAVE PISCITELLO: Yes. So we're trying to change something that has existed since the dawn of man, and it's not going to happen through -- you know, through just using sort of Whac-a-Mole technology and putting down, you know, large numbers of automated defenses and large numbers of attempts to detect attacks. Now, the other point that you were making is that one of the problems in -- you know, in delivering electronic mail to -- you know, to end users is that very frequently the users don't even appear on registration records. The ISP will substitute, you know, its contact information -- >>LUTZ DONNERHACKE: [Speaker is off microphone] >>DAVE PISCITELLO: It should not happen but it happens in very, very large numbers of -- you know, of registration records, but even so, there are two problems here. One is that contact information may not necessarily always get you to the registrant, but in the cases that it does, what we're saying is that the registrant is the one who is socially engineered into disclosing his account information that allows him access through a Web portal to a registrar. So, for example, if you have an account at Go Daddy or register.com or Network Solutions, you go to a Web portal, you, you know, enter your username and your password and you go to domain account pages and you make modifications or add -- you know, or buy more domains or change the DNS configuration of those domains. Those are the account credentials that we're talking about being compromised, because once you have them, you have the keys to that domain registrant's kingdom of domains. >>LUTZ DONNERHACKE: [Speaker is off microphone] -- and they do not have to be the same. We want a correct WHOIS information, but it doesn't include all these persons in the WHOIS that has an account under that portal. It's not necessary. It's completely different. >>STEVE CROCKER: Yeah. >>DAVE PISCITELLO: Well, that's a different -- that's a different row to hoe and it's been hoed for eight years here and, you know, I think if you want to discuss that issue, there's another meeting that is taking place either tomorrow or Wednesday. >>STEVE CROCKER: Yeah. Let me jump in here with kind of three points. The -- as Dave said, now we're moving into the WHOIS debates, which have had lots and lots of discussion. And more yet to come for sure. Second thing -- can I remember all three? Anyway, second thing is the registration information, as you point out the ISP sometimes gets in the way there. One of the things that I would think is very important is that anybody who registers a domain name should go back and check the information that is publicly listed for it and check for two things, most particularly. First is something that you didn't touch on, but is part of this whole picture, is: Who is listed as the registered party? Very often when you're dealing with an intermediary like an ISP or some third party, they will register the domain name under their name and then if there's ever a dispute about who has control of that domain name, you're in very difficult position. The second aspect is that the operative contact people, the admin contact and the point of -- and the technical contact, should be people who are competent, who are technically able to understand the status of the registration, the renewal process, what to do if there is a problem, and so forth, so that if it's a senior executive in some business that might not know what to do, it should be sort of at the right level of technical capability and needs to be tested every once in a while, particularly if it's a role account. You know, if it's thepersoninchargeofdomainnames@mycompany.com, and then that person leaves and that role account is just left there and it's not bound to anything, then e-mail going to that address will go... We've written some on these various pieces of this in the past, covered topics, parts of it, in our reports of hijacking of domain names and so forth, and I suspect that there's more that needs to be written over a period of time. We've wandered a fair distance from the registrar impersonation, in particular, but I think these are very important aspects. But with that, let me suggest that it's time to draw a close to this part and move on to the next report, unless -- does anybody else want to raise a question? Oh. Yes. >>DAVE PISCITELLO: We can also talk offline when we're done. >>PATRICK MEVZEK: I'm Patrick Mevzek. I have three points. I will try to be very brief. First, do we have any statistics on the number of these attacks, particularly in regard with other online services? What decided you should take this study beside IPV cases you spoke about like Comcast or others? That was my first point. The second one -- >>DAVE PISCITELLO: Can we answer them one at a time. That way we don't have to memorize them. >>PATRICK MEVZEK: Okay. Sure. >>STEVE CROCKER: Good idea. >>DAVE PISCITELLO: Yeah. We have evidence and we have not-huge statistics that say that this is happening in a very, very large-volume fashion, but SSAC doesn't necessarily operate as an incident response or a cert. One of the things that we try to do in some cases is to get out in front of, you know, a style of attack or we try to anticipate the evolution of attacks that we see in one forum, or with one set of targets, and determine whether or not, in this case, that, you know, the people with whom we are -- with whom we are concerned may be targets. So obviously since we're concerned about the DNS, we're concerned about registries and registrars and resellers being targets for phishing and that's one of the reasons why we began talking with some of the folks at the APWG -- in particular, rod Rasmussen here from Internet identity and I started the conversation about this. We brought it to SSAC and said, "This looks like a very, very, you know, tractable problem now. It may not be in a year." So do we have statistics that this is happening in a very large manner? No. Is it likely to happen? Yes, because there is value here, and especially with the trends in the way that domain names are being exploited in attacks, we are very concerned that this might become, you know, much more commonplace. >>PATRICK MEVZEK: Second point. Following your idea of trying to study problems before they arrive, can we imagine that the same problems will arrive with registries and ICANN phishing attack because some are dealing directly with customers, or dealing with them, for example, with a change of [inaudible]. So phishing attacks could also [inaudible] and ICANN, being more and more well-known in the community of users could also become an attack of this phishing? >>STEVE CROCKER: I think it is unquestionably true that there is phishing attacks based upon ICANN. I'm sorry? Yep, we've had some dialogue already whether or not the way ICANN runs its Web site lends itself to those kind of attacks and we're having some discussion about how to tighten that up. >>JIM GALVIN: You should probably say, Steve, you also represent SSAC on the board. You are saying, "We have had some discussion." You should say who "we" is. >>STEVE CROCKER: Right. So I wear two hats. As I said at the beginning, I chair this committee and this committee has a slot on the ICANN board as part of the byzantine structure that I described. There's a position on the board that is filled by a liaison from Security and Stability Advisory Committee, non-voting slot, along with comparable representatives from the other Advisory Committees. And I fill that slot as well. But the discussion that I was describing is -- I guess I'm not sure which hat I was wearing when I was engaged in that discussion. But one way or the other, we are having some discussion with the people who run the ICANN sites about what the right way to manage those is. Thanks. >>PATRICK MEVZEK: Last point because I feel very strongly about that, I absolutely agree with you since users are part of the security problems, they should be part of the solution -- of any solution. So your slide about everything that users should check is absolutely right. But I think another party that should be part of the solution. For the case, we have ten registrars can themselves make errors. Can themselves -- their database could be stolen, their security could be not very good. Should ICANN not ask registrars to at least report breaches of security to them, to ICANN, or to the community at-large? Because, otherwise, many things can happen and no one will know unless telling the users this is part of the [inaudible]. >>STEVE CROCKER: There are absolutely no known problems with any registrars. All registrars are 100% perfect. [ Laughter ] No, your point is right. There's reports of problems with registrars, and there's a fair amount of attention within the ICANN staff of trying to work with registrars, get reports on problems. And certainly with the rather spectacular problems with RegisterFly last year, I guess, the posture has switched from trying to be fairly quiet in dealing with registrar problems to a much more active and, in many cases, more visibly stringent dealings with registrars that have various kinds of problems. Eric, you wanted to chime in with something on the first point? >> ERIC BRUNNER-WILLIAMS: Thank you, Steve. You were copied on an e-mail from Werner Staub about a week ago. This arose in the context of the Mozilla Foundation looking for a mechanism for detection of places in the name space where a cross-site cookie is a possibility. The subject that this morphed into -- I just sent a copy to you, Dave -- is that ICANN itself engages in phishing in the sense that ICP track embeds -- in e-mail sent on behalf of ICANN, in HTML format which contains paralinks to the ICANN Web site and actually point to the ICP -- ICP track Web site. So someone in ICANN has -- is making the mistake that we're pointing out here and needs the application of a clue bat. >>STEVE CROCKER: Yes. And in addition to the interaction you and I had briefly yesterday, two other people came up, one on each side of me -- I felt surrounded -- and pointed this out quite strongly. For what it's worth, I have already sent a note as the initiation of a dialogue to get at that. And it comes actually -- we raised this point sometime before, and I think there's not yet agreement on what is permissible and what is necessary and so forth. So we're going to have a bit more discussion about that to try to iron that out. And so we're in kind of an murky area as to whether tracking per se is better or tracking being done this way is bad, but I think we will raise the visibility of this considerably. I thank you. I apologize for not sort of getting it the first time when you sent that. But I can assure you that my attention is now focused on this and we will have something more to say -- I can't guarantee what the result is, but I can guarantee the topic is live and will have some sort of response. >> ROD RASMUSSEN: Rod Rasmussen with the anti-phishing group. This issue came up last fall with a very large-scale attack. It really has happened with the fairly notorious Rock Phishing group going after the largest registrar and their actual -- their customers. We have seen a couple smaller attacks since then. It is not just theory; it is actually happening. And by the most sophisticated criminals in the e-world, if you will. This is not a theoretical exercise. And we are concerned about the implications, especially when you have financial institutions, et cetera, with their entire online presence based on domain names. >>STEVE CROCKER: Good. Behind you there? >> BRITT LYSAA: My question was more like a comment to the last. You talked about tracking. It is a different subject. >>STEVE CROCKER: Go ahead and ask and I will tell you it is the wrong question. No, please go ahead. >> BRITT LYSAA: Excuse me. I didn't catch what you said. >>STEVE CROCKER: I was teasing a bit. Go ahead and ask and we'll see. >> BRITT LYSAA: Tracking is a bit different subject than what we are talking about, in my point of view. >>DAVE PISCITELLO: Yes, it is. >>STEVE CROCKER: Yes. >> BRITT LYSAA: That was a comment. My question is, when will you come back to that issue? Because you said I will come back to that but you didn't say when. >>STEVE CROCKER: That's right, I didn't. I don't know. >>DAVE PISCITELLO: Not today. >>STEVE CROCKER: Not today. The good news is that what we're saying here, even in this informal dialogue is being recorded, so this transcript will be available -- it is available publicly and it is also available so that we can cut the right pieces of it and strip them to the right people and force the discussion and we've raised the visibility of this discussion even amongst the people here. So if I forget to push this, Dave will remind me or you'll remind me or Jim will remind me or something. So let me stop short of a time commitment because I can't tell in the confusion of all the different things that get attended to how quickly other people will respond. But at the very least, you have a kind of marker here that says we promise to do something, promise to at least keep this alive and get a response and to do it in a reasonable time. Great. So we were ahead of schedule before but we're no longer ahead of schedule. I think it is time to move on. Dave? >>DAVE PISCITELLO: All right. Let's look at another subject. One of the things that we have been looking into recently, again, that was brought to us by a member of our committee who had actually seen a presentation by a gentleman by the name of Dan Kaminsky who is a notorious -- well, not notorious because he is actually a very good guy, but he -- he likes to break things and he likes to point out the problems that exist in networks when people don't behave in the way that protocol behavior is expected to behave. So one of the things that we started to study was something that we broadened into a subject that we call DNS response modification. There is a little bit of a background and education that's necessary to understand the nature of this problem. And one begins with the term "NXDOMAIN" and what a NXDOMAIN response is. The NXDOMAIN is actually -- stands for non-existent domain. And it is the same of what is called a name error DNS code in RFC 1035, the domain name system. It is returned by an authoritative name server only and it states more just an error condition. What it states is the content that the authoritative name server expects the client to receive. So when RFC 1035 or at least SSAC's interpretation of RFC 1035 is taken literally, what we're saying is that a name error a message or a communication from the domain name registrant or his agent who is operating the authoritative name server that signals two things. It signals that there is no name in this part of the tree that corresponds to the name that you asked in the query. And it also is signaling that not only is this an error but this is the content that we want to send you is the non-existence of that name. One of the things we have found -- I'm getting e-mail, sorry. Excuse me. I hate when they do this. One of the things that we found is that DNS responses, or at least the information that is returned in a DNS response, is modified or can be modified in two locations. We tried to separate those and tease them out into two different behaviors, but to begin with, we'll identify those two parties. The first we call entrusted agents. And the second we call third parties. So the players in this spectrum of what we're discussing are the domain registrant, and the roles the domain registrant have are that he is the party -- or the organization is the party that registers the domain name. And in principle controls what is included in the domain zone. In principle, the registrant also controls the responses, the domain's authoritative name server returns. What is an entrusted agent? This is the party that administered the zone for the registrant and operates the authoritative name service. This could be someone's only I.T. organization or it could be an outside party and we'll talk a little bit more about who that is. But this agent clearly is supposed to have a trust relationship with the registrant. He is managing a very, very critical resource for the registrant. A third-party network service provider operates the resolvers that do most of the work in the Internet, that are -- that provide more localized query response operations in the general framework of how the DNS operates. Third-party NS providers don't necessarily have a trust relationship other than an implied one with any of the individual registrants that have domain names. So unlike the authoritative name server, there is a different trust model that one would apply or assume with a third-party. We're going to look at two different kinds of modification of the content in an NS response. The first is when an entrusted agent actually makes that content modification. This may look familiar to you because it has appeared before at the TLD level. When the entrusted agent or the authoritative name service receives a name query from a client and determines that that name doesn't exist in this zone file, he can or, in some cases, does return a "name exists" response and it contains an I.P. address mapping that the entrusted agent chooses. The common implementation of this is to include a wildcard entry in the zone file and the wildcard entry essentially says all names not found in the zone resolve to an I.P. address that the entrusted address chooses. So if my domain zone at corecom.com has 25 names, and I would hand my zone off to an entrusted agent that does this form of wildcarding, they would add a 26th entry. That entry would say if any name in the above list is -- any name other than the above list is queried, then please direct the result to the I.P. address that is identified in the wildcard entry in my zone. So let's look at how this actually works. And this is a very simplified version of how DNS resolution is performed. I realize that there are some steps absent here, but in the interest of trying to fit it on one slide, please give me some license here. So the client asks, what is the I.P. address of ww.example.com, illustrating this could be a typographical error -- a common typographical error. The iterative revolver will ask the root server first what is the I.P. address of ww.example.com. The root server will reply, "I don't know but you could ask one of the com servers." Iterative resolver will say to the com name server, What is the I.P. address of www.example.com? The com name server will respond, "Ask the example.com's name server." And the example.com's entrusted agent who is running the authoritative name service for example.com and hosts the zone file is asked the question, What is the I.P. address of ww.example.com? In this case, talking about a synthesized response, he says, "That label doesn't exist, however, I have an entry in my zone file that says for any label that does not exist, I'm going to return in the answer section of this DNS response the I.P. address, a.b.c.d." He does return that I.P. address. The resolver does return that address back to the client. Now, there's a second form of that's performed by a third party. In this case, the third-party nameserver operator examines DNS response messages that it attempts to resolve for a client. When it encounters a nonexistent domain response, it is going to silently author that response code from "nonexistent" to "name found," and then it's going to insert an IP address mapping that the third party chooses. How does this work? Well, to go quickly through this, because we walked through most of this process the client asks the resolver, the resolver asks the com server, the com server asks the -- I'm sorry, asks the root zone and then the com server and then example.com's nameserver what the IP address is of www.example.com. In this particular case, Example.com is not returning a wildcard, it's actually going to return nonexistent domain, because the name does not exist. However, the iterative resolver is going to say, "Oh, this says nonexistent domain. I'm going to change that and I'm going to change it to answer with an answer section that has an address that I choose, and that address is W, X, Y, Z. That's returned to the client. So you can see that there are now three cases that we have to deal with as a -- as a name -- as the domain name registrant and essentially the person who was supposed to control the zone, and as a client. I can get three responses. So who has the means and the motive and the opportunity to make these kinds of decisions and to make this sort of interception or modify the intended contents that the registrant had originally encoded in the zone file. Well, a sponsoring registrar can, a public DNS provider can, and you can actually look down the list. The most important part is to take a look at not only the roles that they are engaged in when they perform this, but also the why's. The value-add of modifying an error and redirecting the client or the browser to an IP address is that you now can put -- land him on a page that you control the content over. So either as the entrusted agent or as the third party, I can put someone on a page I choose, as opposed to a page that the registrant has control over, or as opposed to not giving a response at all, which is what the registrant might have wanted in the first place. So now, that it is my page, I get to control what it says. I can promote my business, I can promote my services, I can post advertising, I can post affiliate advertising or pay per click, or I can offer what is called "enhancing the user experience" in the user resolution market. Which means that I can say, "Ah, that domain doesn't exist but if you're looking for this information, use our search engine" or, you know, "Here are some other cues, other valuable information you might find that will help you solve your problem." Okay. Another reason why people tend to do this, or may do this, is to enforce some sort of policy or provide remedial education. For example, as the entrusted agent, I might choose to say that I would like all responses that come back that are associated with names that have -- that are nonexistent to go to a page that says, you know, "Use our internal search engine, do not have an external search engine" as an organization. Or I might want to use this in a non-wildcard mechanism, but as a specific set of IP addresses that answer specific questions that tell people that they are trying to access sites that are now blocked or trying to access services that are blocked and say, "You're operating outside my organization's acceptable use policy." I might also link this to something like a phishing block list and redirect my users to say, "You are trying to get to a page that, in fact, had been a phishing site, and had you -- by the good graces of people like rod Rasmussen and company, had that site not be taken down, you would have been a victim of a phishing attack and now we'd like you to learn a little bit about why you were phished, so here's a remedial education page for you to read." And of course attackers really like this because now attackers can think about, you know -- about redirecting people using DNS servers that they've compromised for their fun, fame and fortune. There are a lot of implications and issues that arise when an error response that the domain registrant intended to have delivered is not delivered. For one, this signals a different state of the zone to the user or the client than the operating state. The operating state doesn't have, in some cases, an entry or a label, yet the client sees one. In other situations, what has been done is that the original packet that was sent is altered. Content has been inserted. And so the domain authority may not have ever intended that additional content be inserted. So we have a message alteration here, and in many of the situations -- for example, in voice or in electronic mail, grabbing a packet or grabbing a message on the fly, altering it, and delivering it, would be considered a very, very bad thing. I wouldn't want to see somebody do this with a bank transaction. I wouldn't want to see somebody do this with an electronic mail that I'm intending to deliver as a mail exchange operator, so I really am not interested in seeing this happen with my domain name responses. It's still my content. I would still like to see it delivered as it was originally intended. One of the interesting problems that you have here, especially when local third parties or ISPs are the ones who are performing the modification, is that the response a user receives depends on the resolver that it asks. Not all the resolvers are going to be performing this kind of modification, so if I go to resolver A, I might get an NXDOMAIN, but if I go to resolver B, I might get an IP address that resolver B chooses. A corollary to this is that suppose I do decide to add www.example.com to my domain zone, okay? And somewhere along the line, somebody has already cached www.example.com, you know, and is keeping that address for a persistently long time based on the TTL. Locally, all the people who are trying to get to my now-new legitimate www.example.com are not getting there, they're getting to the address that the local operator had, you know, previously bound and is still in the cache. Okay. There are some interesting business consequences for the registrant if the registrant, in fact, is, you know -- is trying to protect brand or trying to protect reputation or has invested a considerable amount of money on their own site and link popularity improvements and now a third party has redirected,you know, under his domain all addresses, you know, to some party that is a redirection host. So my site says www.example.com and I'm selling widgets. If you mistype and go to ww.example.com, a competing party might be selling widgets or they might be selling products in competition with widgets. They might be using my site's popularity to simply, you know, benefit and leverage from the fact that this is a name under a very, very popular name. If I were Myspace, I wouldn't want this happening to me. If I were Du Pont, I wouldn't want this happening to me. If I were a bank, I would certainly not want this happening to me. Okay? One of the things that we're going to talk about in the next few slides is that there is a -- you know, whether you like the premise or not, there is a parent trusts the sub-domain security or trust model in most Web services deployment. You know, there is some notion that the domain zone is authoritative, the domain registrant names the things in the zone, and then as a consequence, anything in the zone that is named can be trusted. Now, that may not be the best trust model in the world to build Web services on, but it is, in fact, the trust model that exists in many, many organizations. So one of the problems you have here is that you have no sense of scope and containment of all the names that actually are instantiated in a zone if anywhere in the Internet at any given time a third party may add a name to your zone on the basis of receiving a "nonexistent domain" response. This creates a -- yet another problem, which is that the security of the hosts to which all this -- all these DNS responses direct clients is not directly under the control of the domain registrant. So Steve has -- you know, Steve has servers as an organization, Rob has servers, I have servers, Du Pont has servers, Cisco has servers. Having someone with a Cisco name or a Du Pont name running a server creates the perception that -- you know, that it's Cisco as a brand, but it also creates a problem for Cisco, because Cisco's not administering that box. Cisco has no idea whether that -- you know, that Web server is operated in the same secure environment or with the same hardened operating system or with the same software, with the same -- you know, same intense scrutiny over, you know, scripting and Java applications and other applications that are operated in conjunction with the Web server. Not just Cisco but any organization. So this actually creates a problem, in that you don't know whether the machines that are named under your organization's domain actually are secured to the same extent that you would if you were operating them yourself. What happens is that attackers see this as an opportunity, and one of the things that is very possible is that you can phish via false site injection at both the synthesized and modified domains. And this has been demonstrated, you know, to exist today by Dan Kaminsky, a live demonstration at one of his last -- you know, last presentations, where what he demonstrated is that he could go to the redirection hosts that were used by companies that were using synthesized response in the, quote, error resolution business model and he could script into those Web pages and he could then post onto the legitimate Web pages. So he was using a cross-site scripting attack and he went to very popular sites -- companies that would be very upset if their brand were misused in this fashion -- and he simply put up a defacement, and it was very easy to do, because the Web server that was the landing page for names redirected under the hosts that he -- or the domains that he tested had a cross-site scripting vulnerability. There was a parameter that did not check for input validation and he was able to append the script to that parameter. The script was executed and it allowed him to post to the parent domain and post to other children in the parent domain. This is a very, very serious problem, but it's only one that is possible. You can also extract information once you are a man in the middle and you've scripted those sites. You can also arbitrarily retrieve cookies, and you can also leverage -- you know, leverage any sort of attack you want against the brand, either by modifying content on the fly between -- you know, as a cross-site scripting attack or by adding sites and then creating your own -- you know, your own host that literally defaces the site in the same fashion that we saw in the Comcast.net case, putting up something that says, "I own you" or putting up something that is much less obvious but more pernicious such as a, you know, modification of pricing on a page, modification of availability of products, alteration of -- of check-out carts and the like. So there's a lot of things that you can do if you can script into the domain through a machine that you do not necessarily have control over. Going beyond what you can just do with "A" records that are typically resolved to Web sites, one of the things that we -- you know, we are starting to worry about and we haven't yet, you know, fully explored in SSAC is, "Well, what about synthesis and what about, you know, modification of other records, mail records, records that have IP telephony numbers or records that identify additional servers?" And this is not really necessarily a -- you know, a conclusion, but it's an observation that if it is allowed to continue or if it is judged as appropriate in the "A" record case, then what's to stop someone from essentially saying, "Well, you know, this number in this exchange, you know, block of telephone numbers, you know, isn't bound to a user, so what I'll do is I'll simply bounce it off my call server and I'll -- you know, I'll answer the call and I'll give this person an advertisement or -- you know, or a clip about, hey, this wouldn't happen to you if you were using my service." There's another problem here that even the people who do synthesize and modify responses have to recognize is that this is only -- if you treat it as only content and if you make the assumption that whatever the original content was that I delivered can be altered at any given time, then anyone further -- or anyone closer to the client who intercepts the query that you've modified can actually do the same to you. So if you go back and you look at the slide where we -- the slides where we demonstrated the modified or the synthesized response, and then you make the assumption that when the synthesized response comes down from the entrusted agent, some iterative resolver can say, "Well, yeah, I can see that this has changed because I've been studying traffic patterns and I know that this is actually this -- you know, this entrusted agent's redirected site so I'll redirect it to my own site instead," there's no assurance that once you've actually started this process that, you know, what you deliver is not going to be modified. And it's sort of amusing to imagine that someone who is doing this at the synthesized response level would go and complain to someone who's doing it further downstream that, "Hey, you've modified my content. You can't do that." Let's get to some of the recommendations. I think, you know, if you go and you read the report, we have some summary findings. I wanted to try to cut to the chase and talk specifically about some of the things that we find very worrisome about this practice. We have talked about synthesizing response messages at the TLD level on at least four previous occasions in SSAC. We have at least four publications that say, "This is a -- not a great idea and should not be practiced," and, you know, we haven't changed our position on that. Whether it's done as a synthesized response or it's done somewhere along the path, it still makes the fact that you're not delivering what the domain, you know, authority -- or, sorry, the domain registrant intended. This is not to say that if the domain registrant was duly notified and informed and provided express consent to allow this to happen and said, "Yes, I'll do it because I'll share in the revenue," that it isn't, you know, that someone could, in fact, negotiate with his agent, because then, in fact, you're doing what the domain registrant expects you to do and wants you to do and has given you license to do. The important part here is: Who has the control? Registrants can control how their entrusted agent answers a query for a name does not exist in its zone file through the trust and business relationship they establish. So a restaurant should be able to say, "I do not want you to modify my, you know, label does not exist operational model, so therefore, do not ever inject, either through synthesis or through subsequent modification any packet other than an NXDOMAIN packet in the case of these labels." And organizations also have to be aware of the fact that this is happening further downstream and outside their administrative reach. One of the other things we think is very important is that organizations that rely on accurate nxdomain reporting for operational stability have to pay attention to what their entrusted agent, you know, is going to do and have to make certain that that agent doesn't modify DNS responses. I guess we have to get out of here, don't we. Because we have to leave and I'd like to -- at least one or two minutes for answering some questions, I think I've laid the table, you know, with the problem set. If you look at the rest of the preliminary recommendations, you'll see that we're not done yet here, and it -- you know, one of the things that we are going to look at are how these kinds of behaviors will affect other IP-based services in the future, whether or not traditional operational assumptions are very seriously affected or obsoleted by persistent error modification in lots of business models, and how you actually would go about creating a trust assertion, if sub-domains aren't controlled by the parties -- you know, by the registrant itself. >>STEVE CROCKER: So I'm told that we're actually -- there's another group that's supposed to be in here now, not after a break, which is awkward. >>DAVE PISCITELLO: Ownership is nine-tenths of the law. [Laughter] >>STEVE CROCKER: Yeah. [Laughter] >>STEVE CROCKER: This is a new form of cybersquatting, as it were. >>DAVE PISCITELLO: That's right. >>STEVE CROCKER: And I desperately wanted to show you the agenda for two days from now of the DNSsec meeting which will be in this room at 1:00 which will be another full -- fully packed thing, but with apologies, I think the right thing to do is to simply cut this off. Plenty of opportunity for interaction. Just keep sending in messages and -- or we can talk in the hallway or whatever. But I do feel a strong obligation to turn the room over. Thank you all. [Applause]