[HR-rt] Human Rights Review of draft-ietf-regext-verificationcode

Gurshabad Grover <gurshabad@cis-india.org> Thu, 20 September 2018 21:01 UTC

Return-Path: <gurshabad@cis-india.org>
X-Original-To: hr-rt@ietfa.amsl.com
Delivered-To: hr-rt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1E9129C6A; Thu, 20 Sep 2018 14:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.102
X-Spam-Level:
X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FILL_THIS_FORM=0.001, FILL_THIS_FORM_LONG=2, LOTS_OF_MONEY=0.001, MONEY_FORM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-ok_Gm4TuAI; Thu, 20 Sep 2018 14:01:43 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BECA130DF6; Thu, 20 Sep 2018 14:01:43 -0700 (PDT)
Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gurshabad@cis-india.org>) id 1g364x-00061I-PI; Thu, 20 Sep 2018 23:01:41 +0200
From: Gurshabad Grover <gurshabad@cis-india.org>
Openpgp: preference=signencrypt
Autocrypt: addr=gurshabad@cis-india.org; keydata= xsFNBFriroIBEADfyDpCD8eborMUMXKtZzjo4t2KzrAlUVYgE/TFtrwUP+4Xw4dzakDIzST8 sVYmlXIWhM5NBBTZSQ190vsxrkbi0xxLcXYM2olZEtqkJ8zONZeZLBeGvcfMymtHqD4jHwYb Zm7OXnS45fWDL+HOoMP/VCwEn098rYfnllIkYQD1Gc28Ig+ywjGg8y5p0qMmmmhm2ckgLjnG MJX8t273MSc8wsn/UYH922yif3MQXmrzqgnRl9hRzf90SKqAw38bw7wccb55pIItloKYsi0r zYBKJSOPXn91Z21TpOSTy21M0MZYEAlDn1zeea+q8TggfHNWxOXoKrIm1pqZFRz0k+8i2siJ AHf8bRm/fhukA6szZ6b2nNPxjkAmOv9zvGu6RZGbmeLvQYVBSSnZ67ayZrkKwn7KIyAV6hQM /bVnD8eEZ2tZ0S8lxoZFYSNeMGt2b6WelFZO97/LbjxaJUHd9K8g5H0MwqN1NXoBxRwllVRC 3sVHVoWTBqnKo8qplzvQEAto69PpvuxxKTOFEJeQqmn1b/fo3sLRb4YiIg8Ax+Np7Huzzjk6 vKKgpIwIN7yEUj/ReWi/UA/W4wSg3XkcqTf7h73crnN/1At0PdgozbDV2UbcApaldStP4DfG UiQl0/7MiYLKapDDuSahmoeH3xrNnrzS9BAfuGHezzDbMyPLXQARAQABzSpHdXJzaGFiYWQg R3JvdmVyIDxndXJzaGFiYWRAY2lzLWluZGlhLm9yZz7CwX0EEwEIACcFAlriroICGyMFCQlm AYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQrbl/X+ubfC7/bQ//YQv7zqQE433xxsN/ 3GYKoOFccBy3WvV4DxrTskJ3n3k5lfcZolbc8TQksQOTzyerNt2ZA7fsGZa7eFSW+xR4Yq3/ C9o+5FOoHGhyZhb+x17MILhmyvyUNSj7SdKrRISgurMbV2Vv8LxmTcdrK6CdFF6JLH+opzU1 NlRKwZqROPgbYZEB2QFIUbGfgh2I5AXNyV2XbT7fagfkHk+v9AUV7POP2H1+AZ1xq6iFTm2o 9ufNZsp2bInsDohcVBKC3aH2cnFMjvIXpNoUOx8vb5A2xW0aBUTTJDB/uZw53WOg3kehrCNb ZkML3FnDZLRuu1e8DSWmwk5YIoDzt5bMCgfUwb0C6Q+JuM8lC+8CEEa9qamLc+fhvFAzcrWp VWuSaVeLdhe5NxmtlRYNZdGuKy6sRHjwsEWlwzRylhm74fiDR3aA1eIFsfmYLd4z+i1Fp23Y dHJf7/Gor2CmOxphog9DEA9WCuORXfx4De7hoMKwW4gWKw1A8B12Cv4EOkXmCsWsOnfDEarr 2Yl6elxkhQRfKjAesXb0cezRzZgwsWIsbeYsuWFF7Xi6IzUJ27lxU3p5PcyY8O8aDYOn+pu0 YFJ7s3u2VRRgptVZJmkcN3WTApXSHY8fGl5xAakM/bqFJj9uj5zlMnFN2EplC6/mQkfYfy2f siaGTP/GQV4OSuOeuMLOwU0EWuKuggEQAJ4lAzB72gHw4+rbyxmQNNVmvgYVZPjFtO/MQdYi x1QwRP/gxxqPqTd/ZwQvmPGzXRKw10B7uKSRk6YP12+IG0mXJwHGp9q5CWJE0XNGqX3UWbAc KIzxqPNpsf8e6Bv7jdW0YwLBxJ+RW0NNL6uAxz0sr2frbnS+EZB3cU+zOZzp/9YfTUZO2lxF NzgJoErKe/HLp7aBeJXBBcwO0LQlIT80rTZx2KihBa/Ww/y9E9gV/HacJu/Ncb6E/G3e4xGj 9w9L+UW43q01wy+FSUKy9FLc7D40WqQsj8SXZEpl84SyLcJRoX3mtj59bX2SAN2VB2BAksTu qCh00IcIUGfyHziu5PwUWYM96gOhDSocP4wSeiQ8TwLzaffllz2qhdI296a9lCIYIeWVytEd NU9jJ3RbzXAgE0pnDauNXDaQv1FS5jYi8rlslJUxKnrS69BFNjM5RqQ16Cm0C4rKL7/a8wHC r4VjcjSCM8Lzv8YOOitJ9Yt4Y8SVfO5s3YvxcdSr56nX0W3B1kGbG1GpqWTzOgXzGF5bIsbV 7SPecwUs9ShvmLmZzDUxIQ68n4zj3lMZn5I+pP+Ew6nAAiuSmKdr5cygnCH/NVJzil07t+X4 uR6oKHBhuMFYF1c6Wxk36m+EZz5ZHFaT4rN0WDIJdAEqRzD0Z56V6ansDF8y+ksh0SHlABEB AAHCwWUEGAEIAA8FAlriroICGwwFCQlmAYAACgkQrbl/X+ubfC50rhAAloTaq/fZC1gtiVtU wOB+00gEkjgmzt+rLkW+l2EySTST7tje57W83UZwzCX746B2O//Bqardxz9R1Vr0VFiwHA8g 3qeBqPqiv1WoQch/iZ5d/1MxK4A9xDag1uyqLR8RuGlZ8lATmcP3IabKiuiBV4MlFZ7V2Ib6 5ToPf28xxSyjMzTjQObIG0e009uHlu2z+iQVshLyoyVVAOWWa88D6iuBDC/EtBRjlpjLAjuR YhWVYX6KHdVUijKMHN2RqjpX5O2wPL7NcMY/wsTq7EteUeI75hxFvargRXkEt1XR8t52LC0u IE2OjpzY5re/ROUbfsqL8trjAOrSJ+Fx5H8AYl9JaoVxohhxDZgNtgNtPbh/8Nnlf9daj/bh lZcTBO98XLQwMnyHGPdyhIodpWPq2C09Ys3TkQsbcdMMB1pqnEK5Vz1zIKkEEX7QVsLdrz7C 2CFsauc/9PHj+4njCHslXtzBOiVu5FXTnbCwPrLJs5iEUkUCb6qtE/2mSCTrAanzOTTOmqiM cnNTI1Tj0ht462S9VypppQnKCv8shGxXG7BadZTv+pNCA/WfB2kk1sS3ZwB0wBWX4p41fxs+ ArM9ew2SzQ/vBrEfO7ljPfZZmBqH4t/vgAZBnOtTxCGlPEIJqiMqtGHRqIqpiR20QfxEUuXI MfMfa9QJpisdNmqoUyc=
To: regext@ietf.org
Cc: "hrpc@irtf.org" <hrpc@irtf.org>, hr-rt@irtf.org
Message-ID: <528ea38a-7e8f-b425-4c49-71c83694c193@cis-india.org>
Date: Fri, 21 Sep 2018 02:31:31 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="sgtzh0IlpNNU7hoFvRDPTQVuuLZxpUDsw"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 5a7ab29fa651aee4c569e25635c94281
Archived-At: <https://mailarchive.ietf.org/arch/msg/hr-rt/tzlT0nVChFf2VyD-ewFP6TAxm1M>
Subject: [HR-rt] Human Rights Review of draft-ietf-regext-verificationcode
X-BeenThere: hr-rt@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Human Rights Protocol Considerations Review Team <hr-rt.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hr-rt>, <mailto:hr-rt-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hr-rt/>
List-Post: <mailto:hr-rt@irtf.org>
List-Help: <mailto:hr-rt-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hr-rt>, <mailto:hr-rt-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Sep 2018 21:01:46 -0000

