SSAC Open Meeting ICANN Meeting San Juan, Puerto Rico 25 June 2007 >>STEVE CROCKER: All right. lock the doors. Don't let anybody else in. I think we've reached a reasonable stable point here. I know there's a lot of competing meetings going on. My name's Steve Crocker. I'm chair of the ICANN Security and Stability Advisory Committee. Welcome. This is our public meeting. We regularly schedule one of these during the ICANN week to present current results and make ourselves available for questions and general discussion. Today we have a fairly packed agenda, actually. I'll say just a word, as I usually do, about SSAC. And I think I actually am going to skip over past and current work, turn the floor over to Lyman Chapin to talk about the RSTEP process. I'll take the floor back briefly to talk ever so little about the Estonia attack early last month. And then we have two substantial pieces of work. One is a security and stability study of IDNs that's under way that Ram Mohan is leading. And this will be a sort of preliminary in-progress report. And the other is a report on the interaction between WHOIS and spam that we have some interesting data to share. And that work is essentially complete, subject to tying up some loose ends in the reporting. And, again, RAM led that work and will be presenting. That. So that's our agenda today. Let me launch forward immediately here. Here's the list of people who are members of the Security and Stability Advisory Committee. Let's see. Ram Mohan here, I will introduce Dave Piscitello and Lyman in a minute. Who else from the committee is here? I see Suzanne and Russ in the front row, Elaine back there, and is that it? That could well be it. It's a feature of our committee that we tend to operate in a pretty distributed mode. There's never been a case where we've all been in the same place at the same time. That's a part of how we achieve a certain degree of safety and security. A number of other people participate on a regular basis in -- for various roles, David Conrad, general manager of IANA. And we added some other people that I should update the slide. Who else from your team is on? >>DAVID CONRAD: From the IANA team, SSAC? >>STEVE CROCKER: I thought -- oh, I know. We added Steve Conte. >>DAVID CONRAD: Right. Steve Conte. >>STEVE CROCKER: That's my error. So don't tell him. I'll fix it. Dave Piscitello, raise your hand, Dave, is SSAC fellow. He's the guy that we tag with getting the writing done and transforms our initial thoughts into serious pieces of work that make it all real. Jim Galvin handles all of the arrangements. Lyman heads up the -- a specialized group that looks at registry requests. And he'll describe what he does there. And raise your hand. Let's see. And Robert Guerra -- help me out here. >> You pronounced it right. >>STEVE CROCKER: Guerra. Good. The ALAC, the At-Large Advisory Committee, is coming into its own, gathering muscle and shape and direction. And among other things, has reached out to us and said, "We ought to find ways to cooperate." And Robert has just emerged as a liaison to us. And I'm looking forward very much to working with him and a handful of other people listed here. We met with the Governmental Advisory Committee a couple of hours ago and at their request, covered SSAC activities in general and two particular topics, DDOS attacks and DNSsec. And, of course, in the area of DDOS attacks, the recent attacks within Estonia last month are the high-visibility event, even though there's lots and lots of DDOS attacks all the time. And I'm just going to show you briefly what I said there, highly condensed, so that we can move on with the rest of things. Estonia is a small Baltic country, 1.3 or 1.4 million people, with a substantial ethnic Russian minority which plays a role in the way all of this came about. Very extensive use of the Internet. People online all of the time for banking and voting and buying gasoline and a standard part of the daily life. The description I've been given is that real life and Internet life are not really distinguished from each other, that it's all part of the same thing. And it has only a couple of connections to the outside world. Bill, how many external connections? >> I think there were six or seven ISPs that had international connectivity, and, essentially. All of those were (inaudible) either two or three ways. So by comparison with the U.S. for instance, a very small. But by comparison with most countries of that size, it's pretty well connected, actually. >>STEVE CROCKER: That's interesting. Because the description I was given was two. And your numbers come out to be more like 15 or 18 or something like that. >> Perhaps you were looking at a single ISP. Each of the ISPs have, like, two or three connections. >>STEVE CROCKER: Right, right. All right. A relocation of a Russian-era statue triggered a lot of protests. That generated both physical protests in the street and action by a range of people, some defacement of sites, a fair amount of DDOS activity. And in the end, it was external armies of bots driving traffic into the country from the outside in the government sites that was the predominant attack. And the solution to that was to cut off the traffic. Lots of coordination and cooperation internally. We had the technical community and the government ministries. And help from outsiders. And I suspect that the fact that the right meeting was taking place in the capital in Tallinn was helpful in the sense that there was a lot more talent on the ground than there might otherwise have been. So that was sort of the shortest description of this that you'll ever see. And here is reference to an MP3 talk by somebody who was there. All right. Oops. I didn't do it in the order we said. But, anyway, Lyman. >>LYMAN CHAPIN: I thought I'd been left off the hook. >>STEVE CROCKER: Nope. >>LYMAN CHAPIN: Thank you. >>STEVE CROCKER: In fact, with that, I'm going to move back to my seat so I can see the other presentations. >>LYMAN CHAPIN: Is this -- I'm not going to put up any slides, so you won't be missing anything if you don't have access -- or can't see the screen. As Steve said, my name's Lyman Chapin. I chair a group called the Registry Services Technical Evaluation Panel. And this is a group that was set up to act as a, essentially, resource in waiting, a group of people who are competent in the areas of security and stability of the Internet and the DNS in particular who at relatively short notice would be available to convene in the form of a five-person panel to spend 45 days -- which is the statutory period allowed by the registry services review process -- to spend 45 days examining the potential consequences for security and stability proposals from the gTLD registries to introduce new services. And there are two things that are important to recognize right off the bat about what this RSTEP, the acronym, the RSTEP, what the RSTEP does. First of all, it does anything until it is asked to do something, in this case, by ICANN. If ICANN determines, for example, that a registry service that's been proposed does not require a technical review, in other words, it's relatively obvious that no security and stability implications arise from the registry service proposal, then there's no involvement of RSTEP. So it's only when a registry proposes a service and ICANN -- the ICANN staff looks at the proposal and makes a determination that there is a requirement to evaluate, to thoroughly evaluate the proposal for potential impacts, that an RSTEP review would be invoked. The second important thing to recognize is that there is an entire apparatus for submitting and considering registry service proposals, what's colloquially called the funnel process, of which the RSTEP, the panel that I chair, is one part. And it's a part that is not necessarily invoked in every instance. In fact, in most instances, it's not necessary to conduct a thorough review. So the good news is that when the process works smoothly and the registries are talking and the channel between the registries and ICANN is open and high bandwidth, very few circumstances arise or should arise in which a registry proposes a service that genuinely threatens or genuinely potentially threatens Internet security or stability. Those are the only circumstances in which the requirement to conduct the kind of in-depth review that my panel would conduct actually arises. So at the moment, between the last time I had an opportunity to speak at one of these SSAC open sessions and this meeting, there have been no such proposals from registries for services, and so there's been essentially no RSTEP activity. So this is just an update and a status report. But there's nothing of any particular interest. There is some overlap between the SSAC membership and the RSTEP membership. Russ Mundy, I think, is the only overlap representative that we have present at the moment. But RSTEP is not a subcommittee or subunit of SSAC. It's independent of SSAC in the way it operates. And the person that is the point person on the ICANN staff for both RSTEP and the entire funnel process is Patrick Jones, who, Patrick, if you can raise your hand just so people know who you are. And, Steve, thank you. That's all I have to report. >>STEVE CROCKER: Since I've moved off, let's move smoothly over to RAM. >>RAM MOHAN: Dave, tell me what I have to do here. >>DAVE PISCITELLO: Excuse me? >>RAM MOHAN: Tell me what I have to do. >>DAVE PISCITELLO: Just -- >>RAM MOHAN: Thank you. In February of this year, the SSAC began a study that attempted to find out whether the WHOIS service was a source of -- for e-mail addresses for spammers, for data harvesters. The objective of the study was to look at the correlation, if any existed, between the publication of WHOIS data and the delivery of spam to e-mail addresses that were accessible via the WHOIS. Now, we've -- we first began with looking at, you know, various ways by which spammers obtain e-mail addresses. Spammers harvest e-mail addresses from many sources. Some of them are listed up here on the screen. And one of the things that we'd like to point out is, it's not just about spammers, but it's also about data harvesters, folks who gather e-mail addresses and then sell them or give them away for whatever reasons. So we cover both of them and we call spammers, data harvesters and spammers. And, really, our focus was, among these various methods that spammers have to harvest e-mail addresses, is the WHOIS service another source for these folks. Now, registrars and registries, we also wanted to find out, can they help mitigate automated e-mail address collection by these spammers. Now, today, registries and registrars offer services that protect e-mail addresses from automated collection. And they do it via CAPTCHAs, the image that you see on the right-hand side of your screen that you have to type in. It's an image that is easy for a human being to look at and identify what the words or the numbers are, but it's actually quite hard for a computer to look at that image and distinguish the words or the letters that are in the image from the background image that is there. So that's called a CAPTCHA. In other cases, we find registries and registrars use rate-limiting techniques that put a limit on how many queries may come from a given source. The source often is rate-limited by an I.P. address or an I.P. address range. And depending on how much -- what the volume and the frequency of the queries that come in automatically, you will find that the responses are truncated or completely shut off. In other cases, there are antiscripting techniques that are in use. There are many other techniques that registries and registrars use. We were looking to see whether the use of such techniques, whether it actually did mitigate automated e-mail address collection or not. Now, we call all of these measures, we call them protected WHOIS in our study and in the report that we'll be publishing. And in today's presentation, you will find us talking about these as protected WHOIS measures. Now, the -- there's another category of protection. And that is called delegated WHOIS. Now, registries and registrars in many cases offer a service, particularly registrars, they offer a service that protects available e-mail addresses from display and abuses. Now, there are two types of services that are offered by registrars. One is to merely substitute the e-mail that is used -- that is displayed in the WHOIS display when you -- when you ask for a WHOIS request, the e-mail address that comes back, if you are the registrant and you submitted your, you know, Joe at XYZ.TLD, the registrar substitutes and replaces that e-mail address with a completely different e-mail address that is their own. There are other systems where the registrar actually substitutes themselves. They become the registrant for the domain name. And they act as your proxy, legally appointed proxy. And in all of these cases, we find that the registrar employs pretty vigorous spam and antivirus filtering at their systems before the e-mail gets to you. Now, the customer, the registrant, chooses to have a third party listed as a registrant. And all of these measures, we've called them delegated WHOIS services. So the clear difference is that you can get to a registry or a registrar that offers protected WHOIS services without getting delegation. And you can get to registries and registrars that provide delegation as well. So our objectives were -- We had five objectives in our study. Number one, do spammers and data harvesters, do they collect e-mail addresses from domain name registration records using query-based WHOIS services? Second, do measures that exist to protect query-based WHOIS access, do they actually work? Do they decrease the volume of spam delivered to the user? The third is, do e-mail substitution and antispam services provided by registrars in the delegated WHOIS mechanism, does that decrease the volume of spam delivered to a registrant? And does a combination of 2 and 3, does it have any effect and is it a better effect than just 2 or 3 above? And do spammers favor one top-level domain versus another? Now, our methodology was to register domains in four top levels, COM, DE, info, and org. We identified and published the e-mail addresses in the WHOIS, and what we did was to avoid a name bias in selecting e-mail addresses. We just picked a set of randomly chosen names, and we put them -- we registered them, and then we made those e-mail addresses available through a WHOIS request. Now, what we also did was we made sure that the -- the e-mail address was not used or published in any other forums at all. So the only place where the e-mail address was physically directly available as a result of an action that we took was through the WHOIS or as published in the WHOIS service. Now, the experiment that we did was to monitor e-mail that was received at these addresses under various different conditions. Now, our assumption is the following. Because we did not actually publish or use the e-mail addresses anywhere other than where it was accessed in the WHOIS system, we presumed that any messages delivered to e-mail addresses that came through were unsolicited and bulk e-mail, they were spam, as a result. So we looked at registering names in -- with only protection enabled, the protection and delegation enabled, and then we tracked e-mail to see how much of the e-mail came through specifically to the e-mail address that was published in the registration record. So an example here would be if you had used info@domainname.TLD, we tried to see how many e-mails, spam e-mails, came specifically to an address that Was, you know, yourname@domain.TLD. We also tracked how much of e-mail came through to any other e-mail addresses that were under the registered domain name. Now, we know that spammers will often end up using either dictionaries or standard names, they send e-mails to support@, whatever the domain name is, or info@, et cetera. So we track both of them. And the results that you see actually show the combined. Both of these, the amount of e-mails received in both these areas. In other words, a specific e-mail address that was available through the WHOIS record as well as a generic, a collector that collected all e-mail addresses sent to that domain name. So in the first case where we had both protected WHOIS and delegated WHOIS, what we found was -- what you see here is the total amount of Spam that was received across a 90-day period without a single exception was under ten pieces of e-mail that came through. The second case, we looked at where we used protected WHOIS, but not delegated WHOIS. So these were registries and registrars that employed measures such as captures and rate limiting. But the actual e-mail address that was used by the registrant, the e-mail address for any of the contact details was not masked in any way, was not delegated to anybody else. In this case, you find that in the same 90-day period, and just to show you in the prior -- from the prior screen, where you had sub-ten, there was not a single case where we had less than -- more than ten e-mail -- spams coming in for the org and DE TLDs. For the same org and DE TLDs, you will find that there were responses, Spam that came through in the hundreds and, in one case, over a thousand Spam e-mails that came through. So we quickly moved on to look at what happens if you use delegated WHOIS but you don't have protected WHOIS. So these are cases where your e-mail address is in some way, shape or form delegated, but the registry that is in use, or the registrar that is used, does not offer protection in a significant way. Captures, et cetera. And we use info and com as the two TLDs to look at. And here you will find in the same 90-day period, there is more Spam than if you were in the -- you know, in case one, but you will find that Spam that came through to the mail addresses was, in general, less than 100 pieces of Spam to an individual domain name. The fourth case, which is wide open, neither protected WHOIS nor delegated WHOIS, was used for the same com and info TLDs. You'll find that the results across a 90-day period are in the thousands, if not in the tens of thousands of Spam messages that came through. So to compare the results, you'll find that for an e-mail address that is not published anywhere other than the WHOIS, when protected WHOIS is used, what we found was you can achieve two orders of magnitude reduction in the amount of Spam received. Keep in mind that all of this predicates that that e-mail address is not published anywhere else, is not used anywhere else. However, when you use delegated WHOIS you get three orders of magnitude reduction in the amount of Spam delivered. And when you combine the two of these approaches, protected WHOIS and delegated WHOIS, you get close to four orders of magnitude reduction in the am of Spam received in your inbox. In addition to this experiment that we conducted, we also conducted a second experiment which was very preliminary, and our results are inconclusive so we are not presenting the results of that data. But that was a brief study to look at to see whether the size and business model of registrars, whether it was a factor in registrants receiving Spam e-mail. And we are -- We didn't know whether that was a factor and whether it is worth considering. Now, because of the limited sample size, we are not presenting the data in our study here. And we did not find conclusive results in registrar business size or the business model to be able to report back to you. So we have a few findings for you. Number one, clearly the appearance of e-mail addresses in responses to WHOIS queries virtually assures that Spam will be delivered to these e-mail addresses. Second, for an e-mail address that is not published anywhere other than the WHOIS, when protected WHOIS or delegated WHOIS services are used, the volume of Spam delivered to the recipients of these domains is significantly reduce. When you apply both protective measures, the greatest reduction is found when both protective measures are used. Delegated WHOIS seems to be more effective than protected WHOIS if you had to choose one versus the other. And with respect to the choice of TLD, the TLD itself does not seem to matter. We studied four TLDs. Com names received more Spam than the other TLDs. Now, DE names received fewer Spam than any of the other TLDs, and we speculate this could be because the DE zone file is not easily accessible. We don't have clear evidence to make that as a statement. So we have a few recommendations for the community. First, we recommend that registries and registrars implement anti-abuse measures to protect WHOIS data from automated collection. Second, we recommend that registrants consider using services that protect e-mail addresses that are recorded in the registration records. In particular, we call attention to the effectiveness of anti-spam measures provided with delegated WHOIS services for e-mail addresses, that is not published anywhere else. So if you were to register a domain name and you were going to use an e-mail address that you did not plan to use anywhere else, our recommendation is that delegated WHOIS services seems to be quite an effective way to stop getting extra Spam. The appearance of e-mail addresses in responses to WHOIS queries, just the appearance of e-mail addresses, will very likely cause Spam to be delivered to these e-mail addresses. The combination of protected and delegated WHOIS services is the most effective way to prevent the WHOIS service being used as a source of e-mail addresses for spammers. And we recommend further studies be conducted to investigate whether spammers are more likely to target one TLD versus another. Whether large registrars are a better target than small registrars for collection of e-mail addresses. And also, whether there is any impact at all on the business model of the registrar, whether they have a resale or retail model, whether it matters. So that is the -- Those are the -- That's the extent of our study and our recommendations. I'll bring the recommendations back on screen and open up for Q&A before we go on to the next presentation. >>ROBERT GUERRA: Thank you for the great presentation I think in the ALAC and some of the other committees where users are represented, this has always been kind of talked about and it's nice to see kind of this -- the initial work being done to try to codify it. I think I have a question in regards to the report that was done. In terms of going forward, knowing the different registrars, some of them charge and some of them don't charge to protect e-mail, so I think going forward, it would be maybe interesting to see which registrars charge for protection or not. And also if it works across -- as you go forward. -- sorry about that. (Feedback noise) >>ROBERT GUERRA: Thank you for the great report. First if the slides are available I would like to share them with my at-large colleagues tomorrow. Second, as you go forward if I might suggest creating a list of registrars from a public interest perspective which ones charge and which ones don't. If Spam is such an issue, protection should not cost the registrants. So I think going forward, that, from a consumer protection point of view, that would be a good one to address going forward. Thank you, and I look forward to your next steps. >>RAM MOHAN: Thank you. >>PETER KOCH: Hi there. Peter Koch, working for but not representing DENIC. I appreciate that you included the DE top-level domain in your research, and of course I am kind of glad that the figures for DE were kind of promising. Still, I'm kind of concerned not to see zeros in all these lines. So my question is -- and it is correct, we don't provide the zone file to the public and not even under NDA so no one can actually get their hands on this data. My question is how randomly were these domain names chosen, or did you do anything else with these domain names, like feeding them into Google? I really wonder how anyone could really randomly generate -- access really randomly generated names without any additional hint. Could you expand on that? >>RAM MOHAN: Sure. We did two things. In one case what we did was pick a -- picked a newspaper and selected a set of names that just came in an order that were available in the different TLDs. That was a set of names. There were another set of names where we registered names that were -- where it was words and we introduced letters and other characters in the middle. So for example, take the word sample and put 1, 2, 3, 4, 5 interspersed so it was harder to find it from a dictionary. So those were the two sets of names or categories we selected. >>PETER KOCH: So you didn't do like MD5 or SHA1 or something random 20 byte string. It was something that I could -- with a sophisticated dictionary attack it would be possible to get to that domain name; correct? >>RAM MOHAN: In some cases it would; in some cases, it wouldn't. What we did, there was no domain name that were less than ten characters long, and some of the names you would be able to get by directory attack. But there was some other names that truly were long enough and had a pretty random selection of numbers in the middle of an actual set of words. And even the words didn't exactly make sense. They were letters just put together rather than a real word. >>PETER KOCH: Okay. Thanks. >>OSCAR ROBLES: Thank you, Ram. I'm Oscar Robles from dot MX, the ccTLD for Mexico. We have had this system in the WHOIS in Mexico since five years ago where we don't publish e-mail addresses. We just put names without any other personal information or private information, anything else. And we ask -- we say to people that consult this information that if they require more details, they should ask -- acquire this information by e-mail. The thing is that this is actually a very low profile activity, because no one really asks for that information. Because that means that represents to create an e-mail, to do a reason -- I mean to write a reason why do they need this information. And this is very low profile. Nobody asks that information. We conclude unofficially that nobody cares about WHOIS information and nobody uses it. So my question is, have you at the SSAC considered the need to maintain the WHOIS or is this just a political issue, a source of revenue for the registrars? >>RAM MOHAN: Just to respond specifically to the question, we did not look at the question of the reason for the existence of the WHOIS. Our work was very narrowly focused on if you publish an e-mail address in the WHOIS that in -- if you look at the registries that are under contract with ICANN, they're required to publish information in the WHOIS record, including e-mail addresses. So our question is pretty narrowly focused. If an e-mail address appears in the WHOIS record, in the registration record that is accessible via WHOIS and that e-mail address is not used anywhere else, is not published anywhere else, is not used anywhere else, will that e-mail address get Spam. And -- Because -- And what really sparked us to ask, your question, what was the motivation, there was a -- and perhaps you can speak a little to the details, but there was an FTC report that was published in 2002. They did -- the U.S. Federal Trade Commission did a study and one of the statements that was made is for the duration of their study, where they were studying Spam coming in, they found that -- I don't want to misquote, but to paraphrase very roughly, they found that publication of e-mail in a WHOIS did not result in Spam. So we were trying to find out, let us to done experiment, let us see whether, if you had an e-mail address that is accessible for registration record, accessible via WHOIS, will those e-mail addresses get Spam. >>OSCAR ROBLES: So would be this question a relevance for the -- to the SSAC to consider, whether or not to get rid of the WHOIS? >>STEPHEN CROCKER: Yeah -- no. It's outside of the scope of SSAC to speak, I think, to whether WHOIS should or should not exist. But I think the proper role for us is to talk about the consequences or provide the technical foundation for that. But other than that, it's basically a policy and a trade-off issue for which we really want an informed discussion, but it's not our discussion. Did I do that right? (Laughter). >>PAUL TWOMEY: Paul Twomey, CEO and president of ICANN. RAM, I found that a really interesting study. I was interested in following it very carefully. I'm going to hold this up. It seems to be a rock star thing. You need to eat the microphone and hold it up high. I am going to come off that last question and the response of Steve because I am actually confused by the recommendations and perhaps Steve is the right person to answer this. I'm not quite certain who you are recommending this to and in what context. But I assume you are not representing that the registrars breach their contracts. >>RAM MOHAN: Definitely not. >>PAUL TWOMEY: Which I could read item number 2 as saying they will breach their contracts. The contract requires presently that they do put e-mails in the WHOIS. >>RAM MOHAN: Yeah, and I think what we are saying here is registrant should consider using services that protect e-mail addresses. We are not saying delete e-mail addresses. >>PAUL TWOMEY:I'm sorry. I suppose I am reading 1 and 2 together. Registries and registrars should implement. >>RAM MOHAN: Anti-abuse measures for one, yes, absolutely. If you have rate limiting or other measures, those are good measures to have. If you have captures or other measures in the WHOIS for web-based access, those seem to be effective. And then 2 separately says, to registrants, if you plan to use an e-mail address when you are registering a domain name and it's an e-mail address you plan not to use anywhere else, consider using protection. And protection currently, if you look at -- there are services available right now from ICANN and registrars which offer protections. >>PAUL TWOMEY: Which are controversial. I suppose my basic question is this. It comes down, perhaps, to what Steve just said before. I'm interested to know to whom this report is focused and is it intended as an informing report to the WHOIS discussion that's taking place in the GNSO. Which could actually be very valuable. And I'm not questioning the results. I'm just questioning what the recommendations are intended towards, and clarifying that. >>STEPHEN CROCKER: So the point here is that we had been seeing some statements that said, in effect, appearance of e-mail addresses in the WHOIS directories was not a source of Spam. And that seemed, to us, probably incorrect. But needed a certain amount of work to pin that down. Now, who cares about that would be exactly the people that you have said, in the GNSO and other forums. So -- I don't know if it's phrased exactly right but basically we are saying here is what we found and as a consequence, if you care about not getting Spam, then -- and now the question is who cares about that. So if you are offering services for sale, registries and registrars, then you can offer these kind of protections. And if you are a registrant, then you may want to take some effort to protect yourself. And that's the essence, nothing much deeper than that. Simply trying to clean up some of the dialogue that's taking place and lay it to rest. >>PAUL TWOMEY: Well, I think that's very valuable, and I think it's a valuable input to the GNSO process as well. I would just -- I hesitate to suggest anything in terms of advice to the SSAC, but I would just suggest that potentially item number 1 might just be rewritten a little bit so you don't get the same confusion that I had from people who have real skin in the game about an argument of completely open, completely accurate WHOIS databases, and you know who those people are and they are pushing very hard at the moment, and there might be a tendency to misinterpret how item number 1 is written. >>STEPHEN CROCKER: How would you like to write it? We take advice as well as give advice. >>PAUL TWOMEY: I mean, you might just simply say SSAC notes that taking these measures tend to protect from automatic collection for Spam, or something. It's the use of the word "recommend" that I'm just -- >>STEPHEN CROCKER: Yeah. >>PAUL TWOMEY: You see what I am saying? I don't want to make a big deal of and I don't want to diminish the work you have done. I just want to ensure it's not mischaracterized. >>STEPHEN CROCKER: It's a fair point. It's a kind of template that we have and that may lead to having phrased it this way where we have findings and we have recommendations and when we write recommendations, we right "recommend, recommend, recommend." in fact, there is a little more wordsmithing to go here. So the file is still open, so this is timely. Thanks. >>RAM MOHAN: The final report is yet to be published and they will certainly take that into consideration. >>PAUL TWOMEY:Please don't interpret anything I said as a lack of appreciation for the work because I think it's very good. >> Richard Cox: If I could interject on behalf of the Spam house project that we have been doing some research on this topic, and that probably won't surprise you, something that's very close to our hearts. First of all, WHOIS matters. It matters to us, matters to law enforcement, whether they are civil or criminal law enforcement. Even if the WHOIS data is fake, it matters. It makes a big difference to our ability to track and match. The second thing I would say is CAPTCHA is not unbreakable. And more to the point, if a bad guy wants to get CAPTCHA broken, what he actually does is feed the image to a third party who wants some free service. They type in the letters, that gets passed back and yes, that breaks it quite effectively. The only recommendation we make on WHOIS addresses and e-mail addresses in WHOIS, is that a system that defeats the long-term use of these addresses by expiring the coded version -- in other words, you would code -- encode it in some way with some other data, which that data expires -- means that however they collect it, they cannot use it for more than say a week or two. That for the purpose of WHOIS is quite sufficient. Therefore, by doing that is correct you do actually take away the other incentive, the value to the person of collecting that data. He has got to put some effort to get around whatever measures are put in place. If you then make sure that whatever data he does collect expires and is of no use to him or anybody else after, say, a week or so, then they will go away. They have nothing to gain. >>DAVE PISCITELLO: Why wouldn't they repeat the process of collecting? They repeat the process of collecting so frequently, it just seems that you are just changing where they put their effort. >>RICHARD COX: They would have to put in too much effort to make it worth a candle. It really is a lot for them to do. What these guys do at the moment is they benefit from collecting the data, putting it on CDs or whatever and selling them, selling them over a long period, say six months to a year. If they expired in a week and are of no use to anybody, that part of the sales chain is destroyed. >>DAVE PISCITELLO: So you are talking about the people who actually do the list merchant as a business. I hate to use the word. >>RICHARD COX: Yeah, I do too, but yes. If you destroy the ability for them to derive revenue from it, you will destroy their interest in doing it. That's been our experience and recommend that approach. >>DAVE PISCITELLO: Thank you. >>PATRICK CAIN: Pat Cain from the APWG. I am a member and observer of the ICANN WHOIS privacy working group where this topic comes up at least once every hour, maybe every half hour, on the con calls. We in the anti-fraud world do correlation to get rid of stuff before it impacts the victims, and every time I see somebody say, oh, just hide more WHOIS data without giving the law enforcement guys or the crime fighters the ability to get some of that data scares me. If you protect everybody in the WHOIS system, it's going to be really hard to shut down people that steal your credit card data. And so I'm worried a little bit about the "recommends" in various places because I'm not so sure that is probably the intent. There are ways of cutting down Spam without kind of hiding everybody. From a technical piece, I'm curious, did you just -- for a control set, did you actually just make a mailbox someplace and not publish it anywhere and see how much Spam it gets? I actually have some domains where I have just made some mail addresses, haven't used them anywhere. They get Spam. >>RAM MOHAN: That's what we did. >>DAVE PISCITELLO: That's what we were trying to point out. >>RAM MOHAN: But you put them into WHOIS. I don't publish them anywhere. >>DAVE PISCITELLO: Well, yes, there is that vector as well, and that could account for the scatter in DE as an example. We were not trying -- we're not trying to say that WHOIS is definitively going to result in Spam. We are trying to demonstrate -- debunk a claim that said otherwise. One claim said there's no way that publication of e-mail addresses in the WHOIS is going to result in that e-mail address being the recipient of Spam. And RAM and I were sitting in a meeting where this claim was made and we looked at each other sort of dumbfoundedly and said, " this is just not correct. We have to correct that myth. ." >>RAM MOHAN: Thank you. Move on to the final presentation here, which is on IDNs. Can you tell me where that presentation is? Thanks. This is the quickest part of the meeting here, which is the quick report, status report on what we're doing with IDNs. The SSAC IDN study, it's a group that we formed in the January time frame of this year. And the fundamental goal of this study is to determine the impact of the introduction of IDNs at the top level -- abbreviate them to IDN TLDs -- on the security and stability of the domain name system. In a more specific way, what this study is attempting to answer is a question that has been asked of various SSAC members. What impact does the introduction of IDNs at the top level have on the technical, policy, operational security and stability of the Domain Name System? Now, we don't presuppose an answer. We've heard different folks provide different answers, some saying, you know, some of these answers are self-evident and others saying far more study is required. Our approach is to study the growth, scaling and systemwide issues that may cause hiccups when IDNs are introduced at the top level of the Domain Name System. Now, it's -- our position is not to actually make policy, but really to provide useful insights on what decisions, such as introduction of IDNs at the top level, what impact might that have on security and stability of the DNS. The committee members are listed here. It's a pretty distinguished group. Most of these tend to be technical folks. They are independent in their perspective. They bring a great deal of experience from both the naming area as well as the addressing area of the Domain Name System. Because we're not sure that restricting our focus to only the naming side might be sufficient here. So we have folk from both sides. And we have able support provided by ICANN. Now, key actions that we're looking to do are to identify, if any, potential security and stability issues. Look at the completeness of this identification effort. If we identify the issues, how complete is it? Are we all the way there or most of the way there or only partly there? And then as we are looking at various issues that come up, if candidate solutions are found along the way, to actually work on them and to present those candidate solutions back into the community. And the other area that we're looking specifically to work on is to provide a range of available spaces where policy-making can be done without any concerns about a technical limitation or a security and stability limitation. So one of the things that we are attempting to do is to define clearly what are the technical no-go, don't go there, areas. And to explain quite clearly what security concerns might exist, security and stability concerns might exist. And then if we know the answers or if we can deduce or infer the answers, to suggest actions to take. We don't actually expect to provide all the answers in this area. But in general, our attempt and our plan here is to complete the study and to be able to provide an answer to the question of if IDNs are introduced at the top level, what security and stability problems might exist? So that's really what we are looking to do. We intend to wrap up our work by the end of this year. And the committee has met a number of times. Most of our interactions are either via e-mail or phone. And we may have, from time to time, informal interactions in hallways at ICANN and IETF meetings. But that's the extent of what we're doing. Any questions? Don't see any? So with that, I'll turn it back to Steve. >>STEPHEN CROCKER: We've accomplished something unusual. I don't know if it's completely unprecedented, but I think we've completed what we came here to do within the time that was allotted, actually. There is a little bit of time if anybody wants to raise broader issues or questions about SSAC at all. Otherwise, I will be glad to bring this to a close and we can enjoy libations and the great weather in Puerto Rico here. Great! Thank you all for coming. Look forward to seeing you next time. [ Applause ]