Re: [bc-gnso] Question/comment regarding HSTLD Verification Program
- To: "Michael D. Palage" <michael@xxxxxxxxxx>, Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>, bc - GNSO list <bc-gnso@xxxxxxxxx>, Craig Schwartz <craig.schwartz@xxxxxxxxx>
- Subject: Re: [bc-gnso] Question/comment regarding HSTLD Verification Program
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Thu, 4 Nov 2010 07:35:51 -0500
i'm a member of the HSTLD group and would like to commend you for your
questions. they compliment the question that's been in my mind during the
whole HSTLD discussion, which is:
"will the HSTLD program work?"
there is definitely **not** consensus today within the HSTLD group at this time
on the answer to my question or yours Steve. another question which remains
open is "what is the scope of authority of, and participation in, the program?"
certainly registries, that's a given. but what about registrars? what about
registrants? what are the implications of widening the scope to include all
three of those groups? is it practical? is it possible?
if you think verifying the capabilities of registry security people is hard,
imagine what it's going to be like to verify/certify that the security teams of
every registrar and **every registrant** can manage security to a level that
assures end users. which gets to another fundamental unanswered question --
"who is the ultimate customer of the HSTLD program and what is it going to
provide them?" again, that question hasn't been answered yet by the advisory
group and it's far from consensus on that topic.
the advisory group is charged with figuring out whether such a program is
advisable and practical. the RFI is intended to get reactions from Smart
People. your questions are a great start and i'm hoping to see more as the
conversation proceeds. i'd like to see the RFI responses come in, the advisory
group come to consensus around some of these fundamental issues, and then see a
public comment cycle to check our work.
On Nov 3, 2010, at 2:08 PM, Michael D. Palage wrote:
> You can contact staff directly as to the interpretation of the proper
> channel of public comment. However, my impression is that because the HSTLD
> is still doing its work and has not authored a draft/final policy document,
> there is no need for a formal public comment channel at this time. Instead,
> the RFI which has been prominently displayed on ICANN's announcement section
> has received responses from six global consulting firms, so I think we must
> be doing something right.
> If you like you can review the MP3 recording from today's call which should
> be posted online shortly as to the agreed upon next steps: edits to response
> document that will be sent to respondents due by end of this week; ICANN to
> send respondents the answers to the questions received, along with posting
> this document publicly on the HSTLD website; consultation with ICANN Legal
> Counsel in connection with a number of issues discussed today on the call;
> conference call with respondents/potential vendors after ICANN legal counsel
> call; and draft of final report.
> Best regards,
> -----Original Message-----
> From: owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of
> Steve DelBianco
> Sent: Wednesday, November 03, 2010 2:40 PM
> To: 'bc - GNSO list'
> Subject: [bc-gnso] Question/comment regarding HSTLD Verification Program
> 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
> registry operation.
> 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?
> Steve DelBianco
> Executive Director
> http://www.NetChoice.org and http://blog.netchoice.org
- - - - - - - - -
handle OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)