idnits 2.17.1 draft-loffredo-regext-rdap-reverse-search-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 22, 2018) is 2227 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7482 (Obsoleted by RFC 9082) ** Obsolete normative reference: RFC 7483 (Obsoleted by RFC 9083) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions M. Loffredo 3 Internet-Draft M. Martinelli 4 Intended status: Standards Track IIT-CNR/Registro.it 5 Expires: September 23, 2018 March 22, 2018 7 Registration Data Access Protocol (RDAP) Reverse search capabilities 8 draft-loffredo-regext-rdap-reverse-search-01 10 Abstract 12 The Registration Data Access Protocol (RDAP) does not include query 13 capabilities to find the list of domains related to a set of entities 14 matching a given search pattern. Even if such capabilities, commonly 15 referred to as reverse search, respond to some needs not yet readily 16 fulfilled by the current Whois protocol, they have raised concern 17 from two perspectives: server processing impact and data privacy. 18 Anyway, the impact of the reverse queries on RDAP servers processing 19 is the same of the standard searches and it can be reduced by 20 implementing policies to deal with big result sets, while data 21 privacy risks can be mitigated by RDAP access control functionalites. 22 This document describes RDAP query extensions that allows clients to 23 request a reverse search based on the domains-entities relationship. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 23, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 61 2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 3 62 3. Implementation Considerations . . . . . . . . . . . . . . . . 4 63 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 64 4.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 Reverse Whois is a service provided by many web applications that 77 allows users to find domain names owned by an individual person or 78 company starting from the owner details (like name, email). Even if 79 the availability of this service might raise some objections due to 80 potential privacy risks, ICANN itself, in its report about Next-Gen 81 Registration Directory Service (RDS) [ICANN], states that it is 82 allowed when driven by some permissible purposes (e.g. legal actions, 83 criminal investigations) and if it provides adequate policies to 84 enforce the requestor accreditation, authentication, authorization, 85 and terms and conditions of data use. 87 It is well known that these features are not implemented in Whois 88 [RFC3912], while they are in RDAP. In fact, RDAP relies on security 89 features, available in the HTTP protocol, to support access control 90 based on local policy [RFC7481]. 92 Another objection to the implementation of Reverse Whois is connected 93 with its impact on server processing. Since RDAP supports search 94 queries, the impact of both standard and reverse searches can be 95 mitigated by servers adopting ad hoc policies. 97 Reverse searches, such as finding the list of domain names associated 98 to contacts, nameservers or DNSSEC keys, may be useful for registrars 99 as well. Usually, registries adopt out-of-band mechanisms to provide 100 results to registrars asking for reverse searches on their domains. 101 Possible reasons of such requests are: 103 o the loss of synchronization between the registrar database and the 104 registry database; 106 o the need of such data to perform massive EPP updates (i.e. 107 changing the contacts in a list of domains, etc.). 109 Currently, RDAP does not provide any way for a client to search for 110 the collection of domains associated to an entity [RFC7482]. A query 111 (lookup or search) on domains can return the array of entities 112 related to a domain with different roles (registrant, registrar, 113 administrative, technical, reseller, etc.), but the reverse operation 114 is not allowed. Only reverse searches to find the collection of 115 domains according to a nameserver (ldhName or ip) can be requested. 116 Since entities can be in relationship with all RDAP objects 117 [RFC7483], the availability of a reverse search can be common to all 118 RDAP query paths. 120 The protocol described in this specification aims to extend the RDAP 121 query functionalities to enable reverse search based on the domains- 122 entities relationship (the classic Reverse Whois scenario). The 123 extension is implemented by adding new path segments (i.e. search 124 paths) and using a RESTful web service [REST]. The service is 125 implemented using the Hypertext Transfer Protocol (HTTP) [RFC7230] 126 and the conventions described in RFC 7480 [RFC7480]. 128 1.1. Conventions Used in This Document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 2. RDAP Path Segment Specification 136 The new search paths are OPTIONAL extensions of path segments defined 137 in RFC 7482 [RFC7482]. The search paths are (Figure 1): 139 Syntax: domains?entityHandle= 141 Syntax: domains?entityFn= 143 Search patterns are the same as specified in paragraph Section 3.2.3 144 of RFC 7482 [RFC7482]. 146 https://example.com/rdap/domains?entityHandle=CID-40* 148 Figure 1: Example of RDAP query to find all domains related to an 149 entity whose handle matches "CID-40*" 151 Search results MAY be restricted to a specific entity role, simply by 152 adding the parameter "entityRole" to the search path (Figure 2). 153 Possible values for such parameter are those detailed in 154 Section 10.2.4 of RFC 7483 [RFC7483]. 156 https://example.com/rdap/domains?entityFn=Bobby*&entityRole=technical 158 Figure 2: Example of RDAP query to find all domains related to a 159 technical contact whose formatted name matches "Bobby*" 161 FOR DISCUSSION: Should reverse search be based on other entity 162 details like email, phone, country (code or name), city? 164 3. Implementation Considerations 166 The implementation of the proposed extension is technically feasible 167 because "handle" and "fn" segment paths are used as standard paths to 168 search for entities. The risks to generate huge result sets are the 169 same existing for the other standard searches and can be mitigated by 170 adopting the same policy (e.g. restricting search functionalities, 171 limiting the rate of search requests, truncating and paging the 172 results, returning partial responses). 174 4. Implementation Status 176 NOTE: Please remove this section and the reference to RFC 7942 prior 177 to publication as an RFC. 179 This section records the status of known implementations of the 180 protocol defined by this specification at the time of posting of this 181 Internet-Draft, and is based on a proposal described in RFC 7942 182 [RFC7942]. The description of implementations in this section is 183 intended to assist the IETF in its decision processes in progressing 184 drafts to RFCs. Please note that the listing of any individual 185 implementation here does not imply endorsement by the IETF. 186 Furthermore, no effort has been spent to verify the information 187 presented here that was supplied by IETF contributors. This is not 188 intended as, and must not be construed to be, a catalog of available 189 implementations or their features. Readers are advised to note that 190 other implementations may exist. 192 According to RFC 7942, "this will allow reviewers and working groups 193 to assign due consideration to documents that have the benefit of 194 running code, which may serve as evidence of valuable experimentation 195 and feedback that have made the implemented protocols more mature. 196 It is up to the individual working groups to use this information as 197 they see fit". 199 4.1. IIT-CNR/Registro.it 201 Responsible Organization: Institute of Informatics and Telematics 202 of National Research Council (IIT-CNR)/Registro.it 203 Location: https://rdap.pubtest.nic.it/ 204 Description: This implementation includes support for RDAP queries 205 using data from the public test environment of .it ccTLD. The 206 RDAP server does not implement any security policy because data 207 returned by this server are only for experimental testing 208 purposes. 209 Level of Maturity: This is a "proof of concept" research 210 implementation. 211 Coverage: This implementation includes all of the features 212 described in this specification. 213 Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it 215 5. Security Considerations 217 Security services for the operations specified in this document are 218 described in RFC 7481 [RFC7481]. It is quite easy to imagine that, 219 in order to be compliant with ICANN recommendations about its use, 220 RDAP servers will provide reverse search, like other query 221 capabilities, only to restricted communities. One realistic scenario 222 for servers is to provide reverse search only for registrars 223 searching for their own domains. Another one is to prevent users to 224 start a reverse search from a registrant detail, by removing 225 "registrant" from the possible values of the "entityRole" parameter. 227 6. IANA Considerations 229 This document has no actions for IANA. 231 7. Acknowledgements 233 The authors would like to acknowledge Scott Hollenbeck for his 234 contribution to this document. 236 8. References 238 8.1. Normative References 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, 242 DOI 10.17487/RFC2119, March 1997, 243 . 245 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 246 DOI 10.17487/RFC3912, September 2004, 247 . 249 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 250 Protocol (HTTP/1.1): Message Syntax and Routing", 251 RFC 7230, DOI 10.17487/RFC7230, June 2014, 252 . 254 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 255 Registration Data Access Protocol (RDAP)", RFC 7480, 256 DOI 10.17487/RFC7480, March 2015, 257 . 259 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 260 Registration Data Access Protocol (RDAP)", RFC 7481, 261 DOI 10.17487/RFC7481, March 2015, 262 . 264 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 265 Protocol (RDAP) Query Format", RFC 7482, 266 DOI 10.17487/RFC7482, March 2015, 267 . 269 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 270 Registration Data Access Protocol (RDAP)", RFC 7483, 271 DOI 10.17487/RFC7483, March 2015, 272 . 274 8.2. Informative References 276 [ICANN] Internet Corporation For Assigned Names and Numbers, 277 "Final Report from the Expert Working Group on gTLD 278 Directory Services: A Next-Generation Registration 279 Directory Service (RDS)", June 2014, 280 . 283 [REST] Fielding, R., "Architectural Styles and the Design of 284 Network-based Software Architectures", 2000, 285 . 288 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 289 Code: The Implementation Status Section", BCP 205, 290 RFC 7942, DOI 10.17487/RFC7942, July 2016, 291 . 293 Appendix A. Change Log 295 00: Initial version. 296 01: Revised some sentences and references. 298 Authors' Addresses 300 Mario Loffredo 301 IIT-CNR/Registro.it 302 Via Moruzzi,1 303 Pisa 56124 304 IT 306 Email: mario.loffredo@iit.cnr.it 307 URI: http://www.iit.cnr.it 309 Maurizio Martinelli 310 IIT-CNR/Registro.it 311 Via Moruzzi,1 312 Pisa 56124 313 IT 315 Email: maurizio.martinelli@iit.cnr.it 316 URI: http://www.iit.cnr.it