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

[Kathleen Moriarty <[e-mail]>]

On Tue, Nov 4, 2014 at 6:38 PM, Alissa Cooper <[e-mail]> wrote:
> Hi all,
>
> On Oct 29, 2014, at 8:03 AM, Hollenbeck, Scott <[e-mail]>
> wrote:
>
> -----Original Message-----
> From: weirds [mailto:[e-mail]] On Behalf Of Alissa
> Cooper
> Sent: Tuesday, October 28, 2014 7:16 PM
> To: The IESG
> Cc: [e-mail]; weirds-
> [e-mail]; [e-mail]
> 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.

Thanks, Alissa.  Your suggested text looks very good.

-- 

Best regards,
Kathleen