Hi Murray,
At 10:36 AM 8/5/2013, Murray S. Kucherawy wrote:
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?
Yes.
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?
It's difficult to understand what RDAP is as it is not clearly
defined. That is what I meant by "ill-defined". In the above
example, the "SHOULD" does not specify anything. It looks like a
"forward-looking statement" as the "future authentication methods" are unknown.
I would look at the specification in terms of what is required to
achieve interoperability now instead of trying to define future
needs. In terms of protocol it would be what the two sides have to
do to talk to each other. One of the issues in MILE what that there
wasn't a clear separation of the HTTP aspect and the MILE aspect. In
simple terms it is better not to redefine how HTTP works; i.e. a 404
is a 404 instead of a contextual meaning of that code.
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).
The draft is intended as a proposed standard. In my opinion that is
different from a requirements document. The usage of SHOULD does
not make it implementable. It is like using SHOULD to beat people up
if they do not implement some future capability. :-)
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.
I mean that the draft does not contain any security feature which is
mandatory to implement.
Right, and the benefits it provides in the context of RDAP. Is that
a criticism or an observation? What do you suggest?
I don't think that the executive summary provides much value. I
suggest dropping the tutorial material. :-)
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.
Ok.
It is a web service, in as much as it uses web protocols. Is there
some improvement you'd like to suggest?
The approach taken can create interoperability issues. I would look
at this in terms of what the codes has to do.
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.
This draft looks like a tutorial for the not-well-informed.
:-) There is likely some BCP which already discusses about non-repudiation.
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?
I would use that as the starting point and then discuss attacks which
are specific to the service.
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?
It would be better to point to the relevant sections if the objective
is to help the reader identify relevant issues.
That seems a little sharp.
The comments were strong. :-(
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 personally think that there is a lack of understanding of what an
applicability statement is. I commented on the draft from a
technical specification angle.
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?
It is a lot of work to explain or suggest text. It's not worth
putting in the effort if the working group believes that the draft is okay.
Regards,
-sm
-MSK