Subject: Re: Last Call: <draft-ietf-weirds-rdap-sec-04.txt> (Security Services for the Registration Data Access Protocol) to Proposed Standard

From: SM <[email-masked]>
Date: Wed, 24 Jul 2013 12:21:24 -0700

At 16:06 15-07-2013, The IESG wrote:
>The IESG has received a request from the Web Extensible Internet
>Registration Data Service WG (weirds) to consider the following document:
>- 'Security Services for the Registration Data Access Protocol'
>   <draft-ietf-weirds-rdap-sec-04.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2013-07-29. Exceptionally, comments may be

According to Section 1, the Registration Data Access Protocol is a 
Lookup Format,
JSON Responses and HTTP usage.  This looks like a weird protocol to 
me.  If the said protocol is HTTP + JSON (responses) it would be 
clearer to the reader to explain that in one specification.  Section 
1 mentions that:

   "One goal of RDAP is to provide security services that do not exist in
    the WHOIS"

I don't see how adding a fourth document helps to achieve that goal.

In Section 3.1:

   'To that end, RDAP clients and servers MUST implement the
    authentication framework specified in "HTTP Authentication:
    Basic and Digest Access Authentication" [RFC2617].'

This draft refers to the above authentication framework as the RDAP 
authentication framework.  The draft then explains how the "basic" 
and "digest" schemes work.  This is "how-to" stuff.  The draft sets 
the following requirement:

   'If the "basic" scheme is used, HTTP Over TLS [RFC2818] MUST be used
    to protect the client's credentials from disclosure while in transit
   (see Section 3.4).'

If I understood correctly HTTPS is needed for security only if the 
"basic" scheme" is used.

   "RDAP SHOULD be capable of supporting future authentication methods
    defined for use with HTTP."

That sounds like a "SHOULD CONSIDER".  Given how ill-defined the 
protocol is I doubt that the above is actionable.

In Section 3.1.1:

   "RDAP MAY include a federated authentication mechanism that permits
    a client to access multiple RDAP servers in the same federation
    with one credential."

Using an upper-case "may" does not bring much in terms of 
security.  The draft takes the stance that security is an optional feature.

Section 3.1.1 looks like an executive summary for federated authentication.

In Section 3.3:

   "An RDAP service has to be available to be useful.  There are no RDAP-
    unique requirements to provide availability, but as a general
    security consideration a service operator needs to be aware of the
    issues associated with denial of service."

The text says that the service must be available to be useful and 
that there isn't any requirement for the service to be available.

In Section 3.4:

   "Web services such as RDAP commonly use HTTP Over TLS [RFC2818] to
    provide that protection by encrypting all traffic sent on the
    connection between client and server."

The above describes the protocol as a web service.

   "When this scheme is used, HTTP Over TLS MUST be used to protect the
    client's credentials from disclosure while in transit.'

The above repeats a "MUST" mentioned in a previous section.

In Section 5:

   "RDAP might need to be extended to provide this service in the future."

This does not look like a security consideration.

   "Code injection refers to adding code into a computer system
    or program to alter the course of execution."

I can only wonder about who is the target audience after reading the above.

The security considerations section seems like an attempt to write 
something about security as there isn't nothing to say about the protocol.

Overall, the draft does not look like a technical specification.  It 
looks like the working group took FYI 36 as a template for designing 
a security service instead of thinking about security and designing a 
security service.

Regards,
-sm