ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>STEVE CROCKER:
Good afternoon.
My name is Steve Crocker.
I'm the chair of the ICANN Security and Stability Advisory Committee.
Welcome to the afternoon session.
Formally, this is our first formal open SSAC meeting at an ICANN meeting.
In the spring in Mar Del Plata, we gave a preliminary version of the report that we're going to focus on today.
And today we'll give you the final version.
Let me just say a word about the committee and a picture of where you can expect we're going to go in the future, and then we'll focus on the main event for today.
The -- thank you.
Good.
The Security and Stability Advisory Committee is an external committee of volunteers that gives advice not only to -- it's chartered under the ICANN board and it gives advice not only to the board, but to the entire ICANN community: Staff, supporting organizations, and so forth.
And also to the general Internet community when it's appropriate.
I won't spend a lot of time on the history and the membership, but I would like to take a moment for those committee members who are here -- and I should emphasize that because of the nature of our committee, we have people from registries, registrars, the security research community, the address allocation organizations, the RIRs, and a variety of other organizations.
And as it turns out, their natural orbits don't all take them to ICANN meetings every time.
Some of them show up at IETF meetings, for example, more often than to ICANN meetings.
So we frequently do not have everybody, I don't think we've ever had everybody in one room, and do most of our work by mail or by phone, and then some of us get together in smaller subsets.
So let me ask the members of the committee who are here to stand up.
Suzanne.
Suzanne Woolf from Internet systems consortium.
Come on, I know there's -- I saw one or two more here.
Jaap Akkerhuis from NLnet labs.
I'll get to you guys in a minute.
And is that it? There are some more floating around the conference.
Closest to me, Bruce Tonkin, from Melbourne I.T.
Ram Mohan from Afilias.
Rodney Joffe from ultraDNS.
And I'm pleased to introduce Dave Piscitello.
Dave is a brand-new addition of an entirely different kind.
He actually does real work.
We have had the intention for a long time to have a senior staff person designated as the fellow for SSAC.
And I'm just tickled pink that Dave came on board about a month ago.
And that helped -- what was the exact date? Oh, it was around the 1st of June, yeah.
May 31st; right.
It was exactly May 31.
And jumped right into this effort that had been going on at a much lower energy level for a few months, and has brought it to a conclusion.
And you're about to see the fruits of it.
So Dave Piscitello is the man.
And I expect that as a committee, we will be significantly more productive and you will see more topics and more reports over the next period of time.
So that's the primary introduction for the committee.
I want to focus the bulk of our time today on domain name hijacking.
As I mentioned, we gave a preliminary report on this at Mar Del Plata and we're now in the position of wrapping this up.
The speakers are going to be the gentlemen on the -- up here with me on different parts of it.
The report is published as of now, I think it's been up on the Web site, measured in some number of minutes.
So it is hot off the press.
I don't think we have any hard copies even, although we would have liked to have had.
The report is, what, about -- how long? How many? 40? Yeah.
Give or take, 40 pages, just so you have an idea of what you're getting into.
And -- oh, I don't control what's on the screen from here.
Next slide, please.
There we go.
There we go.
So we have to -- so down at the bottom, that long URL, and at the end of the session, we'll come back to this slide.
Next slide, please.
So here's the outline of what we're going to cover.
We're going to start with a handful of specific high-profile incidents where names were hijacked.
And we have some of the people who are knowledgeable about each of the different incidents here.
I want to emphasize that our purpose in examining this topic is not specifically to go after a particular incident or any one or two or three of them, nor to focus attention on particular players.
It is not our point of view that there's much to be gained from our committee's perspective for focusing attention on a particular registrar or a particular reseller or a particular registrant, for that matter, but, rather, to look at the interplay of how the whole system works and the obvious implication of whether such things are likely to happen in the future and whether there are ways to improve the entire system so as to reduce the potential for problems or to provide ways of correcting them rapidly when they do occur.
So our focus is more on the systemic, organizational aspects of the scene as opposed to pointing out particular bad guys or particular mistakes that people had.
So with that, let me turn the podium over to Bruce Tonkin.
And Bruce and Rodney and ram will walk through a series of incidents.
Dave will take you through the bulk of the report.
And I will return with the findings and recommendations.
Thank you.
>>BRUCE TONKIN: Oh, this is not connected.
Next slide.
Thanks.
Okay.
PanIX.com is an example of a domain name hijacking where it was transferred from the rightful holder of that name.
In this case, the DNS information, essentially, the name server was also changed.
And so the impact there was that as far as customers of the company, panIX.com were concerned, their E-mail ceased to work, the Web site ceased to work.
And so, clearly, that would have a major impact on the operations of that company.
And then, of course, especially for a company that's a technology company, and if you can't reach that technology company, then that's going to have a very serious impact on the trust and brand for that company.
So the impact on this brand was probably much larger than the short-term impact for customers just not being able to reach them.
In analyzing the incident, pretty much everything that could go wrong did go wrong is probably the best way to describe this incident.
The gaining registrar did not follow the transfer policy and did not obtain approval from the registrant.
And in this particular case, many registrars pretty much provide services to Internet companies.
And those Internet companies that provide Web site services and E-mail services generally do the communications directly with their customers via E-mail.
And so in this case, the particular company that accepted the transfer of panIX.com failed to send the required authentication request to check the transfer.
So that was the first mistake.
Then there are all the available mechanisms that can be used to protect against inappropriate transfers.
One mechanism is that you can, at the registry, lock a domain from transfer.
In this case, that wasn't done.
Also, the previous supplier of services, the losing registrar, can also contact the -- their customer and say, "Did you in fact really want to transfer that name?" in this case, that didn't occur, either.
And in the development of protocols between registries and registrars, there is a mechanism for a password to be stored in the registry.
And that password is checked before a transfer is completed.
And in the case of the dot com registry, that feature is not used.
So the three main mechanisms that are provided for in the ICANN policy that can prevent a transfer weren't used, either.
So that's basically the incident.
Recovering from the incident.
Ended up being a situation where it was very difficult to contact the various parties involved.
Firstly, the incident occurred over a weekend.
The -- both the losing and the gaining registrar did not have phone numbers on their Web site for the general public to access that would actually access a technical person.
Then there was the issue of time zones.
So when people were contacted, let's say it was in the daytime of a Sunday in Australia, you know, that would be in the middle of the night on a Saturday in the U.S. And some other time in the U.K. was where one of the other parties were involved.
So, essentially, the combination of lack of public phone numbers for out-of-hours contact and the lack of -- and the different time zones made it very difficult to authenticate to verify that the problem was true and to take action.
So, essentially, it kind of highlighted some of the issues, that we do need to provide contact information for members of the industry to get in touch with each other, and, clearly, to be able to make these problems resolve quicker.
So when looking at that particular incident -- and if I could just ask people in the audience not to speak, because the -- I guess the acoustics of this room -- I can pretty much hear what you're saying, even though you don't think that.
So it's a bit distracting.
So I'd prefer people didn't speak while I'm speaking.
There's certainly plenty of room to speak out there or out there (indicating).
So areas for improvement, registrars should make contact information for emergency support staff available to the other registrars and resellers and registry operators.
We need to define a mechanism for resolving an urgent restoration of a domain name, and in particular restoring the DNS configuration, so at least even if there might be a dispute about who is the rightful holder of the name, at least all the services that were operating before that change, all the Web sites and E-mails, would continue to operate while more time is spent in resolving often legal disputes over the rightful holder of the name.
We need to improve awareness in the community of the mechanisms that can be used to protect against hijacking.
And one of these mechanisms is registrar lock.
We also need to consider improvements in the authentication and authorization mechanisms in the protocols.
With respect to notifying the registrant, at the moment, that's optional for the losing registrar to notify the registrant.
And that's something that we could look at, potentially making that a required step in the process.
So at least it is not just dependency on one company sending in an authentication request; you've also got the backup of another company querying that to say is that really what you wanted to do.
And so that way, you've got both the gaining registrar saying, "Is that what you want to do?" and the person says, "Yes." But maybe the information in the WHOIS is out of date, whereas the losing registrar might have more up-to-date information, and it's especially useful if the losing registrar uses information other than what the gaining registrar's using, because quite often if an E-mail address has been compromised, then it's going to be compromised for both of those parties.
So you might want to make sure that you're using some other information.
Maybe if the gaining registrar is contacting the technical contact, the losing registrar might want to contact the CEO of the company and say, "Just want to make sure that's really what you want to do." So we can look at making sure that we have redundancy both in terms of the two registrars, but also in terms of the people that we're actually checking with; we check with more than one person.
So at that point, I'll hand over to Rodney to talk about another incident.

