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