Security and Stability Advisory Committee open meeting

 Monday, 2 March 2009

 ICANN Meeting

 Mexico City, Mexico

 

 >>STEVE CROCKER:   Good morning, everybody.

 I'll give just a minute or two for people to (Spanish on scribe line)
process.

 Welcome, everybody.  This is the SSAC public session where the
Security and Stability Advisory Committee presents the work that it has
done over the past few months.

 We are -- I am, frankly, pleasantly surprised that we have as many
people in the room as we do, having (No audio).

 -- would normally have a second screen showing the transcript of the
speakers' remarks.  But we're going through some growing pains in
understanding how to use the new system of meeting planning that we're
using.

 So we'll straighten that out, I think, next time.

 So with that, let me go forward.

 I'm Steve Crocker.  I chair the Security and Stability Advisory
Committee.

 We will have presentations this morning first by myself, Dave
Piscitello, Ram Mohan on my right, and I'll also mention Jim Galvin has
had a very substantial hand in putting the pieces of this together.

 Let me look around the room for a minute and see.

 There are a handful of SSAC members.

 Let me see who is here.  I see Jeremy Hitchcock over here, and
Patrick Vande Walle, and, let's see, Greg Rattray, and we have Barbara
Roseman from the ICANN staff.

 And who have I left off?

 Okay.

 So I'll be very brief in my usual introductory remarks.

 We're an external group of experts chartered by the ICANN board.  We
give independent advice to the board, to the staff, to the other parts
of ICANN, the supporting organizations and advisory committees, and to
the community at large.

 We are, as our title says, an advisory committee.  We don't have any
authority.  We don't make any rules.  And that's a good thing in the
sense that it's important to have checks and balances in any system,
and the strength of what we do is dependent upon whether other people
choose to pay attention to it.

 I'll also note that there's an external review of our committee in
progress.  That is part of the standard cycle of reviews that are
mandated by the ICANN bylaws.

 Every component of ICANN is subjected to this process.  We are in the
middle of the pack, if there's a whole long list of the reviews, some
of which have -- are, essentially, complete, and others which have not
yet been formulated.

 The external reviewers have written their report, done their external
review, written their report, and will be presenting it Thursday
morning.  And I invite everyone who is interested to come and listen to
them.

 And then begins, I believe, a couple-of-month period of public
comments and reactions.

 There is a board working group that then digests all of this and then
makes recommendations about what to do.  I think that's the broad-brush
picture of the way that process works.

 Dennis Jennings is shaking his head yes that I've got that right. 
And I appreciate that.

 In the period since the last meeting, we have written 2.9 reports,
released SAC 38 on registrar abuse contacts, and SAC 36 on comments on
the draft ICANN strategic plan.

 We are on the cusp of releasing a report on WHOIS usage and display,
and we will say something about it, but we are still hammering out some
fine points about what posture we're taking on some issues.  And
there's some diversity of opinion within the committee that we want to
try to get nailed down properly.

 So here's -- we're now through the introduction, and I will move into
short reports.

 Well, almost.

 I mentioned the external review of SSAC on Thursday.  It's Thursday
morning at this very hour in, I guess, the adjacent room, must be over
by one, Don Diego 2.  And on Wednesday, there will be an extended
session.  I don't know if we'll run the full three and a half hours,
but we have a double session reserved from 9:00 to 12:30 on DNSsec and
a considerable amount of interesting and important stuff to cover. 
It's been a very active period.

 So let me cover a series of short items here on things that are in
progress or bear only a few minutes.

 We've been doing a study, and we are not yet done with it, on
protecting high-value domains.  The stimulus for this study was
multiple incidents involving weaknesses at registrars, that is, there
were hijackings or comparable kinds of problems with visible well-known
names that were either -- where the problems were not solely due to the
way that the registrant, that is, the domain holder, conducted
themselves, but were either wholly or substantially complicated by the
processes and procedures at the registrars.

 And so that -- it isn't just a question of pointing fingers in
