The IESG writes ("Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to
Informational"):
The IESG has received a request to consider Registry Registrar Protocol
(RRP) Version 1.1.0 <draft-hollenbeck-rrp-00.txt> as an Informational
RFC. This has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org mailing lists by January
13, 2000.
I can see at least the following problems with this protocol, in
addition to those described in it:
* The TRANSFER command, when used to approve a transfer, does not
specify to which registrar the domain is to be transferred. The
document says that the details of transfer arrangements should be
handled out-of-band by eg electronic mail. However, that would not
prevent a domain mistakenly or maliciously being transferred to the
wrong new registrar. It is essential that this deficiency in the
protocol is corrected or worked around forthwith, as currently a
malicious registrar who is able to manipulate unsecured out-of-band
email may be able to cause the domain to be transferred to themselves
instead of to the intended recipient registrar.
A workaround would be for the intended recipient to send (via another
protocol) to the donor an authenticated confirmation to the that it
had successfully lodged the transfer request, so that if the donor is
willing to transfer to that registrar it can safely approve the
transfer. However, the technical integrity of this scheme depends on
the registry never unexpectedly losing or timing out transfer
requests, and on donors to keep a record of all recent transfer
requests to ensure that the right request is accepted; the sociolegal
integrity of such a workaround may depend on extremely complicated
contractual issues, which is not my field of expertise. In any case
this caveat should be addressed in any Information RFC.
* The use of passwords for identifying registrars rather than the
certificate information corresponding to the SSL session is very
unwise. The secret(s) which identify a registrar should never leave
that registrar. For example, a security compromise at the registry
would require all the registrars' passwords to be changed, and
redistributed via secure out-of-band channels. Furthermore, the use
of passwords makes it impossible to use secure hardware to store the
critical key material. This misfeature should be fixed in future
versions and implementations.
* The use of registry local time in time stamps is absurd (and will
likely lead to daylight saving change bugs etc.). The time used
should be in UTC, or preferably elapsed civil time measured as the
number of non-leap seconds since a suitable epoch. This misfeature
should be fixed in a future protocol version.
* The use of SSL, rather than individually authenticating requests and
responses (or batches of them), means that there is no audit trail,
verifiable by a third party, for resolving disputes. This bug should
be fixed in a future protocol version.
I think that any Informational RFC describing this protocol should at
the very least mention these deficiencies as well as those it already
lists.
Ian.