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

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 28 Oct 2014 16:15:47 -0700

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.

= Section 3.4 =
"If the policy of the server operator
   requires encryption to protect client-server data exchanges (such as
   to protect non-public data that can not be accessed without client
   identification and authentication), HTTP Over TLS MUST be used to
   protect those exchanges."

It is unclear to me that a server policy that allows unencrypted access
should be allowed, particularly in the cases of entity-related requests,
but perhaps also in the case of other requests. The fact that the
registry data may be public is orthogonal to the question of whether a
particular query for that data should have confidentiality protection.
I'd like to understand why RDAP does not require HTTP over TLS to be used
in all cases and instead allows unsuspecting client users to send their
queries in the clear in cases where server policy does not mandate use of
TLS. I'm especially curious about this since clients are required to
support HTTPS anyway.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Section 3.1 =
"RDAP's authentication framework needs to accommodate anonymous access
   as well as verification of identities"

I would suggest s/anonymous access/unauthenticated access/ since
generally it can be pretty difficult to remain anonymous when accessing
anything over IP.

Similar comment for 3.2, I would delete "or anonymous."

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 29 Oct 2014 15:03:34 +0000

> -----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)
> 

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?

> TLS. I'm especially curious about this since clients are required to

The current text is a reflection of operational possibilities in which the server operator does not support queries that could return PII. I don't believe we had WG support for requiring HTTPS in such situations. Do we need to mandate TLS for all servers?

Agreed. "unauthenticated" is appropriate.

Scott

---

From: Pete Resnick <[email-masked]>
Date: Wed, 29 Oct 2014 08:31:47 -0700

On 10/28/14 4:15 PM, Alissa Cooper wrote:
> facilitate those policy choices.

So this is the first time I've had any serious discussion of privacy 
issues in one of my WGs, so please be patient with me as I try to get my 
head around the issue.

I would expect that questions of *policy*, i.e., what 
registries/registrars desire or are required to give out, is something 
that the protocol documents should not discuss at all. What we want to 
talk about in the document is how the protocol is able to provide 
whatever protections on privacy the supplier of the information desires 

> their use should be minimized.

A general statement that says, "The server should minimize the amount of 
info it sends back" I get, but the existence of fields in the jCard spec 
doesn't seem like something that we should be talking in terms of. If 
you are sending back the data, you should send it in the appropriate 
jCard field. If for some particular registry, there is a policy that 
involves publicly producing the date of birth of a registrant, insofar 
as we think that absurd, we're talking about the policy, not the 
existence of the jCard field.

If that assessment is correct, then I've got real worries about saying 
anything more than handwavy about data privacy policies given the 
politics of the entities involved.

> restricted to specifically privileged clients.

seem sufficiently high-level to work in a Privacy Considerations section 
(somewhere). But when you get to:

> but perhaps also in the case of other requests.

That gets me a bit more nervous, as I'm not sure we should be commenting 
on any particular policy like this.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "John Levine" <[email-masked]>
Date: 29 Oct 2014 18:20:32 -0000

>The current text is a reflection of operational possibilities in
>which the server operator does not support queries that could return
>PII. I don't believe we had WG support for requiring HTTPS in such
>situations. Do we need to mandate TLS for all servers?

One of my early bootstrap proposals was https only, and people said
no, don't do that.  Even though everyone supports https, the wide
variation in CAs and ciphers makes interop failures surprisingly
common.  For example, imagine a ccTLD that uses a cert signed by an
authority that is widely used in its own country, and unknown
elsewhere.

Also keep in mind that not all URLS start with http or https.  For a
small provider handling what would currently be SWIPs, it might well
be easier to use ftp.

R's,
John

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 30 Oct 2014 07:48:48 -0700

> authority that is widely used in its own country, and unknown

I think Scott’s answer points in the direction where I'm thinking this should go, which is to require use of TLS for entity queries but perhaps not for other queries. That seems to me like a more balanced approach than saying that the possibility of interop failure (or a load problem, per Andy’s response to Stephen) negates the need for any sort of confidentiality requirement in all cases. Servers that cannot support TLS can then still support a more limited set of queries.

> small provider handling what would currently be SWIPs, it might well

I don’t understand this comment since I thought RDAP requires servers to support HTTP.

Alissa

> 
> R's,
> John
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: "John R Levine" <[email-masked]>
Date: 30 Oct 2014 10:59:44 -0400

> I think Scott’s answer points in the direction where I'm thinking this 
> should go, which is to require use of TLS for entity queries but perhaps 
> not for other queries. ...

But there's no particular reason to expect that an entity query will 
return PII any more than any other query.  Ask about one of the entities 
for, say, ibm.com and you'll just get some role account.  Ask anything 
about someone's vanity domain, entity or not, and it's all PII.

> I don’t understand this comment since I thought RDAP requires servers to support HTTP.

Nope.  The bootstrap is http, but the URLs it points to or that other 
servers redirect to can be anything.  Speaking as one of the world's 
smallest registries (if you want a watkins-glen.ny.us domain, you know who 
to ask), sticking a few things on anonymous FTP would be pretty easy.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Andy Newton <[email-masked]>
Date: Thu, 30 Oct 2014 15:22:05 +0000

On Oct 30, 2014, at 10:59 AM, John R Levine <[email-masked]> wrote:

>> I think Scott’s answer points in the direction where I'm thinking this should go, which is to require use of TLS for entity queries but perhaps not for other queries. ...
> 
> But there's no particular reason to expect that an entity query will return PII any more than any other query.  Ask about one of the entities for, say, ibm.com and you'll just get some role account.  Ask anything about someone's vanity domain, entity or not, and it's all PII.

More to the point, lookups for networks and domains (which is ~99% of all queries today) will have entities embedded in them. MUST HTTPS for entities would work for thin domain registries but not for anybody else.

> Nope.  The bootstrap is http, but the URLs it points to or that other servers redirect to can be anything.  Speaking as one of the world's smallest registries (if you want a watkins-glen.ny.us domain, you know who to ask), sticking a few things on anonymous FTP would be pretty easy.

Ummm… what? No, I don’t think that would work. Additionally, the bootstrap doc mentions RDAP URLs. Maybe that isn’t specific enough, but RDAP is not specified over anything other than HTTP(S).

-andy