particular instances, but of looking at this as a system experience and
saying, "Is there a pattern here and are there opportunities to provide
stronger degrees of protection, particularly for -- where it would be --
where the loss is large or the value is high and where those
registrants might seek a different level of protection in dealing with
registrars?"

 This is a work in progress.  We would have liked to have gotten it
done, and we expect to have it out shortly.

 An entirely different activity is looking at what the potential
issues are as the root becomes larger, partly due to the introduction
of new concepts like IDNs, IPv6, and DNSsec, and substantially with, if
it grows large, and particularly if it grows very large, due to the
introduction of new top-level domains.

 This is work that we had begun to start and then was overtaken by a
normal request from the ICANN board to both the root system -- root
server system advisory committee and our committee to -- and in
combination with ICANN staff -- to study the effects of growing the root.

 This will be a much more formal study where we will have external
support.  It's in the process of being organized.  We have now
formulated a steering committee composed of representatives from each
of these three groups.  And this work is just starting up.  And I am
reluctant --  What's in the minutes of the board asks for a response by
the middle of May.  I fired back a very quick response saying, "We hear
you, but we'll have to see where we are before we can commit to
anything."

 So everything is still in the state of being organized.

 Greg, do you want to say anything about that?

 And I don't think -- there's Suzanne.  Hi, Suzanne.

 >>SUZANNE WOOLF:   My apologies.

 >>STEVE CROCKER:   You sneaked in.

 Suzanne Woolf, who is a longtime member of SSAC, but also a key
member of RSSAC, liaison to the board from RSSAC, and on the steering
committee from RSSAC.

 So do you want to say anything in addition to what I just said about
this?

 >>SUZANNE WOOLF:   There's not actually a lot to add to what Steve
said except that I think combining the resources of SSAC and RSSAC and
having strong staff support also is going to make this really able to
do what the board is going to need to do.  It does require a serious
resource commitment, and I think we're getting that.

 >>STEVE CROCKER:   A couple months ago, a few months ago, the board
released a draft of its strategic plan for the -- for all of ICANN
going forward for the next two years as part of its regular cycle.

 We reviewed the strategic plan, particularly from our perspective of
being concerned about security and stability issues, and commented in
some detail on various aspects of the plan and published that as a
separate report as well as sending it, of course, to the board.

 The main points that we covered are that new gTLDs are coming, and we
need to study the impact of scaling and complexity.

 As I said, that's now been taken over by a formal request from the
board to study this in depth.

 We looked at the wording in the plan about enhanced -- where the plan
says ICANN will enhance security, stability, and resiliency of the
Internet's unique identifiers, and raised concerns about mission creep
and appearance as to whether or not this is a new mission.

 There was commentary in the plan, or part of the plan, about the
depletion of the IPv4 pool and adoption of IPv6.  And we commented that
although this is an important area, ICANN has a useful but inherently
limited role in this.  So there's a question of what is actually
intended in the plan versus kind of signing on to, yes, this is
important, and therefore we have to speak to it kind of activity.

 There's a section in the plan about improving confidence in gTLD
marketplace.  And the focus of that section of the plan was primarily
focused on couldn't nudity of operation, what would happen if a
registry or a registrar failed entirely.

 That's, of course, of great importance, but it's not the totality, in
our estimation, of what it takes to improve confidence in the
marketplace.  Protecting registrations is also very important.

 In striving for excellence in core operations, another component of
the plan, we suggested documenting the root update process, including
metrics.  That may or may not, depending upon how things work out, get
folded into the root scaling plan as things are evolving.

 And under "Strengthening Processes for Developing Policy" we observed
that the policy process is sometimes disconnected from the technical
advisory processes, not only ours, but others, and that those policy
processes sometimes underplay things by not understanding what are
possible and sometimes reach too far by trying to do things that are
beyond what is technically feasible.

 So those were our comments on the strategic plan.

 In a different area, there's been quite a lot of work on Fast-Flux
