Re: [secdir] review of draft-nottingham-site-meta-04
Sandra Murphy <sandy@sparta.com> Thu, 03 December 2009 06:28 UTC
Return-Path: <Sandra.Murphy@cobham.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F123A67F5; Wed, 2 Dec 2009 22:28:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNn5Qw9iOOFe; Wed, 2 Dec 2009 22:28:02 -0800 (PST)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 95A193A68CF; Wed, 2 Dec 2009 22:28:02 -0800 (PST)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nB36RnBX027281; Thu, 3 Dec 2009 00:27:51 -0600
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nB36Rlki025044; Thu, 3 Dec 2009 00:27:47 -0600
Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 01:27:46 -0500
Date: Thu, 03 Dec 2009 01:27:41 -0500
From: Sandra Murphy <sandy@sparta.com>
To: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <B7B2FD7A-2FD8-4915-9C1A-7A0A3CD39110@mnot.net>
Message-ID: <Pine.WNT.4.64.0912030126310.2532@SANDYM-LT.columbia.ads.sparta.com>
References: <Pine.WNT.4.64.0912012020580.6176@SANDYM-LT.columbia.ads.sparta.com> <B7B2FD7A-2FD8-4915-9C1A-7A0A3CD39110@mnot.net>
X-X-Sender: sandy@nemo.columbia.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 03 Dec 2009 06:27:46.0806 (UTC) FILETIME=[BA8C1960:01CA73E1]
Cc: apps-discuss@ietf.org, eran@hueniverse.com, secdir@ietf.org
Subject: Re: [secdir] review of draft-nottingham-site-meta-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2009 06:28:04 -0000
On Thu, 3 Dec 2009, Mark Nottingham wrote: > 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., 'example.com' in 'http://www.example.com/.well-known/foo') should be. Ooops, yes, sorry. I forgot when reading that that there is a special meaning for "authority" in this context. > >> 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 http://www.mnot.net/ > >
- [secdir] review of draft-nottingham-site-meta-04 Sandra Murphy
- Re: [secdir] review of draft-nottingham-site-meta… Mark Nottingham
- Re: [secdir] review of draft-nottingham-site-meta… Sandra Murphy