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, 2 Dec 2014 09:54:01 -0800

Thanks for addressing my DISCUSS points. I just have a couple of follow-ups.

I’m glad to see this new text in 3.5:

   HTTP Over TLS MUST be used to
   protect all client-server exchanges unless operational constraints
   make it impossible to meet this requirement.

Is it implied that this applies to rdap-bootstrap as well?

Couple of comments on this text in section 5:

   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 he or she
   would have preferred to keep private.  RDAP supports the use of HTTP
   over TLS to provide privacy protection for those querying registrant
   data as well as registrants.

Someone in Honolulu suggested to me that the law enforcement officer example might not be the best one, and that’s probably right. I would suggest substituting another term instead — maybe “registry employee”?

I would also suggest editing the last sentence to match the above text from 3.5: “RDAP requires the use of HTTP over TLS to provide privacy protection for those querying registrant data as well as registrants, unless operational constraints make it impossible to meet this requirement.”

Also given the new text in 3.5, it seems like the recommendations in section 6 regarding the TLS null cipher suite should be updated as well. I would suggest "This option MUST NOT be used” — assuming the same operational constraints caveat does not apply here.

Thanks,
Alissa

On Oct 28, 2014, at 4:15 PM, Alissa Cooper <[email-masked]> wrote:

> 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: Tue, 2 Dec 2014 18:00:00 +0000

> -----Original Message-----
> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2014 12:54 PM
> To: IESG
> Cc: [email-masked]; weirds-
> [email-masked]; [email-masked]
> Subject: Re: Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10:
> (with DISCUSS and COMMENT)
> 
> I'm glad to see this new text in 3.5:
> 

Yes. The bootstrap document currently says this:

"The transport used to access the registries could be more secure by using TLS [RFC5246] if IANA supports it."

So if IANA supports it TLS MUST  be used.

> Someone in Honolulu suggested to me that the law enforcement officer
> example might not be the best one, and that's probably right. I would
> suggest substituting another term instead - maybe "registry employee"?
> 
> I would also suggest editing the last sentence to match the above text
> from 3.5: "RDAP requires the use of HTTP over TLS to provide privacy
> protection for those querying registrant data as well as registrants,
> unless operational constraints make it impossible to meet this
> requirement."
> 
> Also given the new text in 3.5, it seems like the recommendations in
> section 6 regarding the TLS null cipher suite should be updated as
> well. I would suggest "This option MUST NOT be used" - assuming the
> same operational constraints caveat does not apply here.

These are all reasonable suggestions. I'll do another edit.

I can't think of an operational reason to use the TLS null cipher...

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 15 Dec 2014 13:11:36 +0000

Top posting...

Alissa, draft-ietf-weirds-rdap-sec was updated on 2 December to address the comments described below. Could you please take another look and update your discuss position if the new version addresses your feedback appropriately?

Scott

> From: weirds [mailto:[email-masked]] On Behalf Of Hollenbeck,
> Scott
> Sent: Tuesday, December 02, 2014 1:00 PM
> To: Alissa Cooper; IESG
> Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-
> rdap-sec-10: (with DISCUSS and COMMENT)
> 
> "The transport used to access the registries could be more secure by
> using TLS [RFC5246] if IANA supports it."
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds