idnits 2.17.1 draft-loffredo-regext-rdap-reverse-search-00.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 (October 3, 2017) is 2397 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: April 6, 2018 October 3, 2017 7 Registration Data Access Protocol (RDAP) Reverse search capabilities 8 draft-loffredo-regext-rdap-reverse-search-00 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 April 6, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 Reverse Whois is a service provided by many web applications that 76 allow users to find domain names owned by an individual person or 77 company starting from the owner details (like name, email). Even if 78 the availability of this service might raise some objections due to 79 potential privacy risks, ICANN itself, in its report about Next-Gen 80 Registration Directory Service (RDS) [ICANN], states that it is 81 allowed when driven by some permissible purposes (e.g. legal actions, 82 criminal investigations) and if it provides adequate policies to 83 enforce the requestor accreditation, authentication, authorization, 84 and terms and conditions of data use. 86 It is well known that these features are not implemented in Whois 87 ([RFC3912]), while they are in RDAP. In fact, RDAP relies on 88 security features, available in the HTTP protocol to support access 89 control based on local policy ([RFC7481]). 91 Another objection to the implementation of Reverse Whois is connected 92 with its impact on server processing. Since RDAP supports search 93 queries, the impact of both standard and reverse searches can be 94 mitigated by servers adopting ad hoc policies. 96 Reverse searches, such as finding the list of domain names associated 97 to contacts, nameservers or DNSSEC keys, may be useful for registrars 98 as well. Usually, registries adopt out-of-band mechanisms to provide 99 results to registrars asking for reverse searches on their domains. 100 Possible reasons of such requests are: 102 o the loss of synchronization between the registrar database and the 103 registry database; 105 o the need of such data to perform massive EPP updates (i.e. 106 changing the contacts in a list of domains, etc.). 108 Currently, RDAP does not provide any way for a client to search for 109 the collection of domains associated to an entity ([RFC7482]). A 110 query (lookup or search) on domains can return the array of entities 111 related to a domain with different roles (registrant, registrar, 112 administrative, technical, reseller, etc.), but the reverse operation 113 is not allowed. Only reverse searches to find the collection of 114 domains according to a nameserver (ldhName or ip) can be requested. 115 Since entities can be in relationship with all RDAP objects 116 ([RFC7483]), the availability of a reverse search can be common to 117 all RDAP query paths. 119 The protocol described in this specification aims to extend the RDAP 120 query functionalities to enable reverse search based on the domains- 121 entities relationship (the classic Reverse Whois scenario). The 122 extension is implemented by adding new path segments (i.e. search 123 paths) and using a RESTful web service ([REST]). The service is 124 implemented using the Hypertext Transfer Protocol (HTTP) [RFC7230] 125 and the conventions described in RFC 7480 [RFC7480]. 127 1.1. Conventions Used in This Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 2. RDAP Path Segment Specification 135 The new search paths are OPTIONAL extensions of path segments defined 136 in RFC 7482 [RFC7482]. The search paths are (Figure 1): 138 Syntax: domains?entityHandle= 140 Syntax: domains?entityFn= 142 Search patterns are the same as specified in paragraph Section 3.2.3 143 of RFC 7482 [RFC7482]. 145 https://example.com/rdap/domains?entityHandle=CID-40* 147 Figure 1: Example of RDAP query to find all domains related to an 148 entity whose handle matches "CID-40*" 150 Search results MAY be restricted to a specific entity role, simply by 151 adding the parameter "entityRole" to the search path (Figure 2). 152 Possible values for such parameter are those detailed in 153 Section 10.2.4 of RFC 7483 [RFC7483]. 155 https://example.com/rdap/domains?entityFn=Bobby*&entityRole=technical 157 Figure 2: Example of RDAP query to find all domains related to a 158 technical contact whose formatted name matches "Bobby*" 160 FOR DISCUSSION: Should reverse search be based on other entity 161 details like email, phone, country (code or name), city? 163 3. Implementation Considerations 165 The implementation of the proposed extension is technically feasible 166 because "handle" and "fn" segment paths are used as standard paths to 167 search for entities. The risks to generate huge result sets are the 168 same existing for the other standard searches and can be mitigated by 169 adopting the same policy (e.g. restricting search functionalities, 170 limiting the rate of search requests, truncating and paging the 171 results, returning partial responses). 173 4. Implementation Status 175 NOTE: Please remove this section and the reference to RFC 7942 prior 176 to publication as an RFC. 178 This section records the status of known implementations of the 179 protocol defined by this specification at the time of posting of this 180 Internet-Draft, and is based on a proposal described in RFC 7942 181 [RFC7942]. The description of implementations in this section is 182 intended to assist the IETF in its decision processes in progressing 183 drafts to RFCs. Please note that the listing of any individual 184 implementation here does not imply endorsement by the IETF. 185 Furthermore, no effort has been spent to verify the information 186 presented here that was supplied by IETF contributors. This is not 187 intended as, and must not be construed to be, a catalog of available 188 implementations or their features. Readers are advised to note that 189 other implementations may exist. 191 According to RFC 7942, "this will allow reviewers and working groups 192 to assign due consideration to documents that have the benefit of 193 running code, which may serve as evidence of valuable experimentation 194 and feedback that have made the implemented protocols more mature. 195 It is up to the individual working groups to use this information as 196 they see fit". 198 4.1. IIT-CNR/Registro.it 200 Responsible Organization: Institute of Informatics and Telematics 201 of National Research Council (IIT-CNR)/Registro.it 203 Location: https://rdap.pubtest.nic.it/ 205 Description: This implementation includes support for RDAP queries 206 using data from the public test environment of .it ccTLD. The 207 RDAP server does not implement any security policy because data 208 returned by this server are only for experimental testing 209 purposes. 211 Level of Maturity: This is a "proof of concept" research 212 implementation. 214 Coverage: This implementation includes all of the features 215 described in this specification. 217 Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it 219 5. Security Considerations 221 Security services for the operations specified in this document are 222 described in RFC 7481 [RFC7481]. It is quite easy to imagine that, 223 in order to be compliant with ICANN recommendations about its use, 224 RDAP servers will provide reverse search, like other query 225 capabilities, only to restricted communities. One realistic scenario 226 for servers is to provide reverse search only for registrars 227 searching for their own domains. Another one is to prevent users to 228 start a reverse search from a registrant detail, by removing 229 "registrant" from the possible values of the "entityRole" parameter. 231 6. IANA Considerations 233 This document has no actions for IANA. 235 7. Acknowledgements 237 The authors would like to acknowledge Scott Hollenbeck for his 238 contribution to this document. 240 8. References 242 8.1. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, 246 DOI 10.17487/RFC2119, March 1997, 247 . 249 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 250 DOI 10.17487/RFC3912, September 2004, 251 . 253 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 254 Protocol (HTTP/1.1): Message Syntax and Routing", 255 RFC 7230, DOI 10.17487/RFC7230, June 2014, 256 . 258 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 259 Registration Data Access Protocol (RDAP)", RFC 7480, 260 DOI 10.17487/RFC7480, March 2015, 261 . 263 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 264 Registration Data Access Protocol (RDAP)", RFC 7481, 265 DOI 10.17487/RFC7481, March 2015, 266 . 268 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 269 Protocol (RDAP) Query Format", RFC 7482, 270 DOI 10.17487/RFC7482, March 2015, 271 . 273 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 274 Registration Data Access Protocol (RDAP)", RFC 7483, 275 DOI 10.17487/RFC7483, March 2015, 276 . 278 8.2. Informative References 280 [ICANN] Internet Corporation For Assigned Names and Numbers, 281 "Final Report from the Expert Working Group on gTLD 282 Directory Services: A Next-Generation Registration 283 Directory Service (RDS)", June 2014. 285 [REST] Fielding, R., "Architectural Styles and the Design of 286 Network-based Software Architectures", 2000. 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 Authors' Addresses 295 Mario Loffredo 296 IIT-CNR/Registro.it 297 Via Moruzzi,1 298 Pisa 56124 299 IT 301 Email: mario.loffredo@iit.cnr.it 302 URI: http://www.iit.cnr.it 304 Maurizio Martinelli 305 IIT-CNR/Registro.it 306 Via Moruzzi,1 307 Pisa 56124 308 IT 310 Email: maurizio.martinelli@iit.cnr.it 311 URI: http://www.iit.cnr.it