[bc-gnso] Question/comment regarding HSTLD Verification Program
- To: "'bc - GNSO list'" <bc-gnso@xxxxxxxxx>
- Subject: [bc-gnso] Question/comment regarding HSTLD Verification Program
- From: Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>
- Date: Wed, 3 Nov 2010 18:39:54 +0000
On our last BC policy call, I mentioned that ICANN issued a Request for
Information (RFI) on a proposal to verify high-security zones (HSTLDs).
For some reason, this RFI is not being done thru the regular channel of
Public Comment, but is instead being advertised on the ICANN news page:
Staff will hold a call to discuss the RFI, indicating that 'participation in
the next call on this program Participation in the call will be open to
anyone that submitted questions prior to 27 October 2010.'
BC member Mike Palage co-chairs the High Security Zone TLD Advisory Group
(HSTLD AG) working on this issue. BITS is also closely following the HSTLD
program and submitted their own comments. If BITS or other BC members want
to share their HSTLD comments, please reply to this note.
The BC has no official position on the HSTLD program.
In my personal capacity, I submitted the following comments/questions in
order to be able to participate in the upcoming call:
I am concerned that ICANN¹s HSTLD verification program is aiming to
commoditize the most complex and critical aspects of running a secure
The Merriam-Webster Dictionary definition of commoditize is 'to render (a
good or service) widely available and interchangeable with one provided by
another company'. That sounds like a good idea if you¹re a registrant or
user of a domain where secure operations are essential.
But let's ask whether high security registry operation can ever really be
effectively and beneficially commoditized.
*First, the only thing about a high security operation that is 'widely
available' is hardware and software. Beyond that, it is notoriously
difficult to assemble a team of security professionals who have experience
with thousands of attacks and intrusion attempts. It's even more difficult
to build and maintain relationships with law enforcement and with internet
service providers across the globe.
Question: How will HSTLD verification measure real-world experience and the
extent of global relationships needed to diagnose and neutralize a security
*Second, a high security operation is not interchangeable across TLDs that
have different business models and distribution networks, many of which are
mandated by ICANN.
Question: Will HSTLD verification ever be achievable for a TLD that is
required to be open to all accredited registrars?
*Third, a high security designation will lose its value quickly in a world
where bad actors continually develop new threats and where evolving
technologies reveal new vulnerabilities.
Question: Will HSTLD verification attempt to measure a TLD's adaptive
responsiveness or will operators be re-verified whenever new threats or
vulnerabilities are discovered?
Those questions are more rhetorical than literal, although I'd appreciate
any attempt to answer them. I raise these questions mainly to say why an
HSTLD verification stamp may not be the desired definitive signal to
registrants and industries trying to decide where its safe to host their
Moreover, I fear that a program that attempts to commoditize high security
operations will reduce incentives for registries to continually invest and
innovate in security capabilities and personnel. Under ICANN¹s program
proposal, would any operator who achieves Overification¹ be deemed just as
secure as any other verified operator? Could an operator sign a contract
with one of ICANN¹s verified vendors, and skip the part about spending years
to build an experienced security team and processes?
If I had to put this in the form of a single question, it¹s this: How will
ICANN's HSTLD program verify and/or measure relevant security experience and
performance in the face of evolving security threats and vulnerabilities?
http://www.NetChoice.org and http://blog.netchoice.org