Hi SM, thanks for your comments. I'm shepherding the document, so replies
inline:
On Wed, Jul 24, 2013 at 12:21 PM, SM <sm(_at_)resistor(_dot_)net> wrote:
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.
RDAP is far from the first protocol specification to exist across multiple
RFCs, so this approach isn't uncommon. That said, I take it you believe
the material here should be rolled into one of the other documents?
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.
Correct, that's what it says.
"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.
You said two important things here:
1) Can you please elaborate on why you think this is "ill-defined" and, if
possible, how this could be remedied?
2) Insofar as this draft amounts to a requirements document, I take "SHOULD
be capable" to mean the actual implementation needs to have hooks for the
stated capability, or have a very good reason for not providing those hooks
(e.g., the same capability is available some other way).
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.
More precisely, the draft takes the stance that federated authentication is
an option. The working group doesn't feel the need to elevate this to
SHOULD or MUST, likely because operators might not be compelled to federate
themselves with anyone for whatever local security or privacy reasons apply.
Section 3.1.1 looks like an executive summary for federated authentication.
Right, and the benefits it provides in the context of RDAP. Is that a
criticism or an observation? What do you suggest?
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.
The next sentence (which you omitted) provides the context. Operators are
advised to be aware of denial-of-service considerations, and there's a
document referenced that provides useful information. Depending on the
uptake of RDAP and the other services that begin to depend upon it, it
might become a DoS target. Hardening against such attacks will be
important to begin with, but might become critical later. I think this is
not a waste of space.
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.
It is a web service, in as much as it uses web protocols. Is there some
improvement you'd like to suggest?
"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.
True, this can be fixed by replacing it with a reference to Section 3.1.
In Section 5:
"RDAP might need to be extended to provide this service in the future."
This does not look like a security consideration.
Non-repudiation (which is the context of the paragraph from which that
sentence was taken) is one of the classic properties of security, so I
don't agree. It's useful to point out to the reader that non-repudiation
is not provided by any of the capabilities discussed here, and its absence
might be conspicuous.
"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.
It's true that the specific things called out in that paragraph are not
specific to RDAP, but rather to anything built atop HTTP. Do you suggest
something else, perhaps something more general like a statement that any
known HTTP-based attack might also affect an RDAP service?
The security considerations section seems like an attempt to write
something about security as there isn't nothing to say about the protocol.
SecDir often scratches its head when a document says very little, so what
you're saying is often the case. However, sometimes it's enough to say
"This is built on top of HTTP, so all the security issues known about HTTP
and HTTPS also apply here." Do you have a specific suggestion?
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.
That seems a little sharp.
This draft is manifestly not a technical specification insofar as it does
not define a new protocol. I would say it's partly a requirements document
and partly an applicability statement, and the latter at least is normally
a standards track document.
I don't know what "thinking about security" we are expected to do beyond
making use of the security services that have already been made available
to applications built atop HTTP. Do you have any specific suggestions?
-MSK