Comments on irtp-a-initial-report-08jan09.pdf

[Patrick Mevzek <contact@xxxxxxxxxxxx>]

Please find below some of my comments on the document
irtp-a-initial-report-08jan09.pdf
I'm writing these comments as an individual generic Internet user,
owner of some domain names for personal and business needs,
a founder of a company working with ICANN registries, registrars,
and domain names providers,
a participant in IETF Working groups related to EPP & IRIS,
and creator of software implementing both EPP and IRIS.
Of course, I'm only speaking for myself.

====================================================================

Executive summary of my comments below:

- Issue 1: IRIS is probably the best road ahead, but some work on EPP
may help too (but probably not on poll messages as offered in the
report), where a major change in policy (enforcing the authinfo as
the true only primarily token of authentication) would even have my
preference over any technical change. I give some other specific ideas below.
- Issue 2: I mostly agree with the report preliminary conclusion, but
I would favor more market free innovation to define new ways of doing
authentication, with some policy safeguards.
- Issue 3: I absolutely agree with the report preliminary conclusion.


I praise the working group for having been able, specially for issue 1, to
take into account so many different ways that may help to reach a
solution, both on technical and policies grounds. This is a very good
effort and work, that I applaud.

=======================================================================

Introduction to my comments on all 3 issues below.