>>RODNEY JOFFE: The incident that I was involved with was that of hush mail.
Hushmail is a company that provides secure E-mail services.
Their business is all about security.
In this particular case, timing was everything.
The attacker was able to make a call to first-tier support at NSI, the registrar at the time. And it's very important to understand also that this is not unique to -- this is not (inaudible) NSI, it's not unique to them.
We chose incidents that actually had a large number of similar incidents in the past.
These happened to be the most recent.
This one over here was based on contacting the -- NSI and convincing a first-tier support over the phone to change the support E-mail address.
The interesting thing about this is that during that time, there was a reasonably well-recognized large-scale DDOS against the DNS servers of NSI.
And it was quite credible on a weekend for a call to be made from someone saying, "I'm unable to actually move the domain because my E-mail address is in the same zone.
So I need you to change it to another E-mail address so we can then change our DNS." I don't know what the password is because I can't easily get it.
I'd like to be able to use the Web site to get the new -- to get the password and make the changes.
The -- NSI then made the change to the contact E-mail address.
The administrative contact with the new address then submitted a request for a password change, got the password change, was able to access the account at NSI, make a change to, in fact, what he could -- in this case, there were a number of E-mail address changes that looked like -- in the order trail that we were able to find, there were three or four changes of E-mail address over the course of perhaps an hour to very -- to some interesting E-mail addresses that if you'd have looked at them, you would have recognized the fact that these were probably fraudulent, words like "LiTE" and "hacker" were in the E-mail address.
But, obviously, it's an automated process after the first one is done.
They then changed the "A" record for DNS for the home page for the security company and pointed to a defaced Web page.
Next slide.
We have it up there.
The -- in this particular case, it was a social engineering attack.
The one that we talked about earlier was really in process.
This one over here started out because there was the ability for a first-level support engineer to make changes without talking to, apparently, a supervisor or a manager.
So a single person was able to make -- receive a phone call, and without really being able to validate it, make the change.
Whoever was involved in this was very familiar with the way that the process worked at NSI and it was probably very aware of the fact that at that time, NSI's hands were full trying to cope with the effects of a DDOS against their DNS that was, as I said, pretty widespread and quite debilitating.
There was obviously a vulnerability in the registrar's customer service -- in the security process.
But one thing I want to say now as well.
When we looked at this together with hushmail, it appeared that the vast majority of registrars, there was the ability for the first-level support to make changes to the account.
It wasn't something that had to be escalated to a different person at a different level to make the change.
The first-level support also seemed to have access to the passwords themselves.
So they had ability to make changes to records.
There's -- timing was everything.
It was on a Saturday during a DNS DDOS.
These things -- another important thing is these things were rectified very rapidly by NSI.
We have since checked and found out a number of the registrars that had the same kind of vulnerability or process have modified that as well.
In terms of improvement, it's really important, I think, for registrars to have a process that makes very clear when something gets escalated.
Obviously, the kind of checks that Bruce was talking about earlier are real tough when you're looking at domains that May only cost $10 or $15.
It's tough to go through the process with every single change.
But there should be a normal escalation when there is a problem that is manual and will allow things to be researched properly and for damage to be undone.
Important, we think, to not use the same E-mail for multiple purposes.
So the E-mail address that's used for the administrative contact should probably be different to the one that's used for the technical contact, so that at least two accounts have to be compromised before the change is made that cannot be undone.
Portions of the registration record perhaps should be kept off of the WHOIS records.
There are obviously some registrars that are now providing anonymous data.
But, in general, there should be portions that are -- do contain contact information that are not part of the public record.
Use more than one form of contact for transfer and registration notifications.
Two different E-mail, obviously a phone call if that's possible.
Obviously, pricing is an issue.
Try to obtain as part of the process 24/7 emergency contact information and make sure you understand why you ask for it.
People try to keep their information anonymous.
Part of that is because of spam and scraping Web sites.
But it's important to explain that if there is a problem that you're looking to undo as a registrar, you need to hopefully be able to reach the domain holder and let them know that something is occurring.
Finally, obviously, try to encourage registrants to lock their domains.
That's something I think we'll discuss a little bit later in terms of overall recommendations.
But I think the main lock is a really important process that should be more the rule than the exception.
Ram, you will pick up now on the HC problem.
>>RAM MOHAN: In the HZ.com incident, the registrant discovered that the registration information had been changed during a completely random WHOIS check.
They had no idea that their domain had been hijacked from them.
And it just so happened that they looked at the WHOIS one day and they found that the information was modified.
The losing registrant in HZ.com's case claimed that the transfer was legitimate and had an E-mail with a form of authority that was purportedly sent by the registrant, and suggested with no firm evidence of E-mail spoofing, as would be found, that perhaps there was E-mail spoofing, but we don't have firm evidence because we didn't have all the records come back from the various registrars.
The losing registrar in the HZ.com hijack case put the onus on the registrant to prove that the transfer was not authorized.
So the registrant, after having lost the name, had to show that they didn't actually authorize the name to be transferred.
And the transfer dispute had -- was submitted, but it was after the waiting period, the ICANN-mandated waiting period, had expired.
And that was because there was no overt sign of hijack.
The name had been -- the registrant other information had been modified, but the DNS information had been left untouched.
And in this case, direct intervention with the CEO of the gaining registrar led to the domain being returned to the registrant.
And the CEO based his decision to restore the domain on suspicious information, because he noticed about 80-plus domains that had been registered by the same hijacker with, you know, completely bogus information that in an automated process you would miss it, but when you eyeball it, it's fairly clear that the information is invalid, plus 1-234-5678 as a phone number.
Next slide, please.
Could we have the next slide, please.
Oh, it changed.
Got it.
In our analysis of the incident, we found no changes had been made to the DNS configuration.
So HZ.com's services were unaffected.
Now, HZ.com is a wireless information portal.
It's been in existence since almost 1995, with about 25,000 users at the time when the name was hijacked.
So the users did not see any real bad effect.
However, the registration changes may have continued undetected for an indeterminate period.
And it results in the status of the domain being uncertain.
And for the founder and the domain name holder of HZ.com, any business processes they were going through getting the business off the ground or talking to venture capitalists or any such people, HZ.com was itself an asset, which as soon as the -- they found that the -- this asset had been hijacked, its value was frozen.
And on top of it, for this individual or this business, which had branded itself HZ.com, had just lost its brand.
Could we go to the next slide, please.
Issues that we found in the recovery process.
There were -- there was incomplete audit and transaction records that hampered the investigation.
The complete domain name registration history for the HZ.com domain was not available.
And inaccurate registration information was also found.
The gaining registrar relied on an electronic process solely to obtain authorization.
Now, the transfer policy accepts consent from an individual or an entity that has an e-mail address that matches the transfer contact e-mail address. That's sufficient to say that you have proof of identity and to allow the transfer to occur.
However, in this case, the actual name holder of record never received a pending transfer notification from the losing registrar.
Could we go to the next slide, please.
In this case, some of the areas of improvement, resellers should be able to provide a complete chronology of the name holders of the domain name. Registrars should augment registration records to include dates of acquisition and a history of name holders insofar as they have that information already available with them in their databases.
And if a pending transfer notification was mandatory, would it reduce an incident like this? It's something for us to think about.
And the other area for improvement is, should the notification process have been entirely dependent and satisfied solely by e-mail notification alone? And should there have been a second contact or a second method of contact to be provided in these cases?
Next slide, please.
And do you know what? It's not just dot com. Dot com is -- the three cases we've brought here are dot com cases but that's because dot com has a great deal of resale value. But as you see on the slide behind me, these domain hijackings have a happened in gTLDs as well as ccTLDs. And if you look at the names that come up for hijacking, they're popular names, they're two-letter characters, they're the kind of names that hijackers love to get, because once they've got it and the various recovery mechanisms are not in place or you go to a registrar who is -- or a reseller of a registrar, it's very likely that that name gets into trouble.
Next slide. I'm going to pass it back to Dave to cover the meat of our findings and other recommendations.
>>DAVE PISCITELLO: Thank you very much. Before I advance some slides, I just want to make an observation. The first section of this report is the sort of compelling, interesting reading. It's all the stories. It's the incidents.
The reason it's here is not to call attention to anyone, but to call attention to the fact that the problems are real and the threat is real.
It's much more important if you're reading this document that you set that aside and you look at the rest of the document, which is presented as one normally would as a security consultant to someone that you're doing a risk assessment and trying to do a risk/benefit analysis in what kind of business opportunities or threats you have laying in front of you.
So I'm not telling you to read section one, but take section one with a grain of salt because section one is just like almost any postmortem of a security incident. Much of the information is never going to be accurately recovered. We're relying on second and third party sources for a lot of our information because in a lot of cases people are unwilling to disclose exactly the circumstances under which a security incident occurred.
So we can derive and conclude a lot from that information, but we've intentionally left some detail out of those incidents because, A, we don't know everything about them, and, b, we've tried to be as accurate and fair as possible.
So with that, I'll move on to the next slide, please.
We're going to break down risks and threats to all the different stakeholders in the domain name process. And I'm starting from I think the most important stakeholder which is the holder of the domain name. This is the person who in fact has the most to lose and in many, many different ways.
Obviously, loss of a domain name for the sake of someone having taken it from you and sold it to a high bidder or taken it from you and extorting you to give it back is a real threat.
Tarnish of brand. It's very clearly the case that the Hushmail incident is a very good case of a security-oriented company who has this black cloud hanging over it, spoke to the CTO and he indicated this is really bad. The first time you type in Hushmail at Google the first thing you see are articles that talk about the domain name hijacking. That's not what they want to be remembered for. What they want to be remembered for is they're a secure e-mail service. That's all negated by one single malicious act. How do you measure that in dollars and cents or Euros?
The other problems that we have are the use of hijacked domain names, among many uses of repurchased domain names, for fraud, identity theft, monetary theft. They're very, very useful in pharming and phishing. They're also very helpful, even if you hold them temporarily, to provide legitimacy to your domain in the case of being a Spam originator. So there are a lot of good, practical ways that people who actually gain a domain name cannot only hurt you but can make a business out of hurting you.
Political, commercial, and personal espionage. If you hijack a domain name and you set up a mail server under that domain name and you intercept or receive all the mail from that domain, in the case of Panix it didn't happen but it could have happened that thousands of subscribers e-mails could have passed through in plain text and sat on this server for later analysis, and we all know how many different things can be disclosed in electronic mail.
Business interruption and collateral damage I'll deal with together. In collateral damage, in the case of Nike.com, as an example, when Nike's domain name was hijacked, an entirely innocent third-party web hosting company received all of Nike's traffic. This web hosting company didn't have anywhere near the bandwidth or capacity Nike did and they were essentially subjected to a denial of service attack.
Loss through litigation, we don't have any evidence that anybody has gone after a registrar or reseller that I lost $100,000 because I was down an hour, but you can be certain that if one of the top five E-merchants loses its domain through somebody else's neglect and they're down for an hour they're going to look for someone to get some sort of recovery.
The last one is obvious as well. There's a loss of customer confidence and customer attrition for the registrant. And you can't manage your own domain name. It doesn't matter who is at fault. The perception is you can't manage your own domain name.
Next please.
To registries, registrars and resellers -- we're on slide 18 of 48, so I'm going to speak fast and I will skip over some things.
Again, tarnish of brand. Who wants to be known as the reseller who botched a domain name transfer or a registrar. Who wants to be the party being sued in litigation. Who wants to be affiliated with a registrant who is perceived as not very competent or not to follow policy. From ICANN's perspective, we also have to be very careful that if registrars are just not doing the job that we expected them to do, that they -- we don't want them continuing operating in that fashion and so we have to think about measures that help us enforce good behavior and good service.
Again, with the registrar, loss of customer confidence and customer attrition to other registrars.
Next, please.
I'd like to look at some vulnerabilities that we have observed from domain hijackings. Next. All of this is in the report. Next.
There's a huge potential for registrant fraud and a part of this has to do with some of the credentials that we rely so helpful on in electronic communication. But it's not just electronic communication. There have been incidents where registrants have been subjected or impersonated through the use of physical credentials that are also accepted forms of identity in the transfer policy. People have taken letterhead, used the letterhead of a company, forged a request for domain transfer, faxed that, mailed it. People can do an awful lot in the way of using physical evidence to do just as good an impersonation as an electronic impersonation.
Social engineering, as was the case in one of the incidents we reported earlier.
A common one, however, is using information that's publicly available that happens to have multiple values. We use an e-mail address to log onto a registrar's Web site. We use that same e-mail address to send an FOA. We use that same e-mail address in many, many circumstances where in one place it's an identity, in another place it's an authorization code.
In the business world, in identity management, we never do this. We're always very careful to have a very clear discrimination between identity, password, or authentication token and authorization tokens. We need to have that same rigor in the way that we deal with domain names.
There's a big long list of registrar or potential areas of abuse and exploitation of registrar processes. I'm talking everything from the time that a registrant asks for a domain to the time that a registrant either with authority or as the victim of an unauthorized attack concedes that domain to someone else.
So social engineering, we talked about. Forged documents we talked about. Authentication credentials disclosed to unauthorized third parties by first tier support we talked about.
We talked of gaining registrars using only one form of contact and that form being one that happens to be vulnerable to impersonation or fraud, e-mail address.
Some of the other areas where we are vulnerable is I don't think we ought to be telling registrants what they ought to be doing to protect their domain names from hijacking.
We need to be a little bit more public facing with information regarding registrar lock, regarding EPP auth info, and regarding other measures they can take to try to ensure their domains and DNS configurations are not abruptly altered in an unauthorized fashion.
Domain locks are not uniformly set across every single reseller and every single registrar. I personally find that to be a problem because I think that when you're dealing with millions of people who are not technically savvy, it's a whole lot easier for them to understand that this is the way that everybody does things than to try to figure out who does it and who doesn't.
Registrars also have -- in some of the scenarios, the Panix scenario as an example, have failed to follow authentication processes. This is not the way we want to operate.
I'm going to skip a few of these. One point to make at the bottom of this is that registrants have a responsibility to help the process by keeping their registration records accurate and up-to-date and by keeping them in some way insulated from fraud themselves. That's not a reseller or registrar's problem. If I have a large organization, I shouldn't be letting a second year I.T. staffer deal with a thousand of my domain names and have him be the administrative contact and when he leaves the company I should make certain that the name doesn't stay in his possession for the next 18 months.
Another problem that we find is that it was very hard for us to get a full history of registration information as in the case of the hz.com. In many cases it's hard for the registrant to get the information to prove that he was the owner or rightful holder at the time of an attack.
We do need to have some best practices and set standards for auditing, not only at the registrar level but also registrars auditing the resellers. ICANN doesn't have any relationships with resellers. It's important that the practices that ICANN tries to oversee with resellers is also overseen by registrars to their resellers. It may be even more important because resellers sometimes are the aggregate representative for hundreds and hundreds of individual registrants.
Recovery mechanisms. Quickly, we have the UDRP today. We have the TRDP today. What we are proposing or recommending that the community investigate at this point is a new channel of action that would allow what we have called or dubbed an urgent restoration of a domain. In the press interview this morning, Steve made a really good analogy, he says what we need is something like the fire department. We already have something like a court of law where we can dispute a domain name and we can go through a formal process and that might take days, weeks, even months. What we need is something that happens in minutes. And something that can -- or hours, and something that can actually result in a DNS configuration being modified. And importantly, time to live values in DNS records set low so the DNS information is propagated through the net as quickly as possible.
So we propose an action channel that basically consists of emergency contacts in some form of a database or some form of accessible information for all resellers, all registrars so that if there is a multi-time zone in an actually scoped existence, we can resolve this quickly.
We also need registrants to cooperate because we need the right contacts for registrants in many of those situations.
Part of this also is a public awareness campaign.
What does the action channel look like? 24 by 7 access to registrar technical support and that staff has to be authorized to assess a situation and determine the legitimacy of the claim. We're not claiming that this is a very easy thing to do but we do think that this is something that we have to investigate.
What's the immediacy of the need? Is this something that does end up being a dispute that doesn't require an immediate change or is this a situation like Panix or hush where traffic is going to the wrong place, and it's causing material harm or collateral damage, as an example and we also need that staff to be authorized to act. If they've made their best judgment, they've made their determination, we need to have them restore the registration record to the rightful owner and believe that that's the right thing to do.
We also obviously need a policy to go along with this action channel. I'm a security expert so I'm just learning some of the subtleties and nuance of using the word "policy" as it's used in the context of ICANN versus the context of developing a security policy for a business or organization.
I tend to mean this to be a policy that says here are the things you have to see that your implementation satisfies. When you go out you put an action channel into place and that's what I'm talking about here.
The most important factors here are to make certain that this complements and does not conflict with the TRDP and it does deal with the distinguishing characteristics of immediacy of harm, magnitude of harm and escalating impact, again meaning collateral damage.
Time check and question to you. Do we want to just get to the findings and recommendations?
>>STEPHEN CROCKER: Yeah.
>>DAVE PISCITELLO: Let me say one minute about the next four or five slides and we'll make these available as quickly as possible so you can take a look at them.
We've come up with a number of steps that registrars, registrants and resellers and ICANN can take to significantly improve the process as it exists today. We don't feel that there are dramatic changes that are necessary. We feel that there are a lot of things that people are just not doing well.
So we're going to be making a significant effort to educate registrants because a lot of this starts at the registrant. But it goes all the way back through to ICANN in terms of just little tuning and fine sanding and steel wool and another coat of lacquer to make this polished and right.
Thank you.
Steve, could you go to slide 39?
>>STEPHEN CROCKER: Thank you, Dave. This deck of slides is a bit dense and we're going to skip -- I'm going to skip over the findings, so we're going to go even a little further, because the findings basically are a summary of the things that you've already heard and I want to move right to the recommendations. And that is slide 44. Good. Slide 45.
So we -- as is our usual style, we divide up what we're saying into facts and opinions of what happened in the past and what we've seen. Those are the findings. And them recommendations to go to the future. And I need to emphasize that, again, our role is purely an advisory one as opposed to an enforcement or a judicial or a legislative type of function.
So these recommendations are intended to be read and thought about and determined as to whether they should be accepted or acted upon.
So they are input to a process rather than the final output.
So with that said, first one is that registries should ensure that the register lock and the EPP auth info are implemented and that registries should confirm that registrars do not use the same AUTH info code for each of their domains. The actual wording of these are longer and more precise so I commend you to read the report.
The second major recommendation is that the resellers and the registrants should provide -- should be provided and should -- with best common practices that describe the appropriate use and assignment of EPP AUTH codes.
Within the existing transfer policy today, when a transfer is initiated, there is a gaining registrar and a losing registrar, or more precisely, when there is a transfer between registrars. There is oftentimes a transfer within one registrar or even within one reseller. So the gaining registrar sends notification over to the losing registrar, and the losing registrar has at its -- can choose whether or not to notify the registrant. Some do, some do not.
Our recommendation here is that it should and that this should be moved from an optional to a regular part of the process.
Those three recommendations taken together are a strengthening of the protection for the registrant in order to prevent the unauthorized transfers.
Recommendation 4 moves into another part of the cycle, what happens when something goes wrong. And the recommendation which you've heard the elements of is that there be a new way to communicate or a more regular way to communicate with registrars for urgent corrective action. Not to solve contractual disputes, not to solve billing disputes and so forth, but to restore connectivity when connectivity has been lost. And that's what we have been calling the emergency action channel for each of the registrars.
Next slide, please.
Recommendation 5 is a consideration of -- to support the emergency action channel of what criteria should be used, because if you bring out a new mechanism, you can create as many new problems as you solve. Somebody could have a legitimate transfer of a domain and somebody else could call up and say, oh, that shouldn't have happened. Restore it back the way it was. And so you get a sort of backwards denial of service, if you will.
Recommendation 6 is an attempt to increase public awareness of how all of these pieces fit together. What the procedures are the registrant should follow and how to request intervention. And so taken together, those recommendations all fit together into a coherent set.
Next slide, please.
Recommends 7 goes to the accuracy and integrity of the registrant records. And this cuts into and touches on WHOIS issues, but here the primary focus is on the records maintained by registrars as opposed to particularly the public WHOIS records.
Recommendation 8 is improve the awareness of hijacking as a -- and registrant impersonation and encourage everyone to use the registrar-lock and AUTH info with the potential even of supplementing that with monitoring and maintenance information.
And recommends 9, next slide, is a question posed to ICANN about whether the enforcement mechanisms are strong enough and whether or not the use of the enforcement mechanisms, which it's our understanding are principally done quietly and behind the scenes, might be made more public. This again is the kind of recommendation that has consequences, and they may not be the right consequences. There's oftentimes value in public visibility of enforcement, but there can be negative consequences. And so we ask that a consideration rather than we know for sure that that's the right thing.
And finally, whether the identity verification requirements in electronic correspondence should be strengthened. If one compares those requirements with what's required for physical correspondence, there's a tremendous disparity, and so there is a propensity for exploiting electronic correspondence and maybe perhaps more than for physical correspondence.
Before I bring this to a close I want to acknowledge and thank the strong participation from several members of the ICANN staff. DAN HALLORAN, Karen Lentz, Tim Cole, Tina dam, is Tina still here? Went off. And the -- that team had already dealt with these incidents in much closer to real time, and as I said at the beginning, our purpose here was to step back out of the fray and take a look at the broader system aspects, but very much in concert with the people who are on the line to make the system work.
And we had cooperation from quite a few other people, including the registrants who were affected.
With that, let me ask if there are any additional comments that the panelists want to make.
Wise move.
And are there any questions or comments that -- from the floor where somebody wants to add a relevant issue, relevant point?
Vint.
>>VINT CERF: This is just a question. Should I assume that now the report has been issued, this has now formally come to the board as a report from your committee?
>>STEPHEN CROCKER: Yes.
>>VINT CERF: So we can now take some action on it.
>>STEPHEN CROCKER: So as a matter of form, we have -- I guess we will put a cover note and formally deliver it, but it is now delivered to the world. The press releases are out, it's posted on the web. Let's see; in fact, I promised -- can we go back to slide two? Yeah. Slide two has at the bottom of it the URL for the PDF version of it.
And so not only is this for the board, although the real action points for the recommendations are mostly elsewhere. They're mostly the registrars and the various constituencies and, to some extent, the ICANN staff. But I think that it is as you're implying quite vital for the board to be aware and cognizant of these activities. And I see a couple of board members here and that's very nice.
>>DAVE PISCITELLO: Steve, if you can't see that URL, you can go to WWW.ICANN.org, and it is on the front page, still, i believe, as one of today's events and you can get the link directly from there so it is an easier hyperlink.
It's a very good point. I appreciate you raising it. And the question I had in my mind when I saw it on the front page is I wonder how long it will stay there before it's pushed off by the next big event.
Bill.
>>DAVE PISCITELLO: Rodney is looking at it in real time and it's there.
>>STEPHEN CROCKER: We're over time? Is that what you're saying?
>>BILL MANNING: He said Rodney is looking at it in real time and it's still there.
>>STEPHEN CROCKER: I figure we have a few more moments of fame here.
>>BILL MANNING: The next big event hasn't happened yet.
My question, as I was partially listening to Dave talking about these interesting things and thinking about what my current registrar wants from me, there's the question of actually who is the legally empowered entity for that? Do I own that domain name or does my registry or registrar hold that? And that seems to be ambiguous because some registries or registrars say that's really their intellectual property and they're just loaning it to you.
Or am I in the wrong century?
>>STEVE CROCKER: Let me give a brief answer to that.
You've used a very loaded word of "ownership." And I think the standard answer is, they're not owned by the registrants, but they have a right to use.
And therein begins a long, complicated discussion.
We very carefully chose not to try to go -- to untangle that.
Nor do we think it's important at all.
What is important is that there is a -- the obvious expectation, registrants are using domain names.
If they're taken away abruptly and improperly, then they're hurt.
And there may be underlying legal -- there may be situations in which the kind of question that you're raising comes into play, but for the kinds of incidents we're talking about, that's not the issue at all.
>>BILL MANNING: Then your fire -- what was it, your firemen?
>> fire department.
>>BILL MANNING: Fire department ought to have the Good Samaritan clause, because if I get grumpy that you have taken my thing away, I might get mad.
>>STEVE CROCKER: That is actually an important point and relates back to this question of if there's an emergency action channel and if there is a restoration to the status quo ANTE until it's sorted out, is that itself an act of harm.
And that's what we did touch on about what level of authentication and query, what the standards ought to be for that.
And, yes, an implication of that is, in the spirit of doing that, wouldn't want to have the next problem of then the registrar, the new registrar or the old registrar gets sued for having interfered.
Yep.
>>DAVE PISCITELLO: One thing that we want to do is achieve a point where our identity and our authentication and authorization processes are tight enough where it is easier to identify whether or not there is some sort of malice or attack in progress, or fraud.
You know, right now, we can't do that as well as we probably ought.
>>JORDYN BUCHANAN: Hello.
Is this on?
Can you hear me?
>>STEVE CROCKER: Are you live? I think you're live.
>>JORDYN BUCHANAN: Okay.
Great.
So my question --
>>STEVE CROCKER: I'm sorry.
Would you identify yourself.
>>JORDYN BUCHANAN: I'm sorry.
I started trying to announce myself.
Jordyn Buchanan with register.com.
My question is, when you refer to this emergency action channel, is it anticipated that -- is that basically just getting in touch with another registrar behind the scenes or is there any way if you can't get in touch with the registrar, is it anticipated there will be some sort of technical mechanism to sort of yank the name back? Or is it purely something that two registrars agree to do between themselves? Is that -- I can't really tell from the recommendations what's anticipated.
>>STEVE CROCKER: Yeah.
So the terminology may have been ambiguous.
What we meant is the equivalent of a hot line or of a -- or a 911 in the U.S. where you can say -- you can reach somebody and get some response, as opposed to we're down -- we're -- please call us during normal business hours, and that's 48 or 72 hours from the time that the incident appears.
So this is a -- the intent is a 7 by 24 real person way of getting attention for exceptional situations.
>>JORDYN BUCHANAN: Right.
So I guess you're saying that, I guess, theoretically, registrars would be obligated to have such a facility available, and that's what you would use to resolve a situation like this, as opposed to a technical mechanism to sort of undo the transaction or something like that?
>>STEVE CROCKER: Yeah, one could start to invent technical mechanisms.
But now you're into a very extended and complicated set of issues.
And what is the safety and reliability of those mechanisms compared to the mechanisms that have just been shredded by a hijack, and you've got a whole new set of things.
So this recommendation is a very simple, ordinary human-oriented one.
Get some people involved.
And if -- one could imagine things could develop in the future in a different way where there would be an automatic rollback and so forth.
I see Bruce -- are you queued up there to -- oh, well, then let's have it.
>>JORDYN BUCHANAN: Actually, just one final -- minor follow-up question.
Did you look specifically -- so if that's the case and you're essentially just requiring that these companies -- that the registrars -- or not -- you're not requiring.
You're suggesting that registrars have a contact channel in all cases.
Did you look at the recent phenomenon of these registrars that are being created that, you know, are essentially -- people call them different things, shell credentials or these things that don't really exist as companies that you can go and interact with on a regular basis.
>>STEVE CROCKER: Yeah.
So for the benefit of everybody, I'm not sure my numbers are accurate, but in round numbers, there's about 150 companies that are selling domain names in the usual way and servicing registrants, and another 300, approximately, that are these kind of shell companies whose purpose is to buy threads to bang on registries for deleted names.
Do I have the roughly right picture you guys? You don't know.
The good news there is that if they're not servicing registrants, then they wouldn't have -- then nobody's going to call them up and say, "Please restore my domain name," because they're not selling those.
>>JORDYN BUCHANAN: They do register names.
They are the sponsoring registrar for a significant number of names.
>>STEVE CROCKER: I see.
So the alternative is that many of those are all the same company.
I mean, there's a sort of holding company.
There's nothing that would preclude one telephone number serving a large number of registrars of record if they were in fact all the same.
>>JORDYN BUCHANAN: Okay.
Thanks.