Hi all,

Firstly, thanks to James Gould and the regext working group for
developing draft-ietf-regext-verificationcode.

As part of efforts in the Human Rights Protocol Considerations (HRPC)
group, I have reviewed the human rights considerations (using RFC 8280
as a framework) in draft-ietf-regext-verificationcode-03. Please find
the review below. Hope that some of these concerns can be addressed
moving forward.


HR Review: Verification Code Extension for the EPP
==================================================

An assessment of human rights considerations in
draft-ietf-regext-verificationcode-03.

Introduction
------------
The ‘Verification Code Extension for the Extensible Provisioning
Protocol (EPP)’ ([VCEPP], hereinafter also referred to as the “draft”)
describes an extension in the EPP object mappings which supports adding
a verification code provided by a third-party known as the Verification
Service Provider (VSP). If the registrant’s data is not “verified” by
the VSP, it may be prohibited from requesting the execution of EPP
transform commands.

This is a review of the human rights considerations in the the draft.
(See [RFC 8280], ‘Research Into Human Rights Protocol Considerations’).
We believe that the draft does not make adequate considerations for
human rights: The implementation of the proposed extension will impact
domain registrants’ right to freedom of expression, right to freedom of
assembly and association, and right to privacy.

Human Rights Considerations
---------------------------