activities.  Dave Piscitello has been spending quite a lot of time,
particularly in collaboration with both the GNSO Fast-Flux Working
Group, and with outside groups, the Antiphishing Working Group, an
operational intelligence group, ISOI, the RISG is what, registry --
Registry Internet Safety Group, which is sort of a consortium of
registries and registrars and so forth.

 And all of this is aimed at understanding how Fast Flux is used for
malicious intent purpose, and also, most importantly, how to
distinguish it from the activities that are -- might appear to be
similar but are, in fact, intended to improve resiliency or capacity in
very high-capacity systems.

 So there's, say, a lot of activity underway there.  Not much for us
to say about that here in this forum.

 Dave, do you want to say anything more about that?

 >>DAVE PISCITELLO:   No.  That's fine.

 >>STEVE CROCKER:   Okay.

 Okay, that is the end of my short reports.

 And I will move to --

 Okay.  Some time ago, we issued a statement about the deployment of
DNSsec.  And then I want to back up for just a second and say a
slightly broader thing.

 When SSAC was formed, now seven years ago, we looked around at what
are the kinds of things that we should focus attention on.  And we
began over our initial period spending quite a lot of time on the
deployment of DNS security.

 After a bit, it became clear that that was a process that was much
larger and more complicated than we could handle within the normal
meeting cycles and energy levels that we had within SSAC.  And a
separate stream of activity was started up on multiple fronts and has
operated in the ICANN arena under our aegis, but has had kind of a
separate life.  And as I mentioned at the beginning, there will be a
lengthy session on Wednesday on DNSsec.

 So there's been this kind of duality of DNSsec having a life of its
own and yet existing within the SSAC framework, at least within the
ICANN arena.

 So several months ago, we wanted to sort of make clear what that
coupling was and issue a statement from SSAC covering where we thought
the overall status of the deployment of DNSsec was.

 And we identified seven different areas to comment on.  We said some
things at the time and said we would say more.

 And so here is the list of the seven areas.  And I will walk through
each of these very briefly with what's in the report that we just issued.

 With respect to protocol completeness, there are, indeed, multiple
interoperable implementations of DNS -- of the DNSsec standards.  There
are several documents that -- related to the standards.  The base
documents, RFCs 4033, 34, and 35, and then additional documents on key
rollover and hashed authentication for denial of existence.  That's the
NSEC3 and there is a fair amount of actual operation listed there are
the top-level domains that have implemented DNSsec and are operational:
Bulgaria, Czech Republic, Sweden, Brazil, Puerto Rico, dot Museum.  Dot
org is coming, not quite here.  Dot gov just signed.  And there is more
coming along.  So that's all quite good news.

 There is still some ongoing work.

 How to integrate DNSsec responses into the end systems by expanding
the set of error return values, formal DNSsec validator API.  Trust
anchor repository is still quite an open area.  How to transfer from
one registrar to another, this is one of the issues that was called out
in the RSTEP report issued when PIR asked permission to implement
DNSsec for dot org.

 And some very long-term issues about migrating the larger key sizes
to new algorithms, which are probably not immediate issues, but are
being worked on.

 The second and third topics, key rollover and trust anchor
repositories, I'll take care of here together.  And therefore a handful
of different ways to deal with trust anchor rollovers.  The report
examines these issues in -- there is a report that examines these in
some detail.

 There's further work needed, and still symptom distance before we
have consensus within the community about how to proceed overall.

 This is not a show-stopper in terms of individual zones being signed
or individual resolvers being in operation.

 With respect to implementation and deployment testing, following some
surprises that were encountered when Sweden first deployed DNSsec,
there's been a considerable amount of work on testing broadband
firewalls and routers, particularly in the small office, home office
environment.  A funded study done jointly with Nominet that we
sponsored looked at a set of 24 different boxes and tested in various
ways.

 The results were, let's say, attention-getting in the sense that
there were very few boxes that passed cleanly.

 The boxes that tried to do more work, that acted as proxies
