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