# Privacy ([RFC8280], section 6.2.2)

From [RFC8280]: “Could your protocol improve data minimization?” and
“Does your document identify potentially sensitive data logged [...]
and/or for how long that data needs to be retained for technical reasons?”

The draft leaves the precise data shared with the VSP “up to the
policies of the locality” and outside the scope of the draft. In the
'domain-registrant' type of verification, both the registrant contact
information and domain name are sent to the VSP. The registrant contact
information is sensitive personal information, including name, address,
telephone number and email address. [RFC5733]

The draft notes that, “the data verified by the VSP MUST be stored by
the VSP along with the generated verification code to address any
compliance issues.” The information is retained and “may be accessed at
a later time.”

Registrants whose personal information will be shared in this way have
no control over these aspects, which negatively impacts their privacy.

# Content Agnosticism ([RFC8280], section 6.2.3)

From [RFC8280]: “Does your protocol make decisions based on the payload
[...]? Does your protocol prioritize certain content or services over
others [...]?”

Section 1 of the draft states that the “Verification Service Provider
(VSP) is a certified party to verify that data is in compliance with the
policies of a locality.” Therefore, the extension facilitates the
prioritization of certain individuals based on how the VSP judges
whether the registrants’ data is compliant. Registrants’ data which is
not in “compliance” with the local regulations will not receive a
verification code from the VSP, which gives the VSP the power to
restrict individuals from registering/modifying a domain name, and
limits their right to freedom of expression.