themselves instead of passing DNSsec queries or DNS queries asking for
signed responses upstream tended to fare worse because they tried hard,
but they didn't get it right.

 There is a considerable amount more testing going on.  Comcast had a
vendor summit about a month ago and said, look, guys, here's what we're
seeing.  And it would be good for you to upgrade your firmware, upgrade
your products, and not have them become part of the problem.

 More on that is going to emerge for sure.

 On performance and error analysis -- and I want a strong caveat here
that these numbers are mine and aren't necessarily 100% common across
everybody's experience.  But I've chosen numbers here which are
relatively conservative, that is, this is not putting a positive spin
on the numbers.  These are kind of close to worst case.

 That on name servers, there is a very measurable increase in the
memory footprint of the size of the zone.  There's a -- there's also a
measurable increase in the size of the packets that are returned. 
There is no perceptible -- well, you can measure it, but it's down in
the few percent -- increase in the amount of computation time on the
name server.

 So that's on the name server side.

 On the resolving side, we don't yet have enough experience to have a
crisp set of numbers.  There's a handful of numbers all over the place.

 However, the initial experience does not suggest that there's any
large issue.

 Now, validating resolvers are doing DNS lookups and checking the
answers full time.

 End systems that are doing DNSsec checking spend a very small
fraction of their time on DNS, because they're doing other things.  So
if you're looking at a Web page, downloading a Web page, doing the
display of it and so forth, and in the -- as part of all that, doing
DNS queries, whatever the amount of time being spent on DNS, it's still
a very, very small fraction of the total time that the end system is
spending.

 So if there are going to be performance issues, they will be in the
two areas that are shown on the screen.

 Excuse me.

 With respect to end system application support, there's not yet a
tremendous amount of information.  There are libraries and add-ins
available on a wide variety of systems, and more coming.

 And Microsoft has announced formally support for DNSsec in its
servers and has not yet announced formal support in its client systems,
but it's clear that they will have to move down that direction.  And I
believe they are.

 And there is comparable end-system developments, but coming along at
a slower pace.

 There's --  This is awfully hard to read this slide from this
distance, I can tell.

 There's a couple of different deployment scenarios.  I think I'll
just, both in the interest of time and because it's very hard to read,
I'll just give a very quick summary.

 The question is, where does the validation take place in the -- let's
see.  Can I -- do I have a -- oh, I do.

 Can you see that hand moving around there up at "validating" here? 
Barely.

 So here's the end system.  Here's where the data is coming from, and
here's the path along the way back.  And here's the validating --
recursive resolver in the middle.

 This is maybe the most common case, where the checking will take
place.  And then you have, presumably, a trusted path between the end
system and the recursive resolver.

 In another case, the end point does validating either in between here
or way at its end.

 We are -- we're still accumulating experience.  I would say the vast
majority of validations are going to take place in this sort of main
recursive resolver that operates either at an ISP or at the edge of an
enterprise on behalf of the clients inside an enterprise.

 What's the availability of DNSsec name server platforms?  We did a
survey -- this is really your work, Dave, I believe -- with quite a few
products.  

 And the basic results that there is a substantial set of products
available, and more coming.  I think that this puts us in the range
that this is not an issue; that there's plenty of choices and that they
are maturing very rapidly.

 So that takes me through the survey of the seven areas that we
promised to look at.

 In summary, would I say the main open issues are the trust anchor
distribution and use, that the broadband firewalls and routers still
have some distance to go, and of course integrating DNSsec with
recursive resolvers is an area. 

 We're curating deployment experience.  Registrars and recursive
resolvers I think are where the frontier area is at the moment.

 We are working with a couple of registrars to get them ready to go
for general registration processes and work as general examples on how
this will be done.  And so that's evolving over time.

 And this set of -- everything I have just said here is also scheduled
