Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Tue, 4 Nov 2014 15:38:32 -0800

Hi all,

On Oct 29, 2014, at 8:03 AM, Hollenbeck, Scott <[email-masked]> wrote:

>> -----Original Message-----
>> From: weirds [mailto:[email-masked]] On Behalf Of Alissa
>> Cooper
>> Sent: Tuesday, October 28, 2014 7:16 PM
>> To: The IESG
>> Cc: [email-masked]; weirds-
>> [email-masked]; [email-masked]
>> Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-
>> sec-10: (with DISCUSS and COMMENT)
>> 
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-weirds-rdap-sec-10: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to http://www.ietf.org/iesg/statement/discuss-
>> criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> = General comment =
>> I'm not exactly sure which document this remark is directed at, but I'm
>> putting it in a DISCUSS here and we can figure that out later.
>> 
>> I feel like the RDAP document suite is missing an overall explanation
>> of
>> the privacy threat model associated with registration data, the policy
>> choices that are left up to registry providers, and the mechanisms
>> included in RDAP to help protect registrant  and client/user privacy
>> and
>> facilitate those policy choices. There are mentions of some of this
>> here
>> and there, but even those are not necessarily consistent with each
>> other
>> (see my DISCUSS on draft-ietf-weirds-using-http). So I think it would
>> be
>> beneficial to capture this in one place and articulate it explicitly,
>> rather than implicitly across the documents. Some of the salient points
>> for starters:
>> 
>> * WHOIS data has historically included personal information about
>> registrants, has been made public, and has not had the benefit of
>> authentication or access control mechanisms to gate access to it. In
>> part
>> as a result of this, proxy and privacy services have arisen to shield
>> the
>> identities of registrants.
>> 
>> * The standardization of RDAP does not change or impact the data that
>> registries may require to be collected from registrants. However, RDAP
>> data structures allow servers to indicate when data returned to clients
>> has been made private, redacted, obscured, or shielded by a proxy.
>> 
>> * RDAP uses the jCard standard format for entity representation, but
>> many
>> of the jCard fields are irrelevant for registry operation purposes and
>> their use should be minimized.
>> 
>> * RDAP includes mechanisms that can be used to authenticate clients,
>> allowing servers to support tiered access based on local policy. This
>> means that all registration data need no longer be public, and personal
>> data or data that may be considered more sensitive can have its access
>> restricted to specifically privileged clients.
>> 
>> * [Something about confidentiality of requests and responses ... see my
>> other DISCUSS point below.]
>> 
>> * etc.
> 
> I could see adding a good bit of what you wrote above to a new section titled "Privacy Threats Associated with Registration Data" that appears as a new section in the Introduction or perhaps between the existing sections 2 and 3. Would one of those options work?

During the IESG call last week I said that I would take point on suggesting text to accommodate both my and Kathleen’s suggestions for this new privacy threats section. Picking up from the points above and from the thread about Kathleen’s json-response DISCUSS, my strawman suggestion for a new section in rdap-sec is below. I tried to frame this as an explanation of the available choices to registries that want to mitigate the identified privacy threats, picking up on Pete and Ed’s concerns that we do not want to be specifying registry policy in the weirds documents.

I’m still thinking about my other DISCUSS point re TLS … will follow up on that later.

---

Privacy Threats Associated with Registration Data

Registration data has historically included personal data about registrants. WHOIS services have historically made this information available to the public, creating a privacy risk by revealing the personal details of registrants.  WHOIS services have not had the benefit of authentication or access control mechanisms to gate access to registration data. In part as a result of this, proxy and privacy services have arisen to shield the identities of registrants.

The standardization of RDAP does not change or impact the data that registries may require to be collected from registrants, but it provides support for a number of mechanisms that may be used to mitigate privacy threats to registrants should registries choose to use them. 

RDAP includes mechanisms that can be used to authenticate clients, allowing servers to support tiered access based on local policy. This means that all registration data need no longer be public, and personal data or data that may be considered more sensitive can have its access restricted to specifically privileged clients.