# Censorship Resistance ([RFC8280], section 6.2.6)

From [RFC8280]: “Can your protocol contribute to filtering in such a way
that it could be implemented to censor data or services?  [...]”

By design, the extension facilitates filtering: the VSP will receive the
power to “verify” data on arbitrary grounds when determining whether
registrant data is in “compliance” with local regulations. The draft
also identifies examples of these scenarios: the VSP will check whether
“the domain name is not prohibited”, or whether the “registrant is a
valid individual, organization, or business in the locality.” On these
grounds, the VSP can accept or reject attempts to register domain names.
Thus, the extension explicitly provides filtering and censorship
abilities to the VSP, which are inimical to the registrants’ freedom of
expression.

# Open Standards ([RFC8280], section 6.2.7)

From [RFC8280], “Are you aware of any patents that would prevent your
standard from being fully implemented [RFC6701] [RFC8179]?”

There is an IPR declaration filed by Verisign Inc. for an older version
of the draft mentioning the relevant [PATENT]. The declaration
facilitates mostly open development, giving minimal assertion rights
over the license for Verisign Inc.

From [RFC8280]: “Is your protocol fully documented in such a way that it
could be easily implemented, improved, built upon, and/or further
developed?”

Several key details that will form the complete mechanism for the
verification code are not included in the draft (as it only describes
the extension), but have been offered in the [PATENT]. This includes a
description of the grace period within which “the requirement set of
verification codes may be sent before the object becomes non-compliant”,
and a clear depiction of the flow of the request detailed in Fig. 1 of
the [PATENT].

# Decentralisation ([RFC8280], section 6.2.14)

From [RFC8280]: “What is the potential for discrimination against users
of your protocol?”

There is immense potential for discrimination against registrants whose
data will be subject to “verification” by the VSP. The proposed
extension provides the VSP powers to discriminate against registrants
based on the information it receives, which may include names and
addresses, and which may be further compared to other “local data
sources” [VCEEPP] to indicate legal sex, religious affiliation, or
ethnicity.

From [RFC8280]: “Can your protocol be used to negatively implicate users
(e.g., incrimination, accusation)?”

There is potential for negative implication: a malicious registrant may
submit a request for a domain name considered legally “prohibited” by
the locality, accompanied with someone else's personal information.
Registrant information is sent to the VSP, an entity that may be
associated with law enforcement, which creates potential misuse for
false incrimination/accusation.

# Reliability ([RFC8280], section 6.2.14)

No fallback mechanism is specified within the draft for when the VSP is
offline or unavailable. In the event that the VSP is not available to
process the sent object, the registrants’ requests will not be performed.

Similarly, when considering how long the VSP takes to process a
particular request, Section 0057 of the [PATENT] states that a “pending
compliance status indicator may indicate that the object is not
compliant by [...] a time, or grace period, in which the requirement set
of verification codes may be sent before the object becomes
non-compliant.” Therefore, if the VSP does not respond within the grace
period, the object will be considered “non-compliant”. The proposed
extension thus creates a problematic assumption of  “non-compliance”,
which is at odds with the presumption of innocence.

# Confidentiality ([RFC8280], section 6.2.15)

From [RFC8280]: “What options exist for [...] implementers to choose to
limit the information shared with each entity?”

No such mechanisms are present which allow the registrants to limit the
information that will be accessed by the VSP.

# Integrity ([RFC8280], section 6.2.16)

From [RFC8280]: “Does your protocol maintain, assure, and/or verify the
accuracy of payload data? Does your protocol in any way allow the data
to be (intentionally or unintentionally) altered?”

The XML Signature maintains authenticity and integrity of the
verification code. However, we are not sure whether the object can be
altered by the VSP before appending the verification code to the shared
object. If so, it creates the potential for false implication (also see
section on Decentralisation) by the VSP.

