Last Call Review of draft-ietf-weirds-using-http-07
review-ietf-weirds-using-http-07-secdir-lc-murphy-2013-08-16-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-weirds-using-http-07-secdir-lc-murphy-2013-08-16

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) <doessomeaction>".  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