as part of the Wednesday morning session.  So for the people who are
here and also going to DNSsec session, I apologize that you will be
burdened with this twice.

 That's the end of this presentation.

 Any questions or comments that people want to raise?

 Great.

 So the next is the WHOIS -- Oh, you are going to take this?

 >>DAVE PISCITELLO:   Yes.

 >>STEVE CROCKER:   Okay.

 Oh, a question.

 >>JIM GALVIN:  Okay.  So the question from the room, if I get this
right, please, is this is a question about the registrar stuff.  What
are the technical requirements for registrar implementations?  Are
there any documents on this?

 >>STEVE CROCKER:   That's a good question.  There should be more
documents than there are.

 There is a specification for passing DNSsec records via EPP, I
believe.  And there is probably not enough of the right kind of
documentation elsewhere.  And I will take that question as a strong
hint that we better have a better answer next time.

 Is that it, Jim?

 >>JIM GALVIN:  Yeah, the only additional closing comment is basically
an idiot's guide would be ideal.

 >>STEVE CROCKER:   Idiot's guides are always ideal.  So we need
DNSSec for Registrars and Dummies.

 Dave, your turn.

 >>DAVE PISCITELLO:   Good morning.  I am going to talk today about a
report that SSAC released over the weekend on registrar abuse contacts.
And as an introduction to the issue, -- and again, apologies for the
dimness of the screen and for the poor resolution -- in a typical
phishing domain takedown or other illegal or abusive domain takedown,
there are basically three chunks of a time line.  The first chunk
involves really the precursor to the attack by the phisher where the
phisher registers a domain, creates a phish site, sends a phish e-mail,
and now he has got the lures to the illegal Web site that he has hosted
out in the wild.  People are receiving it.  And at that particular
point, in many cases, from the first delivery of phish e-mails, we have
anti-phishing service providers, other interveners, brand owners,
detecting the phish URL, identifying it, and beginning the process of
trying to suspend the site and take down the domain.

 At this point, we are in the second phase, which is hours one through
12.  Consumers are receiving e-mail.  They are unwittingly being duped
into visiting sites, and the process of scam and fraud impersonation
and other abuses begins.

 The clock is ticking, and people are losing money, or are being
harmed in other ways.

 At this point, the anti-phishing service providers or interveners are
attempting to contact ISPs, registrars, and site owners to try to take
out the site.

 And the question that we're trying to address today is how do
interveners know whom to contact in this process at this particular time.

 The important party here with respect to the domain name is the
sponsoring registrar.  Interveners and law enforcement agents and
others can identify the sponsoring registrar through information they
can get through WHOIS.

 One of the issues that arises is that now that I know who the
sponsoring registrar is, where do I find contact information for the
sponsoring registrar, and is the contact information that I can find
one that will lead me to someone who can handle abuse claims or
criminal complaints.

 How you find registrar contact information depends on your expertise
and your flexibility or agility in dealing with these matters.

 You can visit the registrar's Web site and in some cases you can find
information there.  You can visit ICANN's published list of registrar
contacts at the URL cited here.  Often you will ask a colleague, you
will ask a mailing list, you will ask anyone who you believe might
know.  You will ask an ICANN employee.

 The issue here is very simple.  Each failure to locate a registrar
abuse point of contact extends the duration of the attack.

 If you do get contact information, it is not necessarily the case
that you are done doing your search.

 Registrars publish contact information from many points of contact. 
They publish it voluntarily.  Certainly published points of contact are
not going to be the kind of people who handle an abuse claim or a
criminal complaint.  Some contact information isn't available, and some
points of contact aren't available 24 by 7 to handle an abuse, and
criminals don't necessarily take the afternoon off.

 In many cases, the party that you can reach with an abuse point of
contact that is published at a registrar site or available at ICANN's
list is a general contact point.  And they may not be able to process
an abuse claim or to escalate the complaint to a party who can.

 So the issue that I mentioned earlier is revisited.

 Each successive failure to locate a registrar abuse point of contact
extends the duration of the attack.

 The question that SSAC asks in SAC038 which was published I believe