# Outcome transparency ([RFC8280], section 6.2.19)

From [RFC8280]: “Are the effects [...] fully and easily comprehensible
[...]?”

As highlighted earlier in the review, many details (some out of the
scope of the draft) may be opaque to registrants with the implementation
of the proposed extension, including but not limited to, the exact data
shared with the VSP.

Additionally, as the [PATENT] notes, a “rejection of the verification
request may be transmitted [...]” by the VSP. Therefore, while the
proposed extension technologically facilitates a legal mechanism, there
are no built-in measures that facilitate human rights related to legal
transparency, remedy, or due process. For example, the VSP has no option
to append an explanation for sending back a rejection.

Conclusion
----------
In summary, the proposed extension in its implementation allows the VSP
to have enormous censorship and discriminatory power. The arbitrary and
opaque mechanism to “verify” compliance with local regulations gives
disproportionate powers to impede freedom of expression, right to
privacy, freedom of association, and the right to non-discrimination.

Some of the concerns highlighted in this review have already been
pointed out in the past in and outside the IETF. [NLLZMSG][ART-19] We
hope that the WG considers the potential adverse human rights impact
that the proposed extension creates before recommending its
standardisation. We understand that some of the concerns in the review
do not stem purely from the proposed extension, but due to the
unavoidable consequences of implementing the extension. The WG could
consider adding the details of those to the draft as well, so as to make
its impact on human rights clearer.

References
----------
[RFC8280] ten Oever, N., Cath, C., “Research into Human Rights Protocol
Considerations”, RFC 8280, October 2017,
<https://www.rfc-editor.org/info/rfc8280>.
[VCEEPP] Gould, J., “Verification Code Extension for the Extensible
Provisioning Protocol (EPP)”, draft-ietf-regext-verificationcode-03,
April 2018,
<https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/>.
[IP-DECL] Ward, M., “Verisign Inc.'s Statement about IPR related to
draft-gould-eppext-verificationcode”, October 2015,
<https://datatracker.ietf.org/ipr/2703/>
[RFC5730] Hollenbeck, S., “Extensible Provisioning Protocol (EPP)”, RFC
5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>
[RFC5731] Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain
Name Mapping”, RFC 5731, August 2009,
<https://www.rfc-editor.org/info/rfc5731>.
[RFC5732] Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Host
Mapping”, RFC 5732, August 2009,
<https://www.rfc-editor.org/info/rfc5732>.
[RFC5733] Hollenbeck, S., “Extensible Provisioning Protocol (EPP)
Contact Mapping”, RFC 5733, August 2009,
<https://www.rfc-editor.org/info/rfc5733>.
[PATENT] Waldron, J., et al. “Domain Name Operation Verification Code
Generation and/or Verification”, United States Patent Serial No.
14/868,972, September 2015,
<https://patents.google.com/patent/US20170093793A1/en?oq=United+States+Patent+Serial+No.+14%2f868%2c972>.
[NLLZMSG] ten Oever, N., “Re: [regext] I-D Action:
draft-ietf-regext-verificationcode-01.txt”, IETF Mail Archive: regext,
April 2017, 
<https://mailarchive.ietf.org/arch/msg/regext/EIK0E7ins874q8DmP37yg7AzAQI>.
[ART-19] Article 19 Digital, “Corporate actors must not facilitate human
rights violations through new Chinese rules”, Article 19, December 2016,
<https://www.article19.org/resources/corporate-actors-must-not-facilitate-human-rights-violations-through-new-chinese-rules/>.

Acknowledgements
----------------
Thanks to Paul Kurian for research inputs. Thanks to Amelia
Andersdotter, Mallory Knodel, Sunil Abraham and Swaraj Barooah for their
feedback. Please note that acknowledgement here does not necessarily
imply endorsement of the contents of the review.

--
Thank you.
Gurshabad