Skip to main content

Last Call Review of draft-nottingham-site-meta-

Request Review of draft-nottingham-site-meta
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-12-15
Requested 2009-10-09
Authors Eran Hammer-Lahav , Mark Nottingham
I-D last updated 2009-12-03
Completed reviews Secdir Last Call review of -?? by Sandra L. Murphy
Assignment Reviewer Sandra L. Murphy
State Completed Snapshot
Review review-nottingham-site-meta-secdir-lc-murphy-2009-12-03
Completed 2009-12-03
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 


I have no security concerns with the draft or the idea of a registry of 

well-known URIs.


   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?