RDAP data structures allow servers to indicate via status values when data returned to clients has been made private, redacted, obscured, or registered by a proxy. Private means that the data is not designated for public consumption. Redacted means that some registration data fields are not being made available. Obscured means that data has been altered for the purposes of not readily revealing the actual registration information. One option that registries have available to them to reduce privacy risks to registrants is to adopt policies that make use of these status values to restrict the registrant data shared with any or all clients according to the sensitivity of the data, the privileges of the clients, or some other heuristics. 

RDAP uses the jCard standard format for entity representation. Registries may find that many of the jCard fields are irrelevant for registry operation purposes or that they have no reason to collect information from registrants that would correspond to certain fields. Registries wishing to reduce privacy risks for registrants may restrict which information they collect and/or which fields they populate in responses.

In addition to privacy risks to registrants, there are also potential privacy risks for those who query registration data. For example, the fact that a law enforcement officer performs a particular query may reveal information about the officer’s activities that she would have preferred to keep private. To provide privacy protection for those querying registrant data as well as registrants, RDAP supports the use of HTTP over TLS.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 4 Nov 2014 19:34:16 -0500

On Tue, Nov 4, 2014 at 6:38 PM, Alissa Cooper <[email-masked]> wrote:
> I could see adding a good bit of what you wrote above to a new section
> titled "Privacy Threats Associated with Registration Data" that appears as a
> new section in the Introduction or perhaps between the existing sections 2
> and 3. Would one of those options work?
>
>
> During the IESG call last week I said that I would take point on suggesting
> text to accommodate both my and Kathleen’s suggestions for this new privacy
> threats section. Picking up from the points above and from the thread about
> Kathleen’s json-response DISCUSS, my strawman suggestion for a new section
> in rdap-sec is below. I tried to frame this as an explanation of the
> available choices to registries that want to mitigate the identified privacy
> threats, picking up on Pete and Ed’s concerns that we do not want to be
> specifying registry policy in the weirds documents.
>
> Registration data has historically included personal data about registrants.
> WHOIS services have historically made this information available to the
> public, creating a privacy risk by revealing the personal details of
> registrants.  WHOIS services have not had the benefit of authentication or
> access control mechanisms to gate access to registration data. In part as a
> result of this, proxy and privacy services have arisen to shield the
> The standardization of RDAP does not change or impact the data that
> registries may require to be collected from registrants, but it provides
> support for a number of mechanisms that may be used to mitigate privacy
> threats to registrants should registries choose to use them.
>
> RDAP includes mechanisms that can be used to authenticate clients, allowing
> servers to support tiered access based on local policy. This means that all
> registration data need no longer be public, and personal data or data that
> may be considered more sensitive can have its access restricted to
> specifically privileged clients.
>
> RDAP data structures allow servers to indicate via status values when data
> returned to clients has been made private, redacted, obscured, or registered
> by a proxy. Private means that the data is not designated for public
> consumption. Redacted means that some registration data fields are not being
> made available. Obscured means that data has been altered for the purposes
> of not readily revealing the actual registration information. One option
> that registries have available to them to reduce privacy risks to
> registrants is to adopt policies that make use of these status values to
> restrict the registrant data shared with any or all clients according to the
> sensitivity of the data, the privileges of the clients, or some other
> heuristics.
>
> RDAP uses the jCard standard format for entity representation. Registries
> may find that many of the jCard fields are irrelevant for registry operation
> purposes or that they have no reason to collect information from registrants
> that would correspond to certain fields. Registries wishing to reduce
> privacy risks for registrants may restrict which information they collect
> and/or which fields they populate in responses.
>
> In addition to privacy risks to registrants, there are also potential
> privacy risks for those who query registration data. For example, the fact
> that a law enforcement officer performs a particular query may reveal
> information about the officer’s activities that she would have preferred to
> keep private. To provide privacy protection for those querying registrant
> data as well as registrants, RDAP supports the use of HTTP over TLS.

Thanks, Alissa.  Your suggested text looks very good.

-- 