Friday, is that the ideal response time for phishing attacks are
measured in hours.  Delays introduced while attempting to contact a
registrar, and even once contacting the registrar, finding the right
point of contact in the registrar to handle an abuse complaint, are
measured in hours.

 So how can we reduce the delay?

 The document is relatively short and our recommendations are
relatively focused.

 We do believe that every registrar should provide an abuse point of
contact.  Not just an e-mail, not just a phone, but a party that can be
effective and responsive in dealing with the complaint.

 The contact party also should provide complainants with some well-
defined and audible way to track the abuse complaint.  So it's not a
case of sending in an e-mail and having no feedback after you have sent
an e-mail about abuse to go by, but to have some kind of ticket or some
other method to be able to track the progress of responding to that
complaint.

 The information about the abuse contact should be published by
registrars.  We think it should be listed prominently on the
registrar's Web site, and it should be listed prominently on the ICANN
Web site as a specific abuse contact.

 We also believe the abuse contact information should be consistent
with other registration contact records, the same richness of
information in interprets of e-mail, not simply a postal address but a
real honest-to-goodness street address, telephone numbers where people
will answer phones and the like.

 It will be very valuable for people who have to deal with some
automation to make the contact information available in a machine
readable format.

 And we believe that it's important that this information be kept
accurate, and so we think it's important for ICANN to periodically
check for accuracy no less than annually.

 And that's pretty much the sum and total of that report.

 So if there are any questions, I'll take them now.

 >>THOMAS ROESSLER:  Good morning.

 So given the large number of documents published over the weekend, I
didn't find time to read this particular one, so I have to rely on the
things you said here.

 One point that's striking me is that we're putting a lot of emphasis
on the takedown point.  I don't want to debate that here, but I wonder
if it is part of a useful balance in this came to actually figure out
what the accountability mechanisms are.

 Do we actually have any kind of reporting about abuse takedowns?  Any
way to understand whether the abuse takedowns are abused any way to
detect that if it happens or when it happens?

 I think that might be a direction of thinking and work that I would
really like the folk in SSAC to spend some brain cycles on.

 >>STEVE CROCKER:   Let me make a comment and then turn it back to Dave.

 I think that's a very sensible and well thought out question.

 Within the ICANN ambit, we actually, I think, have a very, very
limited role in the overall game that's being played out in this
process, and that the operational community is the one that's
predominantly involved in takedowns.

 So that question about how effective it is and all of that is, I
think, a very apt and sensible question, but is not one that either we
have the data nor are we in a very good position to go after, because
we have a kind of supplementary role, if you will, in all of that.

 The other point that I want to offer, and then I want to ask Dave to
step in, is that -- and I'll put this in somewhat personal terms.  I am
a lot more interested in building systems that are strong in the first
place, and although it's absolutely necessary to have operational
support to react to problems, my long-term feeling is that that cannot
and should not be the totality of the view towards security.  That we
have to balance that with the much less attractive work of building our
houses strongly in the first place rather than just going out and
fighting fires all the time.

 Let me ask Dave to say something, then.

 >>DAVE PISCITELLO:   I would not portray this document as putting a
great deal of emphasis on abuse at the back end.

 I think it just happens that we have published this before, a pending
SSAC document where we are going to talk a great deal about measures
that you can improve registration services at the time of registration
to not only protect the registrars but to also reduce the number of
opportunities for malicious insertion of domains into the registries.

 So we look at the spectrum of the issues.

 I think that it's very important to realize that we hamstring
intervention when they can't contact anyone because there's no
published information, and that's an omission that we can identify and
fix, and that was the purpose of this document.

 >>PAUL STAHURA:  It's another tricky problem.  I agree that it would
be beneficial for -- for certain registrars to publish information so
you can contact them.  But I fear that the abuse contact will be abused.

 eNom works with various private e-mail lists that the bad guys can't
