review of draft-nottingham-site-meta-04
Sandra Murphy <sandy <at> sparta.com>
2009-12-02 01:41:51 GMT
This is a review of draft-nottingham-site-meta-04
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
This draft defines a new registry for applications that wish to use a
well-known URI for some purpose, for example, a URI for a policy or
metadata that would be specific to each application site. A registry is
needed to prevent conflicts among the URIs defined or conflicts with other
resources.
I have no security concerns with the draft or the idea of a registry of
well-known URIs.
Comments:
Note that this specification defines neither how to determine the
authority to use for a particular context, nor the scope of the
metadata discovered by dereferencing the well-known URI; both should
be defined by the application itself.
I'm not sure what "authority to use for a particular context", but I
presume that it means that each application should consider the
authorization model of who should have the authority to use the well-known
URI at each host/site. This sounds lke a general security concern, but it
is not verbatim reflected in the security considerations section (the
scope part is mentioned, not the "authority to use".) Note: given that I
say below that it would be impossible to be complete in the security
concerns that might arise in any particular application, this is NOT a
recommendation that the text should change.
Security Considerations section
As this is a definition of a registry, there's not much to be said about
what the security considerations there might be.
The section notes two possible security concerns. No statement is made
about possible solutions to these security concerns.
The first is that access to the server might give an attacker the ability
to modify what is stored at the URI. Depending on the application and the
way the well-known URI is used, that could represent a security concern,
obviously. There's nothing to be said here about solutions, given that
the use is still to be defined.
The second possibility mentioned is DNS rebinding:
Because most URI schemes rely on DNS to resolve names, they are
vulnerable to "DNS rebinding" attacks, whereby a request can be
directed to a server under the control of an attacker.
My understanding is that DNS rebinding allows the attacker to rebind a
name it controls to a local address. So it is the directing to a server
that is under the control of the attacker, not the server itself. I'm not
sure that is what the text here is saying. DNS rebinding here would be a
concern if the well-known URI provided some access that would be useful to
an attacker. That would be a subject for the application to consider, so
I'm not saying that it needs to be mentioned here.
Recommendations for protection against DNS rebinding have to do with the
browser or the enterprise, not the application, so I don't think they need
to be mentioned here.
I could see that there might be other ways that the existence of a
well-known URI could be a concern, depending on how the application used
that file (DDOS if the use caused transmission, exposure if the use caused
access to sensitive data, whatever). But I don't think that this document
could possibly be complete in discussing all the security concerns these
unknown applications with their unknown uses of the URI could have.
In general, I think this section could be replaced with just guidelines
about what the specification of a new well-known URI should discuss or
consider. Consider the authorization model, consider corruption,
exposure, etc. of the URI file, consider vulnerability to DNS rebinding
attacks, etc.
IANA considerations section
The draft mentions several things that a specification of a new well-known
URI should discuss or include. Is the IANA resonsible for ensuring that a
specification for a new well-known URI meets the stipulations made here?
Or maybe the Designated Expert does that?
--Sandy
RSS Feed