>>STEVE CROCKER: Bruce, were you waiting to get in --
>>JOHN LEVINE: I'm John Levine, a member of the ALAC.
I'm observing that this is an instance of the general problem that establishing the identity of the being at the other end of a TCP socket is difficult. And establishing identity in general is expensive.
And I am noticing some domains are a lot more valuable than others.
I'm wondering if you have looked at the possibility of establishing multiple tiers of domain authority so that -- so that you can sign up for the platinum service and if it's some random thing of mine, I can make do with the current hodgepodge.
>>STEVE CROCKER: Yes.
>>JOHN LEVINE: Could I have any further thoughts on this topic?
>>STEVE CROCKER: I think the man behind you wants to speak to it.
>>BRUCE TONKIN: I'll -- I'm wearing different hats.
Maybe I should ran back up there.
Wearing my hat from security SAC point of view is those services already exist and so I can give you cards of people who can help you if that's what you want to do.
But that's a different topic.
The -- and they're mentioned in the report, are they? Yeah.
I guess the comment I want to make is really just as a member of the ICANN community.
And that is probably this is, I guess, looking at it from a process point of view, if you like.
But, okay, the SSAC produces a report.
Now what happens?
>>STEVE CROCKER: Yeah.
>>BRUCE TONKIN: And, really, I just wanted to comment on that question.
And I think probably what would be useful is to take from that report and actually begin to create on the ICANN Web site a best practices area for the guidance of registrars and resellers and registrants and so on.
And so what would be useful as a very first step, perhaps if the board said ICANN staff, please create a best practices area on the ICANN Web site, and take the, you know, recommendations, if you like, from the -- SSAC's report and stick them there.
The next question, then, is, does the community believe that we need to go beyond just some best practices? Does the community believe that it is a sufficient problem that ICANN should mandate something for registrars and re- -- and registries? If that's the case, then the ICANN board should ask for an issues report for the council.
And there's a process for doing that.
And then the third component of that is that if there is an agreement on something that should be made compulsory, then we need to think about the compliance side of that and having, you know, ICANN staff check to see that registrars are doing that.
Now, the further I go down that chain, the more expensive things become.
And so I guess what we need to be doing, perhaps, is the cheaper part of it is putting best practices and creating some documentation.
So a lot of what's here is what any sensible company should do.
But, you know, I know from my -- you know, Melbourne I.T. had sort of direct technical people to some sort of resource like that.
So while you're doing a new thing, here are some things others are doing that's generally considered to be industry best practice, and they can help do that.
And it may well be sufficient.
And that's a very cheap way of getting an outcome.
If, however, we're finding that registrars are not doing that because there's not a commercial or market incentive to do so, but there's a negative impact on registrants, then the board or the council should be saying, "Right, we need to do something." So I just wanted to start that thinking a little bit.
And perhaps it's a little bit of a comment to Vint and the board as to what do you do when you get this report? And what I would be recommending is, first thing to do is to perhaps direct the staff to create a best practices area, and you stick this stuff in it.
And then maybe after a while, maybe we leave it for a bit, then decide whether we need to take further steps.
>>STEPHEN CROCKER: Let me take what you said to heart, and as you said, it is complementary to the question Vint asked about transmission. And I think that what you've just done is outline what we should put into a formal memo of transmission and a specific set of suggestions for follow-up actions. And it's good that it's written down here. And Dave and you will work on this, and that will be great.
So I appreciate that a lot.
>>DAVE PISCITELLO: Steve, can I make one comment in response to what Bruce said?
One of the things that I think is important here is that we don't present this as an obligation but an opportunity. There may be many, many people who don't care about domain -- or locking their domain, and they may be very happy paying as little as possible. But there are lots of other people out there, even small businesses who simply have a brand as a result of using a domain name years for that would be happy to pay three, four, five times what they're currently paying or more, to be certain that nobody ever transfers their domain. It always stays with the same person.
There are two extremes here. I would like to take my domain in perpetuity and have someone protect it and never move it and whatever it costs, it costs. That's my personal feeling for my domain name, because I have reasons to do that and I'm sure there are lots of people other than me that want that.
There are also lots of other people that don't care. Whenever I see that in a business world, I see opportunity, because there's differentiated services.
>>STEPHEN CROCKER: Right.
>>RICHARD LAU: Hi, Richard Lau from domainclip.com. I've worked on a few dozen domain hijacking, and domain hijacking recoveries, many of which have not been recovered and I just want to ask about the UDRP which is an alternative to the court of law and we have the TRP, and the UDRP is very much -- well, designed for trademark holders, TRP obviously for registrar transfer disputes, but in your urgent restitution or -- of a domain name, have you considered expanding that to a registrant dispute resolution process where the registrant, rather than going to a court of law, you know if the domain has gone from one registrar to another registrar to another, and the current registrant is in China, you know, the expense of going to a court of law is going to be quite substantial.
>>STEPHEN CROCKER: So let me speak to that.
Our primary focus here was on the immediate repair where there's been a specific and current, immediate, recent action. We were not at all intending to -- in fact, in the report we make a point of not trying to perturb the existing resolution mechanisms. So there is obviously -- one could say something like that and there are obviously some boundary conditions as to where things are.
The general thrust of what we have been recommending is to undo a quite recent event, and then bring other processes to bear rather than a substitution or an override of those processes. If there are failures in the UDRP mechanism because it's too helpful weighted for trademark disputes or it isn't enforceable or things like that, then I'll just say I think that's a different class of problems than the ones that we were specifically focused on here and may deserve its own kind of attention, but it isn't -- I wouldn't take what we're focused on here and try to stretch that to cover those kinds of cases.
So that's where we are.
In the interest of time, let me thank everybody and bring this to a close. I appreciate your attention. Let me commend the report to you.
We are eager for comments and for suggestions. We'll be happy to follow up. And we have appreciated the comments we have already seen and heard. And with that, we bring this session of open SSAC meeting to a close. Thank you
(Applause.)
>>DAVE PISCITELLO: At the risk of starting a small stampede, before a comedy of copying or facsimile errors made it impossible for me to make more copies, I did get ten copies and if you don't have a laptop and you don't have any other way of getting a copy and you want to take one of the ten, it's the pile that appears to be white paper but that's because they're face down.