Last Call Review of draft-nottingham-site-meta-
review-nottingham-site-meta-secdir-lc-murphy-2009-12-03-00

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