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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]