post to.  So let's say we published an e-mail address that said, "Hey,
if there's phishing, this is the address to contact."  The bad guys
will know that.  When they start to phish, they are going to Spam that
address or there will be other complaints going to that address that
have nothing to do with phishing, frivolous complaints.  And it gets
very difficult to discern which ones are the good ones, which ones are
the bad ones, which ones are coming from the bad guys, which ones are
coming from who knows who.

 So I think it's a great ambition to provide contact ability to the
registrars, but practically speaking, it's a tough problem to solve.

 If you can solve the abuse of the contact, I'm all in, but I think
that's going to be difficult to solve.

 There needs to be a different channel, I think.

 >>DAVE PISCITELLO:   We actually talk about this as one of the issues
that the GNSO should consider.

 We simply didn't throw this out and say, "This is the policy."  SSAC
doesn't make the policies.  We actually recommend in the report that
the GNSO consider the potential for the abuse of the abuse contact.

 I think that the concern you have has merit.  I think that there are
many ways, including making contact information available to the right
parties, as you say.  And I think that we have to pay attention to it.

 I don't think that we can run away from it by saying this is going to
be hard.

 >>PAUL STAHURA:  I agree with that.  We shouldn't run away from it. 
We should help work it out or solve it, but the fact remains, this
abuse is going to be -- this contact will be abused and it will end up
being useless.

 >>STEVE CROCKER:   Let me echo Dave's response.  I'm sitting here
thinking through what you are saying, and one or two ideas come quickly
to mind at how to deal with all of that.  And rather than get into an
extended discussion here, you and I can go off and one of us can buy
beer.

 I'm sure this is a workable problem.

 >>PAUL STAHURA:  I agree.  There is a -- I think there's a solution,
but it's just difficult.

 We have an emergency contact number.  We don't publish it.  Not to
everyone.

 It's tough, because if we publish it, you know, we're going to have a
million people calling it, 24/7.  And how do we discern which ones are
really, really emergencies and which ones are transfer requests or
problems with customer service and hosting and all the other services
we offer?

 So we give our emergency phone number out to our large resellers, to
people who we know provide good complaints, let's say.  You know anti-
phishing people.  We monitor various private e-mail lists.  Those are
the methods -- we have struggled with this problem ourselves.

 We would love to publish the information so we can get the
appropriate contacts, but it doesn't -- the appropriate contacts don't
contact.

 Other, the abusers contact.  They send out a phish, they know that's
the abuse thing, they will Spam that like crazy.  So you don't get the
anti-phish e-mail.

 >>STEVE CROCKER:   Yeah.

 This is a great discussion.  And as a measure of it, it's consumed
the time that we have.

 Let me move on to Ram Mohan on WHOIS usage and display.

 Ram, you are going to run off of my machine, I understand.

 >>RAM MOHAN:   That makes it easy.

 Good morning, and thank you for being here.  I'm here to present some
SSAC views on WHOIS usage and display.

 I realize that we're running a bit short on time.  So I'm going to
push through the first few slides relatively quickly.

 So at the very start, what is pretty clear is that registration data
is getting more internationalized.  All of you know this.

 And the advent of IDN top-level domains promises to significantly
increase both the volume and frequency of registration data being
provided in internationalized formats, using characters well beyond the
U.S. ASCII character set.

 And local language support affects not only how the data is stored
but also how it is displayed and how it -- what the user experience is
all about.  The original objectives behind the WHOIS, at least the way
we have looked at it, seem to have been that someone registers a domain
name and that registration data and the information is stored in some
central repository.

 Users ask queries on the WHOIS in U.S. ASCII, and the output that
comes out on the other side is also in a U.S. ASCII format.

 But that is evolving to -- on the next slide you will see what is
happening is evolving to a place where input can come in one of any
sets of languages, using character sets well beyond U.S. ASCII.

 And an expectation that the output is also in character sets beyond
U.S. ASCII.

 And the intent is to have all of this happen without having a Tower
of Babel to ensure that few progress and continuing progress on
technology is not halted by confusion of tongues.

 Go on to the next slide.

 Now, if you look at standards itself, the RFC 4690 that speaks about
