Re: [secdir] Review of draft-brown-versioning-link-relations-05

Julian Reschke <julian.reschke@greenbytes.de> Wed, 06 January 2010 15:02 UTC

Return-Path: <julian.reschke@greenbytes.de>
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 169C03A6879; Wed, 6 Jan 2010 07:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 oDjnh5EpxS3b; Wed, 6 Jan 2010 07:02:25 -0800 (PST)
Received: from donbot.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by core3.amsl.com (Postfix) with ESMTP id 24E533A63C9; Wed, 6 Jan 2010 07:02:24 -0800 (PST)
Received: from [192.168.1.105] (unknown [192.168.1.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id 7E4F3C4CA6C; Wed, 6 Jan 2010 16:02:22 +0100 (CET)
Message-ID: <4B44A5F8.7010103@greenbytes.de>
Date: Wed, 06 Jan 2010 16:02:16 +0100
From: Julian Reschke <julian.reschke@greenbytes.de>
Organization: greenbytes GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <20100102230208.8346F6CB202@kilo.networkresonance.com> <4B40E063.7070605@greenbytes.de> <20100105165742.9DE066CBAC8@kilo.networkresonance.com>
In-Reply-To: <20100105165742.9DE066CBAC8@kilo.networkresonance.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: draft-brown-versioning-link-relations@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-brown-versioning-link-relations-05
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: Wed, 06 Jan 2010 15:02:26 -0000

Hi Eric,

for now I have added:

"Care should be applied when versioned resources are subject to 
differing access policies. In this case, exposing links may leak 
information even if the linked resource itself is properly secured. In 
particular, the syntax of the link URI/IRI could expose sensitive 
information (see Section 16.2 of [RFC3253] for a similar consideration 
in WebDAV Versioning). Note that this applies to exposing link metadata 
in general, not only to links related to versioning."

to the Secutiry Considerations 
(<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html#rfc.issue.expose-urls>).

Is this sufficient?

Lisa: please let me know whether (and when) to submit a new draft (I'll 
assume post LC end sometimes last week?).

Best regards, Julian


Eric Rescorla wrote:
> At Sun, 03 Jan 2010 19:22:27 +0100,
> Julian Reschke wrote:
>> Eric Rescorla wrote:
>>> This document describes a set of link relations which provide
>>> information about other versions of a versioned resource.
>>>
>>> In general this mechanism seems sound but I'm not sure that
>>> the security considerations are entirely adequate. This 
>>> mechanism lets you learn information about other versions
>>> of a resource even if you potentially don't have permission
>>> to view them directly. Consider a limiting case where each
>>> version of the resource had a name that contained the
>>> change set for that resource. E.g.,
>>>
>>> http://example.com/versions/filename/_@line_50_+_FOO;@line_60_+_BAR/;
>>>
>>> In this case, seeing other parts of the version tree leaks
>>> information about those versions. I don't think that this
>>> is a problem for the draft, but it might be useful to
>>> mention that this feature has implications for name 
>>> construction.
>> Yes, we can mention that.
>>
>> But, isn't this a general problem with exposing meta data in link 
>> relations? 
> 
> Yes, probably.
> 
> 
>> As such, shouldn't it have been mentioned in RFC 4287, and 
>> should it also be mentioned in draft-nottingham-http-link-header?
> 
> Probably... I just didn't read these. :) I only did this one as part
> of secdir review. 
> 
> -Ekr
> 


-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782