Re: [secdir] review of draft-nottingham-site-meta-04

Mark Nottingham <> Thu, 03 December 2009 05:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A85F3A68AA; Wed, 2 Dec 2009 21:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.185
X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[AWL=-1.586, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CFniCijyLTdL; Wed, 2 Dec 2009 21:49:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4972D3A6961; Wed, 2 Dec 2009 21:49:18 -0800 (PST)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4C35022E1F3; Thu, 3 Dec 2009 00:49:00 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham <>
In-Reply-To: <>
Date: Thu, 3 Dec 2009 16:48:57 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Sandra Murphy <>
X-Mailer: Apple Mail (2.1077)
Subject: Re: [secdir] review of draft-nottingham-site-meta-04
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Dec 2009 05:49:55 -0000

Hi Sandra,

Responses inline. 

On 02/12/2009, at 12:41 PM, Sandra Murphy wrote:
>   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.

Not quite. It's basically saying that, given a particular application context using arbitrary network resources, it's up to you to determine what the appropriate URI authority (e.g., '' in '') should be.

> 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 agree; DNS rebinding was brought up as a concern during review, but AIUI it's more of a concern for applications using well-known locations, if they choose to try to address that problem. It may be that they just pass a warning upstream to their implementers/users.

> 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.

I think that's a good suggestion. 

> 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?

The designated expert.

Cheers and thanks for the review,

Mark Nottingham