Re: ACTION-278 Hiding metadata for security reasons

Hi Noah,

On Jan 18, 2010, at 10:21 PM, noah_mendelsohn@us.ibm.com wrote:

> I've been giving this proposal some thought, and I'm not sure I buy the 
> premise.  In particular:
> 
>> In special circumstances where URIs are adequately protected 
>> for the application in question
> 
>> [...]
> 
>> 3. the URI is confined to secure data paths
> 
> Going down this path seems to divide the Web.  It suggests that there is 
> the wild and wooly main part of the Web, in which URIs wind up in all 
> sorts of places like logs, in memory in proxies, or in links get passed 
> around in emails, etc.  The above suggests that there are also other 
> Web-like networks, built of the same technology, but much more private. 

URIs are used to identify things. In some cases, it's OK if URIs end up in logs and so on, and in other cases URIs should be shared between just two parties. I don't think that negatively affects the quality of the whole network. 

The point of keeping URIs private is to allow the creator, and recipient of such a URI to be the only entities which can choose to share that URI.  But, of course, they can still share the URI. But, if you can:

a) Incentivize the creator and recipient of such a URI to keep it private under all conditions other than those actually intended for sharing (for example, I wouldn't share my credit-card number because someone else could then buy things with my money -- but I would share that number with my wife, since we already share our money, and thus she too will not share my cc number with anyone else -- unless she no longer likes me ;)
b) Ensure that unintentional sharing is not possible, by protecting these URIs in ordinary usage (for example, attempt to ensure they don't appear in the Referer header, and transport them over SSL/TLS)   

...such sharing can be painless.

> The suggestion is that there are little private Webs in which it is 
> possible to bound the places where a particular URI may wind up.  I think 
> this is what you mean by URIs that are "adequately protected for the 
> application in question."
> 
> No doubt, it is possible to use technologies such as URIs and HTTPs to 
> implement such protected networks.  Trivially, I could set up a one-hop 
> network with air-gap isolation from all other networks, control both ends 
> and run HTTP over that.  I don't think that the result is "the Web", the 
> architecture of which the TAG attempts to describe.  It's a network in 
> which linking is discouraged rather than encouraged.

I think the point is more that not only linking is encouraged (under the correct circumstances) but that when such links are shared, they give the same results for the entity with which the URI is shared as they do for the entity doing the sharing. If I share my credit-card purchase URI with you, you get to use the same money I do. 

Isn't the Web supposed to work this way?

> 
> In short, I'm tempted to stay away from the notion of protecting URIs.  It 
> was certainly my premise as editor of the original metadata in URI finding 
> that URIs were presumed to be unprotected.  I.e., it was assumed that in 
> normal use on the Web, any URI may well be discovered by users or software 
> not controlled by or associated with some particular application or 
> security domain.  Furthermore, it's assumed that malicious software, and 
> perhaps even just creative Web spiders, can synthesize and attempt to 
> access URIs that are similar, but not identical to ones that are 
> encountered in other Web traffic.  I'm so far unconvinced to change the 
> finding.

I think it would be very worthwhile to explain that URIs could be used this way, and in such cases, entities which use such URIs should be aware of the issues with doing so:

i) Referer HTTP header usage
ii) Use of TLS, or equivalents in acquiring such URIs 
iii) When creating such URIs, the scope of their usage should be as limited as possible (use more URIs but make them do less) 
iv) Other potential pitfalls of such usage

I think it's worth noting that such URIs are in widespread usage already on the Web today - Craigslist, Second Life and any organization which confirms account creation by sending a confirmation URI would all be cases where such considerations might apply. 

Regards,

- johnk

> 
> Maybe I need to understand the Google calendar case a bit better than I 
> do. 
> 
> Noah
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> Jonathan Rees <jar@creativecommons.org>
> Sent by: www-tag-request@w3.org
> 12/27/2009 11:46 AM
> 
>        To:     www-tag@w3.org
>        cc:     Tyler Close <tyler.close@gmail.com>, "Mark S. Miller" 
> <erights@google.com>, (bcc: Noah Mendelsohn/Cambridge/IBM)
>        Subject:        ACTION-278 Hiding metadata for security reasons
> 
> 
> Regarding ACTION-278, here is preliminary draft text to add to the end
> of section
> 2.7 "Hiding metadata for security reasons" of TAG finding "The use of
> Metadata in URIs" [2]
> 
> Criticism welcome; I'm expecting I'll have to substantially revise in
> the face of
> the wisdom to be precipitated.
> 
> <snip>
> 
> In special circumstances where URIs are adequately protected for the
> application in question, it may be safe to create URIs that carry
> sensitive metadata.  Most risks associated with metadata payloads are
> avoided when the following rules are respected:
> 1. the URI conveys only specific, limited knowledge or authority
> 2. the URI protects the information it carries by a level of
>   obfuscation such as encryption and/or indirection via a random key
> 3. the URI is confined to secure data paths
> 4. the URI is restricted to a single use and/or is valid only during a 
> limited
>   lifetime
> 
> For example, a calendar system may provide an option to share a
> calendar with another user.  The access right may be designated by a
> unguessable URI that can be sent to the other user, who on applying it
> obtains read access in a coordinating mail application to the first
> user's mailbox.
> 
> Adequacy of data path security is difficult to assess and great care
> should be exercised in using this pattern.  The calendar case works
> because the URI in question has special use contexts (it is not likely
> that is will be used for general browsing or bookmarking), it conveys
> limited authority (read access to one calendar, not login access to an
> email account), email and HTTP connections are assumed to be
> sufficiently private, and the providing and consuming applications
> both take steps to minimize disclosure risks.
> 
> </snip>
> 
> Best
> Jonathan
> 
> [1] http://www.w3.org/2001/tag/group/track/actions/278
> [2] http://www.w3.org/2001/tag/doc/metaDataInURI-31#hideforsecurity
> 
> 
> 
>

Received on Tuesday, 19 January 2010 14:28:54 UTC