Best regards,
Kathleen

---

From: "John Levine" <[email-masked]>
Date: 5 Nov 2014 03:09:15 -0000

>Privacy Threats Associated with Registration Data

Everything you say is true, but it's equally true about any protocol
that might let you query a database that contains PII.  It would, for
example, be applicable to online phone book web sites.

For the ICANN contracted registries and registrars, the policies about
who can see what via WHOIS are defined by their contracts with ICANN,
sometimes modified by national law where it is more restrictive.  All
of the ccTLDs that offer WHOIS have their own policies, again informed
by the relevant national law.  For numbering information, the RIRs
again set their own policies through their internal processes,
although it's less of an issue since it is rare for RIRs to delegate
to individuals rather than organizations.

Since this is an IETF document that describes mechanisms, and the
likely implementers mentioned above already have (better or worse)
WHOIS privacy policies in place which nobody I know expects to be
different when they move from WHOIS to RDAP, could you clarify who is
the intended audience for this privacy discussion?

R's,
John

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Nov 2014 15:21:13 +0000

First I’ll say I am fine with the suggested text.

Second I’ll respond a bit to John’s comment below:

-----Original Message-----
From: John Levine <[email-masked]>
Date: Tuesday, November 4, 2014 at 22:09
To: "[email-masked]" <[email-masked]>
Subject: Re: [weirds] Alissa Cooper's Discuss on
draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT)

>sometimes modified by national law where it is more restrictive.

Nit picking, the “ICANN" policies aren’t *defined* in the contracts,
polices in ICANN are a result of a policy development process - analogous
to many other organizations.  “WhoIs” is a significant topic of discussion
amongst participants in the policy development processes.

>All

I’d disagree with that to some extent.  There’s a strong structural
analogy between an RIR allocating space to an LIR who then assigns a small
range to a customer to a (domain name *) TLD accepting a registration of a
name from a registrar on behalf of a registrant.  E.g., some TLDs permit
registrant contact information to be obscured via a third party; some
RIR’s permit obscuring the holder of a less than a “slash-X” (/29 in
IPv4?) of space.

I’ve worked both sides of the fence, there’s not much difference between
them.  Really, registries are registries.  How they decide to approve a
request may differ - addresses are based on demonstrated need while some
names are first-come-first-served and some have other criteria, the
process of registration (object -> entity) is the same.

>the intended audience for this privacy discussion?

IMHO, anyone who will implement RDAP without reading all of the documents
in the IETF library. ;)

Implementers != Operators, just as protocol engineers != implementers
(IETF is pretty good at bridging that gap).

Sometimes implementers need to know what knobs and dials are needed in
code so that operators can run the protocol.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 5 Nov 2014 15:56:13 +0000

> From: weirds [mailto:[email-masked]] On Behalf Of Edward Lewis
> Sent: Wednesday, November 05, 2014 10:21 AM
> To: [email-masked]
> Cc: Kathleen Moriarty; John Levine
> Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-
> rdap-sec-10: (with DISCUSS and COMMENT)
> 

I, too, don't have any issues with the proposed text. I may change my mind if/when I actually add it to the document and read it more closely, but in the meantime I think it's fine.

This last point made by Ed is significant. Guidance that helps policy makers better understand the new knobs and dials we're making available to them will be helpful. Clearly identifying these topics will help inform policy-making discussions that will need to start soon given that some operators have contractual terms that address implementation and deployment of RDAP. Here's the text from the base registry agreement (http://newgtlds.icann.org/en/applicants/agb/agreement-approved-20nov13-en.pdf):

"Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry."

Scott

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 5 Nov 2014 10:47:08 -0500

> code so that operators can run the protocol.

Exactly.  As we discussed on the telechat, we (ADs interested in this
discussion) are all fine with pointing out that knobs are available
with RDAP and can be used or not used according to implementers
policies.  We'd all be a bit more comfortable if there was at least
some educational discussion pointing out what is available and have no
interest in setting what gets implemented in any kind of policy.

Thanks.

-- 

Best regards,
Kathleen