Domain name transfers (like whois) have always been an outstanding
issue, between technological changes (such as the introduction of EPP
and its "authcode"), policy changes (like
http://www.icann.org/en/transfers/policy-12jul04.htm ), new attacks
and "famous" thefts (true or alleged).

Policies and processes need to find a middle ground between the ease
of transfer to make sure no arbitrary registrar locking can take
place on one side and on the other side enough guarantees that only
legitimate transfer requests happen and succeed.

Before starting to directly answer the 3 issues presented, I would
like to say that based on the only public data I know (the ICANN
registries monthly reports as PDF), there does not seem to be a lot
of problems with transfers.
I've used the monthly reports PDF to tabulate data in other ways and
create graphs, and you can see them on my website at
http://www.testing.dotandco.net/ressources/icann_registries/index.en
and for example on .COM transfers:
http://www.testing.dotandco.net/ressources/icann_registries/verisign_com_net/transfers_COM.en

If there is other data on transfers, it would be good to know them,
so that policy procedures and energies can be properly spent
depending on hard facts.

If you look at the above transfers numbers you come to the conclusion
that failed transfers are low, often around or below 5% (with .COM
being higher than that but this is pretty much to be expected, based
on the number of .COM domain names and the image of .COM, a gTLD
better known than any other one). This does not mean there are as
much problems, as transfers can fail for a myriad of valid reason
such as: error from the registrant (not transfering the correct
domain names, or not at the appropriate time), from the current sponsoring
registrar or the prospective one.
Sadely, there is no way, nor requirement, for the registry and the
current sponsoring registrar to document why they reject a transfer
(no provision for that in EPP), so there is no data that show which
cases among the list of 9 points in §3 of
http://www.icann.org/en/transfers/policy-12jul04.htm
explains why transfers have been refused.

A number that may be even more revealing, is the one about transfer
disputes, and its spread between disputes that has been solved (in
favor of one of the two registrars involved) and disputes without
decision (per the process specified at
http://www.icann.org/en/transfers/dispute-policy-12jul04.htm )
This number is very low, often less than 10 disputes per month.
This does not cover all kind of possible disputes, as disputes
handled outside of the registry operator are probably not computed
there, nor are all disputes handled by courts around the world, but I
doubt that the numbers would change a lot if they would be all
counted.

Which means to me that the current system do seem to work "good
enough". It does not mean that effort should not be spent toward
improving it even more, but the current situation should be taken
into account before providing too much new requirements in policies
or new software developements.


=====================================================================

Issue 1. Potential exchange of registrant e-mail information

I think part of the problem comes from the fact that the registrant
"contact" is handled differently than other contacts (administrative,
billing, technical), where today this difference makes no sense at
all.

If, in the past (more than 10 years ago), people were owner of domain
names without maybe even knowing anything about the internet (so not
necessarily having an email address), and
thus giving their authority to the admin  contact that acted on their
behalf, I doubt that this situation is prevalent today.
So, in all policies documents and thus technical procedures, all 4
types of contacts should be handled exactly the same way, with the
same requirements on what data needs to be provided, how it is used,
and so on. The email address should be there for all contacts, and
displayed/used the same way.
See for example the Registrar Data Escrow Requirements, where emails
of all contacts are to be dumped... except for the registrant ones !
And for whois display.
(I do observe however in some quick tests that registrant email
address is displayed in whois for AERO ORG INFO BIZ MOBI CAT TRAVEL
at least; since .COM/.NET are thin it depends on each registrar)
But whois display cross the issues of personal information in whois,
and this is another debate.

The registry implication do vary also because it depends on its
status, as thin or thick registry. Any work today on these issues
should take into account current TLDs but also forthcoming ones, and
I have personnaly no idea/information if future registries will be
thick or thin, even if all the latest additions were thick ones.


This issue 1. asks if there is a way for registrars to make
registrant emails data available to one another.
Before giving some ideas of my own, I would like to comment on points
given in the report presented (pages 15 and following).

- EPP : I do not believe the poll mechanism should be used to
transfer messages between registrars. It was not intended this way in
the protocol (and specifically, some registries in the world based on
EPP dislike the idea of poll messages, and started their business
without it ; some have added poll messages some not ; it just shows
that poll messages are an EPP feature on which there is no absolute
consensus), as it is purely a channel for the registry to
*asynchronously* inform the registrars on some information.
Allowing registrars (client side of EPP) to create messages, and even
allowing them to choose the destination (the other registrar, which
would need to be identified) of messages seem to me very unnatural in
the current EPP specifications, and an horror waiting to happen due
to security and denial of services potential problems, not even
thinking about the new specifications that would needed to be
written, in then the new software developement at both registries and
registrars ! This whould be a huge amount of work to shoehorn
something like that where there is another solution that fits more
naturally, IRIS.

- IRIS : IRIS is the successor of whois... except the only fact that
is not used anywhere today publicly (except for something closer to a
domain availability check then a whois, in .DE) .
It has however two major points that are a mess today in whois:
* a clear format (based on XML), where whois lacks any standardized 
format at all
* a core mechanism to handle authentication and authorization
policies, where there is none in whois.

If any data should be transmitted between registrars and/or
registries securely, with traceability and authentication, in my
view, IRIS would be the solution.

However, it would mean having an IRIS server working at each
registrar. This may seem unrealistic as they are already problems
with registrars whois servers, at least some of them, from time to
time. So making a new technical development mandatory to something
like 1000 registrars is not a guarantee to achieve it in a reasonable
time I'm afraid. A shortcut could be achieved in thick registries, as
only a registry IRIS server would be needed, available only to
registrars.

But I would like to pinpoint something: having the need to do some
software development should not be taken as an argument against some
solution. Innovative and new services pretty much always need new
developement to start with, and anyway, IRIS should be something
pursued in the future in other cases, like the current complete mess
with all whois issues (while at their core these issues are not
technical and hence can not be solved only with technical changes,
this does not mean that new technical solutions could not help,
together with policies and procedures, to achieve a better state).
So, if there are two solutions for a problem, and one requires new
technical development while others do not, then we may say that the
one without software development should be prefered. However if this
solution does not exist, and the only one or the best one do require
some technical development, then it should not be an argument against
it. Of course the related costs and time to market should be taken
into account, but by itself this should not eliminate the solution in
question from being studied.

No solution should be based on working on the current whois system,
and if that happens, this should be changed to work on IRIS solutions
to replace/enhance the current whois.

- Registrant vs admin approval : I believe that if both parties
should remain involved in the process, they should have the same
rights regarding initiating, confirming or declining a transfer.
If they do not have or can not have the same rights and tools to act
upon transfers (or other areas for that matter), then
only one party should remain, and the other should not intervene
anymore in the process.

However, as outlined above, since these 2 entities are not handled
the same way currently, it would be a problem to choose one over the
other.

I also fear that choosing one over the other, makes the loosing one
almost worthless, at least on the registry level (registrar are free
to use their authorization system locally in any way they see fit
based on contacts and their appropriate passwords ; along the road, I
would like to share my experience on that stating that not all EPP
registries worldwide use the same set of contacts - some do not use
the billing one, some do use other ones - and also that EPP allows on
the protocol level to have multiple contacts of the same types for a
domain name, like having 3 administrative contacts ; this last point
- even if not really seen today - may create the exact same problem
as this issue is trying to solve with more than one actor).

I would however slightly prefer, if this is the solution taken, to
favor the administrative contact over the registrant because, first
it is the current system and it solves the problem of having to get
the registrant email which would not be needed in anyway as the
registrant would not intervene at all, and second because I think we
are in either of these two cases:

* some entity, for various normal reasons, wishes to own domain
names, but let some other company (one of its affiliates, its
lawyers, its webhosting company or technical provider, etc.) manages
them ; they thus would be registrant, but the other entity would be
the admin contact (and probably also the technical/billing one is
many cases). In this situation, all operations on the domain name are
conducted by the admin contact, so the registrant should not be
participating at all, as it clearly stated (by not being the admin
contact itself) that some other entity has the right to act on its
behalf for domain name management

* or some entity wants to own domain names and manage them, maybe
while leaving only technical stuff (like DNS management) to some
outside company, which would be the technical contact only. In this
case this entity would be at the same time the registrant and admin
contact.

So if we take into account these two cases, dealing with the admin
contact only should be enough and the proper way to manage a
transfer.

As I'm sure to have forgotten some other cases, I'm not sure however
that such a clear cut would be always possible and siding with the
admin contact. If they are however no other cases, using only the
admin contact should seem reasonable.

For uniformity, I would recommend in all cases, that if the
registrant is taken out of the equation on the new registrar round of
contact emailing to get transfer authorization, then it should also
be taken out of the current sponsoring registrar round of (optional)
contact emailing, in order to avoid very difficult cases to
understand.
So basically : the new registrar emails the admin contact (after
having been given the authinfo code) and proceeds with the transfer
if it gets express positive agreement from admin contact, the
transfer is started, and if the current sponsoring registrar wishes
to double confirm, it emails only the admin contact, and stop the
transfer only with an express negative reply.
At least, this would be my advise.

- AuthInfo code : this is an interesting point related to the way EPP
was created.
EPP was created after transfers started to happen in gTLDs.
EPP was created with an idea of using authInfo to start a transfer,
in such a way as the simple possession of the authInfo token means
the acting party (the new registrar on behalf of "someone" that gave
him the authinfo, and that someone must have been authorized in some
way by the previous authinfo to get this code) has all necessary
proof it is currently making a legit transfer request, and not a
bogus one.
When EPP came in production, the current set of policies regarding
transfers were modified to take into account this new token of
authentication.
By then transfer policies already had the mechanisms with emailing
the contacts and waiting for their acknowledgment, albeit without any
clear standardization of messages or procedure flow. But EPP authInfo
was then added to the current policies, as an additionnal step,
without reframing the policies themselves.

However in my mind as a software developer regarding EPP, its
authinfo mechanism should then have been used instead of the current
system with contact emails and acknowledgments. Of course care would
need to be taken into account to ensure proper transition over to
EPP, as oldest registries were still using RRP. Introduction of
authInfo created many problems, because it was something new and not
very well understood by a large proportion of registrars (which lead
to various problems such as the same authinfo used for all domain
names, refusal to give the authinfo and thus blocking outgoing
transfers, and so on...)
But, again, as an EPP technical specifications participant and later
developer, it makes low sense to add this new requirement of authinfo
code to the older one. It should be one or the other, not both. And
since the authInfo one seem superior (for various reasons outlined
below and with issue 2), it should supersede the other one.



Now here are some ideas/comments from myself that I'm giving for
review by the working group:

- about EPP and getting/giving email addresses through poll messages.
I think there is a better solution, which the protocol allows today
and which is only a matter of policy. It will work only for thick
registries, but anyway for thin registries, a solution among
registrars will be needed (and I did not have enough time to think
about good solutions for thin registries).
So here is the idea: the EPP protocol has a domain:info operation
which reveals all data related to the domain, including the contact
IDs of the registrant.
This operation accept an authInfo code, the idea being that if the
registrar doing it is not the current sponsoring registrar of the
domain name, it may still get information on it if it has the proper
authInfo code (given to him by the admin/registrant which got it from
the current sponsoring registrar). At least this is a policy
decision, some registries allow domain:info done by all registrars
and some do not.
But doing so before a transfer, the prospective new registrar can
gain information on the registrant (and admin for that matter)
contact ID.
Now, the contact:info operation works basically the same way (and
would thus reveal the associated email address), with an optional
authInfo. But small problem here it is not the same authInfo as
previously, this later one is attached to the contact, it is like its
password (which may or may not have any relation with the password
used by clients to manage their domain names through the registrar
website). Here comes a small problem, which could be solved in
various ways:
* disclosure of the contact authInfo : this may be a problem for
contacts handling multiple domain names and if this "password" is
used in other areas.
* change of contacts : the domain currently sponsored by registrar A
could use contacts created by registrar B, 
Technical procedures have nothing against that but registries
policies may require registrars to only use their own contacts
objects.
* changing the authInfo structure for the contact : authInfo is an
extensible element, and has been extended already for domain:info
(in short, you can give the authInfo related to the domain you query
OR you give the authinfo of one of the contact of the domain you
query and the ID of this contact, which is called the roid)
I think it could be easily extended for contact:info such as you
would pass, not the contact authInfo (which would thus remain secret
to the future registrar, which is good), but the domain authInfo you
wish to transfer and for which the current contact you query is the
admin or registrant, and the ID of this contact (which is displayed
in the domain:info).
I believe this would need only a minor technical specification (as it
has been done for domain:info already), and very little changes in
current software both on registrar and registry sides.

So this is only an idea, and maybe further work on it may find it
useful or definitively useless. If needed, and useful, I'm available
to help study and work around this idea or other ones like that, if
my participation could be useful to the working group.


- getting maybe a little too far, but based on the comments I gave
previously on authInfo introduction in EPP, the transfer policy could
be simplified a lot and at the same time this issue could be resolved
if the policy is changed so that it requires *only* the authInfo code
to start the transfer, removing the contacts email handling. The
current sponsoring registrar would still be allowed to notify
contacts and would be allowed to stop the transfer if one of the
contacts say so.
The current registrar has all email adresses it needs, and can
properly identify the associated contacts and inform them.
No emails would need to be passed from registrars to registrars,
no technical changes would be required.
Things will not go slowler than today (as the domain authInfo would
still be needed, and so things can be "blocked" if the current
sponsoring registrar refuse to give it), they will maybe go a little
faster, but more important things will be simpler, without the need
of 2 specific acknowledgments needed (authInfo + contacts answer).
I do not believe that this simplification creates more risks or ways
of disputes.


Even in the very improbable case that this would become the way
forward, I would keep my recommendation above to make sure all
contacts are handled the same way everywhere.

I specifically do not understand while the report says on page 21
about using only authInfo:
"However, this was not deemed a secure and viable solution
compared to the current system."

If the authInfo is not secure, why using it at all then ? Why not
going back to the previous system, before EPP, with only contacts
authorization ?
If the authInfo is secure, why could it not be secure by itself ?
In what way do emails, through clear channels (making snooping very
easy) and from/to email
adresses publicly known in whois (making spoofing/impersonification
trivial), make it more secure ?
It is not public information (where contacts names emails and so are
in whois so open to many kind of attacks... which one specific
example even given in the report page 22 about compromised email
accounts !), and it is available only to registrars.

This also seem to be the position of the Registry Consistuency as it
can be read on page 30.

Again, see my previous discussion about authInfo introduction in EPP.




To summarize, my preferences would be, from most prefered to least:

- first to simplify the policy, to remove the new registrar
requirement to send emais to the contacts, and make the transfers
mandatory as soon as the authInfo is known, leaving the current
sponsoring registrar the possibility to make contacts and refuse the
transfer (only if some contacts do explicitely refuse it or for the
reasons outlined in the current policy or its march 2009 revision) ;
even if that case, streamlining of the difference between registrant
and admin contact should be achieved, and maybe the registrant
contact should be taken completely out of the procedure of domain
name transfers management.

- if removing this part from the policy is not possible, then I would
recommend working on making the registrant contact a same class
citizen as the administrative one and maybe taking it out of the
equation for the reasons outlined above, and at the same time working
either on IRIS and/or EPP (see some ideas above) to see how exchanges
of email adresses could be made simpler or exchanged for other
authentication, based on the current authInfo.


I'm clearly against any further work on whois as known today to try
shoehorning something into it. This energy should be more properly
spent on IRIS growth/adoption and/or EPP adjustements.
I do note that progressively working on whois replacement in favor of
IRIS will have good consequences for transfers (even if only the
administrative contact remains concerned, the standardized format of
IRIS would make it easier to get access to administrative email
address, not even counting about the proper authorization framework
around IRIS access) and other issues, such as display of personal
information through current publicly available whois (some issues as
being worked on by other working group).




======================================================================

Issue 2. About other type of electronic authentications

Like the report says, emails are not always a very good type of
authentication. They can be spoofed, hijacked, and redirected (when
someones waits for the domain name on which a contact primarily email address 
is recorded, such as gmail.com in bob@xxxxxxxxx , to be dropped
because not renewed - and this has already happened in the past
including for very high profiles domain names - and then reregister
it and have instant access to all emails directed to it).
Which makes me wonder even more about why they are still used as
primarily token of authentications during domain name transfers, in
contrast of using the more secure authInfo one.

Emails could be protected further by the use of technologies such as
OpenPGP and/or S/MIME to ensure integrity, confidentiality and
especially authentication (of registrar sending the messages, to
prevent phishing, and of the contact replying, to prevent bogus
replies). But as far as I know they are not widely used in this case.

Also, access to a website (protected by a SSL certificate), with the
browser (and hence the user) authentifying itself with another SSL
certificate may be seen as a better security method than current
emails.

Many other schemes may be imagined.

I do not think the GNSO/ICANN should start defining these mechanisms
through beforehand procedures that would apply uniformly to each
registrar.

Registrars should decide if they want to use other methods of
authentication, and which ones. It would be a clear and huge factor
of differentiation between registrars.
Before starting to use it, they could provide information about their
procedure to the relevant registry that would then be notified and
could act if it thinks the new mechanism is not good enough.
Also (or replacing previous point), yearly ICANN could monitor which
mechanisms are used by registrars and verify they meet some
requirements, or it can be done during regular registrars auditing
and/or when disputes arise for some transfers using some "new"
authentication method.
Another idea would be to put in place a process similar to the RSTEP
one for new registry services.



This would allow the market to invent other means without having to
wait for very long procedures beforehand. However some checks after
problems or regularly make sure that the whole system is not derailed
by some ill attempts. So a correct mixture of free market innovation
with some ICANN/GNSO policies to put some boundaries would be my
recommendation.


=====================================================================

Issue 3. Handling partial bulk transfer between registrars


I have no specific ideas on this issue, as it seems something not
very frequent. Or at least not very known/heard of.

As I said in my introduction on top, it may help here to have some
hard numbers and to know:
- which registries have/had this issue,
- how many registrars does it involve,
- the reasons, if any, for the need of a partial bulk transfer,
(specifically because the report speaks about registrar-initiated
transfers instead of registrant-initiated, which may mean internal
handling of domain names inside a group of registrars controlled by
one and the same entity) ;
- and how many domain names (and/or as percentage of the total
portfolio considered for partial bulk transfer)

If these numbers happen to be very low, it may not be a good idea to
focalize a lot of resources inside ICANN and the GNSO to think about
this issue. Especially because it rise a lot of issues around
security, fees, requirements, cases where it can apply or not, etc.

The report gives 5 scenarios (cases) on pages 24 & 25 :
- Partial Bulk Transfer following ICANN accreditation of a reseller
I do not believe this happens more than a few times per year. Are
there data about that ?
- Partial Bulk Transfer between registrars (end of agreement with one
gTLD)
I believe that the registrar concerned knows when it agreement will
come to an end (except for failures on this part, but then this is
another problem), so it has plenty of time to do transfers before
that date.
- Partial Bulk Transfer in case of a (partial) merger
or acquisition between registrars
Like first case, I'm not sure this happens a lot per year. Are there
data about that ?
- Partial Bulk Transfer initiated by a registrant
The report itself previously asserts that this case is already
handled directly by registrars as a specific service. Hence no
specific new policy may be needed in that case.
- Partial Bulk Transfer following de-accreditation of a registrar
SAme case as the first one, and I think it may happen even less
frequently. Any data ?


In short I pretty much agree with the report preliminary conclusion,
stating that 
"there is no need to incorporate provisions for handling partial
bulk transfers between registrars at this stage"






-- 
Patrick Mevzek
Dot and Co <http://www.dotandco.com/> <http://www.dotandco.net/>