I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall concerns: This draft in the first sentence portrays itself as one of a collection of documents that describe the RDAP protocol. But no other documents are referenced or cited. Reviewing all the other drafts in the weirds wg, I believe that the weirds working group considers the following three drafts to be the definition of the RDAP protocol: draft-ietf-weirds-rdap-query draft-ietf-weirds-json-response draft-ietf-weirds-using-http I would add draft-ietf-weirds-rdap-sec to the list, as it is also standards track and states requirements for behavior. But I do not know if the weirds wg considers the recommendations in the rdap-sec draft to be mandatory for all RDAP implementations to implement. The security considerations section provides little in the way of discussion of the security considerations for the RDAP protocol. It refers to discussions of protections against denial of service (rate limiting) and reuse of existing http security mechanisms (cross-site resource sharing, I think). Other than that, it says Additional security considerations to the RDAP protocol will be covered in future RFCs documenting specific security mechanisms and schemes. Since there are obvious possible security considerations (client and server authentcation, authorization, integrity, confidentiality in the server responses at least, etc.), this is weak. Luckily, draft-ietf-weirds-rdap-sec provides a discussion of many of those considerations and others as well, and mechanisms to provide those security services. I am puzzled why the authors did not cite that draft - is there some doubt that the rdap-sec draft will progress? Without such a reference, this section is inadequate. [The rdap-sec draft is very thorough, but I have a few questions I might ask about some of the recommendations - if I were reviewing that draft. But I'm not. So I won't pose them here.] 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]. I have about 10 minutes of knowledge of this header field, but I can not envision a case where cross origin resource sharing might be needed, or whether the access-control-allow-origin header is sufficiently secure for those cases. Someone who understands that area should confirm that this is reasonable and adequate. The draft contains language that might be interpreted to be normative, usually in the form "client(server) ". Maybe that would always be interpreted to be "MUST", but in some cases later text makes it appear that MAY or SHOULD is intended. Particularly section 4.1, 5.2, and 5.5. =================================== Specific comments: --------- Collecting a few comments about the posiiton of this draft wrt RDAP: Section 1 says This document is one of a collection that together describe the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). In section 2 it says RDAP query and response formats are described in other documents in the collection of RDAP specifications, while this document describes how RDAP clients and servers use HTTP to exchange queries and responses. The other parts of the "collection" are left to the reader to discover. There are no related drafts listed in the reference section. Besides having pity on your poor reader, this leaves the position of this draft somewhat unclear. The text about "how RDAP is transported using ...(HTTP)" makes it sound like HTTP is a transport protocol, not a fundamental component of the RDAP protocol. (REST is not limited to HTTP, if you can believe the web.) If the queries and responses in the two other drafts were carried in a different transport protocol, would that communication still be RDAP? It would be helpful if that was clear. The rdap-query draft contains references to the behavior in this draft, so I have decided to believe that this document is a fundamental part of the RDAP protocol. And in section 3 it says: In this document, only a JSON [RFC4627] response media type is noted, with the response contents to be described separately. This document only describes how RDAP is transported using HTTP with this format. This could be read to mean that other documents might describe how RDAP is transported using something other than HTTP, but I'm presuming it means that this document describes how RDAP is transported in HTTP only with the JSON media type, no other media types are described. --------- Going through the sections: Section 1 says: The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. The rdap-query document section 2 says: WHOIS services, in general, are read-only services. Therefore URL [RFC3986] patterns specified in this document are only applicable to the HTTP [RFC2616] GET and HEAD methods. If only HTTP GET and HEAD methods are allowed in the client, should that not be mentioned in this document? Aren't they part of the "standard HTTP mechanisms for this application"? (It would ahve been really helpful to know that restriction the first read through this document.) Section 1, page 3 A replacement protocol is expected to retain the simple transactional nature of WHOIS, while providing a specification for queries and responses, Not sure - isn't this document (a component of) the "replacement protocol"? So do you mean "RDAP retains...."? section 2 In accordance with [SAC-051], this document describes the base behavior for a Registration Data Access Protocol (RDAP). Another point of uncertainty about the position of this document wrt RDAP (part of the RDAP spec or not). But at any rate, this document does not describe the base behavior. Unless by "base behavior" you mean the "HTTP behavior". Section 3 There are a few design criteria this document attempts to meet. Did it succeed? For example, I don't see anything in this document that mandates that there is a bound on the maximum number of results to a query as mentioned below: First, each query is meant to return either zero or one result. With the maximum upper bound being set to one I'm not even sure this is answered in the json-response draft, as it seems to be concentrating on the data format of the response, not the specification of what responses or how many responses are included in a reply to what queries (no sort of state machine sort of description). Section 4.1 To indicate to servers that an RDAP response is desired, clients include an Accept: header field with an RDAP specific JSON media type, the generic JSON media type, or both. ... This specification does not define the responses a server returns to a request with any other media types in the Accept: header field, or with no Accept: header field. So it seems "clients include an Accept: header field ..." is not a MUST. MAY? SHOULD? To indicate to servers that an RDAP response is desired, clients include an Accept: header field with an RDAP specific JSON media type, the generic JSON media type, or both. Servers receiving an RDAP request return an entity with a Content-Type: header containing the RDAP specific JSON media type. Is that a "MUST return"? If the servers always return a specific JSON media type, why do the clients indicate acceptance of a generic media type? section 5 This section describes the various types of responses a server may send to a client. I don't think you meant "MAY" in the 2119 sense. section 5.1 it returns that answer in the body of a 200 response. I think this is a MUST. section 5.2 query can be found elsewhere, it returns either a 301 response code ... indicate a non-permanent redirection, and it includes an HTTP(s) URL I think these are both MUST. in the Location: header field. The client is expected to issue a subsequent request to satisfy the original query using the given URL without any processing of the URL. In other words, the server is to hand back a complete URL and the client should not have to transform the URL to follow it. Is this a MUST issue or a MAY issue? Is that should not a SHOULD NOT? Or did you want to say that the server MUST provide a URL that could be used directly by the client in a subsequent request without requiring any transformation. [I have no clue what tranformations you might be trying to avoid. For my curiousity, can you provide an example?] For this application, such an example of a permanent move might be a Top Level Domain (TLD) operator informing a client the information being sought can be found with another TLD operator (i.e. a query for the domain bar in foo.example is found at http://foo.example/domain/ bar). such an example of a --> an example of such a I don't know why you emphasized that this example is TLD operators, because the foo.example domain names don't look like TLDs to me. If the example relies on the fact that the operators are TLDs, then the domain names chosen should reflect that. Unless I'm just completely misreading this. section 5.3 If a server wishes to respond that it has no information regarding the query, it returns a 404 response code. Optionally, it MAY include additional information regarding the negative answer in the HTTP entity body. I think you mean MUST return. If a server wishes to inform the client that information about the query is available, but cannot include the information in the response to the client for policy reasons, the server MUST respond with an appropriate response code out of HTTP's 4xx range. In the second paragraph, is the server allowed to choose a 404 response code? In the second paragraph, is the server allowed to return additional information about the refusal to return the information. (e.g., "I dould tell you but I'd have to shoot you") sectin 5.4 If a server receives a query which it cannot interpret as an RDAP query, it returns a 400 response code. I think you mean MUST return. Section 4 of rdap-query says Servers MUST return an appropriate failure status code for a request with an unrecognized path segment. Is that covered by "which it cannot interpret as an RDAP query" - that is, does this section provide the status code that would be appropriate? I think the section title of "malformed queries" suits all situations better than "cannot interpret as an RDAP query". in the rdap-query section 4 case, the server can interpret the query as an RDAP query, but the query parameter is malformed. section 5.5 abuses. When a server declines to answer a query due to rate limits, it returns a 429 response code as described in [RFC6585]. I think you mean MUST return. A client that receives a 429 response SHOULD decrease its query rate, and honor the Retry-After header field if one is present. So is it SHOULD honor, since it is SHOULD decrease? Or is it MUST honor? section 7 This document made recommendations for server implementations against makes denial-of-service (Section 5.5) and interoperability with existing security mechanism in HTTP clients (Section 5.6). mechanisms Section 5.6 is Cross-Origin Resource Sharing. Is that what you meant by "interoperability with existing security mechanism in HTTP clients"? As the Access-Control-Allow-Origin header field was developed as part of enabling secure cross-site data transfers, it seems appropriate to discuss the security considerations and usage scenarios. sectin 8 In accordance with RFC5226, the IANA policy for assigning new values shall be Specification Required: values and their meanings must be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. This draft and the others are Standard track - why would extensions not also be standards track? I understand that the extensions are prefixes for JSON names and URL path segments, not extensions to the protocol. Are there other permanent sources outside the IETF that you envision developing a specification for an RDAP name/path segment extension? If you are proposing a new registry, there's a requirement of what must be included in this document in section 4.2 of rfc5226: 1) registry name 2) information that must be included in a request (this section does that) 3) review process: ordinarily Specification Required means there's a Designated Expert 4) "size, format, and syntax of registry entries" 5) "Initial assignments and reservations." The request format suggests that the request should include the "Registry operator". There's a conflation of the term "registry" here with the fact that the request is being made to an "IANA registry". "Registry operator" here I think means the operator of the registration data service to which an RDAP query could be made. 9.3 Given the description of the use of language identifiers in Section 9.2, unless otherwise specified servers SHOULD ignore the HTTP [RFC2616] Accept-Language header field when formulating HTTP entity responses, so that clients do not conflate the Accept-Language header with the 'lang' values in the entity body. (section 9.2 suggests that language identifiers, to be specified later, should be used to annotate responses.) This passage is confusing - the accept-language header is in the client's request, so the server ignoring it is not going to prevent the client from confusing that header with the 'lang' values in the (request?) entity body. (It is unfortunate that one query path segment type is called "entity" as in GET /entity/JoeDoe-Handle, but I'm pretty sure here it is talking about the http entity.) Appendix B The suggestion that caches can be avoided by inventing a random parameter with a random value to make the query look unique seems to be commonly used. To someone who has been in security for a long while, this looks like a huge (not-so-)covert channel. But I don't think that's a concern. --------- real wordsmithing comments section 1 The registration data expected to be presented by this service is Internet resource registration data - registration of domain names and Internet number resources. I think you mean "data associated with the registration of domain names and Internet number resources". I don't think you mean for RDAP to have anything to do with the registration process itself. Where complexity may reside, it is the goal of this document to place it upon the server and to keep the client as simple as possible. I think you mean "Where complexity may arise" or "may occur". section 7 protocol. However, it does not restrict against the use of security ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Strange choice of words. I think you mean it does not restrict the use. This document made recommendations for server implementations against denial-of-service (Section 5.5) and interoperability with existing security mechanism in HTTP clients (Section 5.6). "recommendations ... against denial of service" - an odd wording. I'd say "recommendations for use of rate limiting as a response to denial of service" --Sandy Murphy