Re: exposing sensitive information in URIs - LC comments on draft-nottingham-http-link-header-07.txt

Mark Nottingham <mnot@mnot.net> Fri, 29 January 2010 04:31 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B553A68B6 for <ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com>; Thu, 28 Jan 2010 20:31:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.783
X-Spam-Level:
X-Spam-Status: No, score=-7.783 tagged_above=-999 required=5 tests=[AWL=2.816, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 7WaI7yGUu1KE for <ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com>; Thu, 28 Jan 2010 20:31:14 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 593DF3A687E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 28 Jan 2010 20:31:14 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1NaiW0-0001Ja-Tw for ietf-http-wg-dist@listhub.w3.org; Fri, 29 Jan 2010 04:31:28 +0000
Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <mnot@mnot.net>) id 1NaiVu-0001FZ-Tl for ietf-http-wg@listhub.w3.org; Fri, 29 Jan 2010 04:31:22 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from <mnot@mnot.net>) id 1NaiVt-00030h-AE for ietf-http-wg@w3.org; Fri, 29 Jan 2010 04:31:22 +0000
Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0A9FC22E1EB; Thu, 28 Jan 2010 23:30:53 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <4B586349.5050405@gmx.de>
Date: Fri, 29 Jan 2010 15:30:51 +1100
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD5F57CA-C457-46A5-8098-019FB9B09FCB@mnot.net>
References: <20100119053002.5CD613A683B@core3.amsl.com> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de> <4B586349.5050405@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1077)
Received-SPF: pass
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_HELO_PASS=-0.001
X-W3C-Scan-Sig: bart.w3.org 1NaiVt-00030h-AE ef2a780d1827573c4956417057ce285f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: exposing sensitive information in URIs - LC comments on draft-nottingham-http-link-header-07.txt
Archived-At: <http://www.w3.org/mid/AD5F57CA-C457-46A5-8098-019FB9B09FCB@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/8273
X-Loop: ietf-http-wg@w3.org
Sender: ietf-http-wg-request@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1NaiW0-0001Ja-Tw@frink.w3.org>
Resent-Date: Fri, 29 Jan 2010 04:31:28 +0000

I sincerely don't believe that adding any such text to the Link draft (or the URI specification, which is where this really belongs) will make the world any more secure of a place. 

However, I'll be happy to have that discussion with Eric *if* he brings it up.

Cheers,


On 22/01/2010, at 1:23 AM, Julian Reschke wrote:

> Hi,
> 
> finally a security related comment.
> 
> During IETF LC for draft-brown-versioning-link-relations we got a comment from Eric Rescorla:
> 
> "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."
> 
> I assume this is a concern that applies to the Link header in general.
> 
> Best regards, Julian
> 
> 


--
Mark Nottingham     http://www.mnot.net/