<<<
Chronological Index
>>> <<<
Thread Index
>>>
Study Suggestion Number 4
- To: study-suggestions@xxxxxxxxxxxxxxxxxxxx
- Subject: Study Suggestion Number 4
- From: study-suggestion-response@xxxxxxxxx
- Date: Fri, 11 Jan 2008 14:01:47 -0800
Submitted By:
[Redacted for privacy reasons]
Topic:
Transport Layer Security for WHOIS database lookups
Hypothesis:
Traffic to Port 43 is not secure. This has grave ramifications for business on
the Internet whenever a WHOIS lookup must remain confidential. A simple query
to WHOIS is always required prior to registering a domain name, but this
traffic is subject to being disclosed.
How the hypothesis could be falsified:
Only by ignoring RFC 3912, which states: "For historic reasons, WHOIS lacks
many of the protocol design attributes, for example internationalisation and
STRONG SECURITY, that would be expected from any recently-designed IETF
protocol. This document does not attempt to rectify any of those shortcomings."
(Emphasis added)
Furthermore, the industry may feel there is no need for a secure transaction
for WHOIS. But unlike email, news, NTP, DNS, and web traffic, which are all
normally transferred unencrypted, global WHOIS lookups have no secure transport
layer to use when confidentiality or security is required. Most other network
technologies have a secure counterpart,
Utility:
It is my opinion that some of the hotly debated problems of WHOIS data being a
privacy concern can be alleviated knowing that the data is not transmitted in
the clear, but is sent over secure TLS channels from the requester to Verisign
and back.
But my main concern is the fiasco with DNS NXDOMAIN queries that are sold and
resold to domain tasters. We already know that domain tasters want to obtain
lookups that indicate a party's interest in registering a domain. And that this
threat could soon be directed at port 43 queries, too. It is time to rethink
the 25 year old WHOIS lookup method, especially while we are debating domain
tasting, domain privacy, and access to the growing database of domain name
registrations.
Type of Study Needed:
Primarily, we need to consider the current trends for alleviating this problem,
and then implement them. There is already some standards to work with (see
below). What we need is consensus by the major players, namely ICANN and
Versign, and the industries that the represent and support.
The costs to those companies needs to be evaluated. The other parties, such as
the registrars and the registries, will follow the lead of the industry.
Data that needs to be collected:
The IETF working group, CRISP, has concluded, and has offered to implement an
approved cure. See
http://www.ietf.org/html.charters/crisp-charter.html
"IRIS provides no authentication or privacy facilities of its own. It
relies on the application-transport layer for all of these abilities.
Implementers need to fully understand the application-transports
employed by IRIS."
>From http://tools.ietf.org/html/draft-ietf-crisp-iris-core-05#section-10
>From RFC 3981: http://www.ietf.org/rfc/rfc3981.txt
"The IRIS XML layer provides no authentication or privacy facilities
of its own. It relies on the application-transport layer for all of
these abilities. Application-transports should explicitly define
their security mechanisms (see Section 8.2)."
And from: RFC 4698: http://tools.ietf.org/html/rfc4698
"This registry type uses the default server authentication method as
described in IRIS-BEEP" which is RFC 3983, http://www.ietf.org/rfc/rfc3983.txt
also know as IRIS over BEEP:
"Proposed Name: IRIS over BEEP"
In other words, by using IRIS over BEEP, the transport layer of the
communication between the requester and the server can be made secure using
TLS, an encryption standard.
It would appear that RFC 4698 and RFC 3983 are on the standards track, but not
approved. However, I believe that if ICANN took a step to requiring registrars
to begin implementing IRIS and areg, then we may be closer to realizing a
secure transport layer.
Population to be surveyed:
Sample Size:
Type of Analysis:
Determine if this would be a replacement or a mandatory supplement to the
existing WHOIS lookups, and for how long. We need to determine how this change
would fit into the current system and determine how long the old system will be
around if it is meant as a replacement. Obviously, getting rid the current
WHOIS system might take upwards of ten years, depending on deployment and user
needs.
It is my belief that once secure WHOIS is rolled out, the domain community will
be a strong proponent of it, while the typical user may not be for a long time.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|