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
ietf@ietf.org 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