next steps in IDN, there's a piece that is highlighted in yellow, and I
will just read it out briefly.  The WHOIS protocol itself has no
standard capability for handling non-ASCII text.  One cannot search
consistently for or report either a DNS name or contact information
that is not in ASCII characters.

 So with that as background, there are some questions to consider.

 Now, right now, if you look at how WHOIS information, registration
information and data is considered, that -- the submission and display
of contact information is a local matter for registries and registrars.
And one of the questions is, is that desirable?  Is that sufficient?

 And can current practices used by these parties be utilized and
exploited to a better extent when contact information itself is not
available in U.S. ASCII format?

 And there's also other questions.  For example, what can we actually
learn from experience to date?  As we know, WHOIS and registration data
has been available in non-U.S. ASCII modes in many other parts of the
world.  And there is real experience, and the question is, is there
something that can be learned and leveraged in the gTLD and the new IDN
TLD world that we're entering into?

 And is WHOIS accuracy itself affected?  If so, how is it affected? 
And are there any kind of general principles that registries and
registrars could adopt, any kind of best practices that they could
adopt to minimize this Babel effect on WHOIS services?

 In addition, can we actually deliver a better -- a service that
provides better responses to internationalized contact and registration
data.  We're calling this WHOIS, but just to be clear, and within the
SSAC we have had some vigorous debate about it, we're not talking
solely about the service that is currently running on port 43.  There
are -- the IETF has gone forward and put new protocols, IRIS is a well
established RFC that has been out there, yet to be adopted by
registries or registrars.

 The question to consider is, what features will Internet users find
most beneficial?

 From a user experience point of view, what kind of features would be
most beneficial, and what is actually the right user experience?

 In the past, there have been statements made that at least one
contact, one set of contact data should remain in U.S. ASCII.  Is that
appropriate?  Should it be something else different?

 We don't actually propose a particular solution on this, but we
certainly believe that this is an area that ought to be considered, a
question that answers ought to be thought about.

 And I had already mention board of director IRIS, but there are other
protocols and there's another question, which is should WHOIS itself --
should we say goodbye and start off on something that is new?

 So we have several recommendations.

 We would like to suggest that the June 2009 Sydney meeting, we would
like to host a workshop to discuss changes to domain name records usage
and display.

 And we believe that it might be particularly useful because that
setting might attract far more people who actually have this problem of
having registration contacts that are internationalized.

 And there are some potential topics for the WHOIS -- for this
workshop as an agenda, but it is certainly not limited to this.

 The second is a recommendation to the ICANN Board of Directors, which
is to direct GNSO, ccNSO, and SSAC to task a working group.  And this
working group would study the feasibility or suitability of introducing
display specifications or standards to address this issue of display of
internationalized registration data, and to formulate the proposal as
well as to work with the IETF to develop support for non-U.S. ASCII
characters for WHOIS-type data.

 I think that brings us to the -- that is the last slide.

 So that's our recommendations, really two recommendations on the
WHOIS and display area.  Open it up for questions.

 Okay, Steve.

 >>STEVE CROCKER:   Thank you very much, Ram.

 Thank you Ram, thank Dave and Jim and the entire committee for the
work that has been put into this round of reports and studies.

 I appreciate everybody coming.  I'll note for the record that a rough
count, there have been or are approximately 50 people in the room,
which is, frankly, quite surprising to me and an extremely positive
turnout from what I would have guessed.

 We were half expect to go walk into an empty room here.

 So this is great.

 So I appreciate everybody's attention and support, and encourage
vigorous participation and interaction.  And keep pressing on various
issues, whatever comes to mind.

 Is there any last-minute questions or anything that anybody wants to
bring up?

 I apologize, this time slot is shorter than we usually have, and so
we have had to make this a very compressed schedule here.

 With that, I will bring this to a close.  We have -- I think we are
in time for the opening welcome ceremony, which is -- where is it? 
Upstairs one floor.

 Thank you.  Good morning to everybody.