Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04241AD02D for ; Wed, 29 Oct 2014 23:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 U0htbUCbl02F for ; Wed, 29 Oct 2014 23:52:43 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91EE61AD02C for ; Wed, 29 Oct 2014 23:52:43 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hy10so2374150vcb.40 for ; Wed, 29 Oct 2014 23:52:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=q7P8rLtUr7dYASsYKDKpcsmr9OIGYs/y2yV++htNddU=; b=jFKaEE5pSE5iUQPXKKdFlzSyN2LLw+lUj9/C9vwz24wX68OTmN+qo/8DZQuyxPZF2V KUiILhsaD3SyAiu4VVggzYFeO0Q4ypWytbFd8BPhmE9sJnkDunFBW5VpNQ7HJ8Nh+APT Crx6T4QFbzKsH6ayTEa8XgKzGjh/eHqBo41T5HS6KZ9GkSOwBJUPQ+omvzkejAy7E6aw 2tOpG0PJQ/wyB1zpqx2ayxcZsCrEipUbfMe9nhS+bPCHIhDPybYBEenhUrIxWW/eI1E4 C6XSI3vXevpQu9mz2I0btVriYwpJZ3zVW57KSq6EFdAIqGNSc8K5veyXBILEC9MVhDzg wAdw== X-Gm-Message-State: ALoCoQmXdRLzJhaLANOxsWT+rL6hxt9HW16JHd5XPrjMbWz8FrXfVN7lO/KLNDzTibaPKXksHkGb MIME-Version: 1.0 X-Received: by 10.221.51.71 with SMTP id vh7mr11610376vcb.27.1414651962516; Wed, 29 Oct 2014 23:52:42 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Wed, 29 Oct 2014 23:52:42 -0700 (PDT) In-Reply-To: <20141028231700.11097.11887.idtracker@ietfa.amsl.com> References: <20141028231700.11097.11887.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 23:52:42 -0700 Message-ID: From: Richard Barnes To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a11331564b4fe1305069e5396 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/s89MqtoD8KoYutWxWGt4TUnrauU Cc: "weirds-chairs@tools.ietf.org" , draft-ietf-weirds-using-http@tools.ietf.org, The IESG , weirds@ietf.org Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-using-http-14: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 06:52:45 -0000 --001a11331564b4fe1305069e5396 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 4:17 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-weirds-using-http-14: 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-using-http/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > = Section 5.6 = > "When responding to queries, it is RECOMMENDED that servers use the > Access-Control-Allow-Origin header field, as specified by > [W3C.CR-cors-20130129]. As the use of RDAP is for public resources, > a value of "*" is suitable for most cases." > > What is the use case for cross-site RDAP queries? > This seems pretty obvious to me; see, e.g., https://who.is/ Also, I am confused by the claim in the second sentence. The message that > I got from draft-ietf-weirds-rdap-sec and draft-ietf-weirds-json-response > is that one of the motivations for using HTTP for RDAP was that its > authentication features could be leveraged to provide tiered access to > data on the server, such that some of the data would not be public but > would be restricted to specific users (from > draft-ietf-weirds-json-response, Appendix A.1: "In many use cases, it is > necessary to hide or obscure the information of a registrant or contact > due to policy or other operational matters."). So it seems like if > cross-site requests are justified at all, there should be some text here > explaining when that might be the case and when not. > I agree that some clarification could be useful, in light of the fact that not *all* RDAP data will be public. In particular, I note that cross-origin requests (if authorized) will be sent with the user's cookies. So RDAP server operators should keep in mind that if they allow cross-origin requests, then they might expose access-controlled information to origins that might not be authorized. The right mitigation is probably to suggest checking the Origin header and using that as a secondary control. --Richard --001a11331564b4fe1305069e5396 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 28, 2014 at 4:17 PM, Alissa Cooper <alissa@cooperw.in&= gt; wrote:
Alis= sa Cooper has entered the following ballot position for
draft-ietf-weirds-using-http-14: 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-crit= eria.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-using-ht= tp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

=3D Section 5.6 =3D
"When responding to queries, it is RECOMMENDED that servers use the =C2=A0 =C2=A0Access-Control-Allow-Origin header field, as specified by
=C2=A0 =C2=A0[W3C.CR-cors-20130129].=C2=A0 As the use of RDAP is for public= resources,
=C2=A0 =C2=A0a value of "*" is suitable for most cases."

What is the use case for cross-site RDAP queries?

=
This seems pretty obvious to me; see, e.g., https://who.is/
=C2=A0

Also, I am confused by the claim in the second sentence. The message that I got from draft-ietf-weirds-rdap-sec and draft-ietf-weirds-json-response is that one of the motivations for using HTTP for RDAP was that its
authentication features could be leveraged to provide tiered access to
data on the server, such that some of the data would not be public but
would be restricted to specific users (from
draft-ietf-weirds-json-response, Appendix A.1: "In many use cases, it = is
necessary to hide or obscure the information of a registrant or contact
due to policy or other operational matters."). So it seems like if
cross-site requests are justified at all, there should be some text here explaining when that might be the case and when not.
<= br>
I agree that some clarification could be useful, in light of = the fact that not *all* RDAP data will be public.

In part= icular, I note that cross-origin requests (if authorized) will be sent with= the user's cookies.=C2=A0 So RDAP server operators should keep in mind= that if they allow cross-origin requests, then they might expose access-co= ntrolled information to origins that might not be authorized.=C2=A0 The rig= ht mitigation is probably to suggest checking the Origin header and using t= hat as a secondary control.

--Richard
=C2= =A0
--001a11331564b4fe1305069e5396--