Re: ACTION-278 Hiding metadata for security reasons

Hello,

On Feb 7, 2010, at 5:50 PM, ashok malhotra wrote:

> Hi Larry:
> This is useful.
> Non-public URIs provide a weak level of security that is held to be adequate for some usecases.
> I wonder if there is disagreement with the above statement.

Personally, I feel as if we're looking at this from the wrong direction.

URIs are supposed to be easily shareable, and should point to the same resource regardless of who is viewing them - I believe these to be essential parts of Web architecture. 

If additional information (cookies, passwords and so on) are necessary in order for someone else to see the same information I see when I click on a link, then a URI is less-easily shareable than if I can assume that the person receiving this URI sees the same thing I do. 

Resource owners, and users (people) make decisions about who to share URIs with all the time. 

For example, a resource owner decides to share a URI with a user by including it in a representation returned to that user's user-agent. 

A person shares a URI by pasting it into an email and sending it to his friend.

The resource owner and the user should be able to share a URI shared between them, as much or as little as they each see fit. These are, very naturally, their own decisions. 

However, if the URI points to a resource that is, for example, personal for a user (my calendar) then the user may not wish for URIs pointing to that resource to be widely known. Password-protecting the page (calendar) however, makes it difficult for the user to share the URI with anyone (including his own family). 

Using a URI with an unguessable number in it resolves this issue. I can give the calendar link to my family, and no-one else can guess the URI. So only the resource owner and a small number of people need be able to access this resource. 

There are some challenges here though:

i) The URI may be "accidentally" revealed because it ends up in a Referer HTTP header sent to another site.
ii) The URI is passed over a non-confidential transport and is sniffed by an MITM
iii) The URI ends up in logs that get shipped to places unexpectedly
iv) The URI is guessable

... and so on.

These are, as Larry is suggesting, security considerations about the use of URIs, and security considerations which address some common use-cases. 

My reading of:

>>> Good Practice: URI assignment authorities SHOULD identify a
>>> confidential resource using an unguessable URI.

Is that if one wishes to limit the audience for a resource identified by a URI, then the resource owner SHOULD make the URI which points to the resource "unguessable". By doing so, one limits the audience for that resource to those who have the URI in hand. 

I think we should start with the assumption that URIs should be easily shareable by the resource owner and user (but not always by others). The intended audience for the resource may vary widely. What are the methods one might use to limit the audience for a resource to that decided by the resource owner and the recipient user of that URI? How might we ensure that the security tradeoffs are made consciously and properly? 

Regards,

- johnk

> All the best, Ashok
> 
> 
> Larry Masinter wrote:
>> As I said in the TAG meeting, I think we might be able
>> to resolve this by trying to be more precise about what
>> is meant by "confidential". 
>> Let's look at this from a threat analysis point of view
>> first, and then come up with "good practices" second.
>> 
>> Can we agree that "confidential" really covers a large
>> space of actual requirements for confidentiality?
>> Some information is intended to be confidential forever,
>> some information has only transient benefit, in some
>> circumstances the risk of unintended disclosure is
>> drastic, and in others it is a minor inconvenience,
>> and the amount of damage that can be incurred by
>> accidental disclosure is limited, and the damaging
>> act done with sufficient auditing and confirmation
>> that in can be undone. In some cases, the use of
>> unintended disclosure can be detected and future
>> abuse corrected, and in others there is no auditing.
>> 
>> Secondly, the disclosure risk of including information
>> intended to be "confidential" "in URIs" varies significantly, depending also on circumstances:
>> whether or not it is an "http:" URI or an "https:"
>> URI, or a "data:" URI, for example, and whether
>> or not the information is in the fragment identifier,
>> for example.
>> 
>> In the case of "mailing list subscription",
>> the harm that can be caused by a discovery of
>> a "unsubscribe" capability is pretty limited.
>> The email address being unsubscribed is notified
>> of the unsubscription, so the act itself is
>> undoable. Most usually, this notification also
>> contains information about how to re-subscribe
>> and sometimes even recovery information of whom
>> to contact if the unsubscription was unintended,
>> presumably to allow auditing and tracking, for
>> example, of the IP-address used to do the unsubscribe.
>> 
>> In general, though, I would oppose changing the
>> "good practice" document along the lines that
>> Jonathan indicated:
>> 
>> 
>> 
>>> Good Practice: URI assignment authorities SHOULD identify a
>>> confidential resource using an unguessable URI.
>>> 
>> 
>> 
>> for example, because "a confidential resource" is much
>> to general, and the cases where using an "unguessable URI"
>> is actually "good" practice limited.
>> 
>> It may be a stylistic problem that the W3C TAG
>> findings on security seem to focus on giving
>> pragmatic rules-of-thumb ("Good Practice") rather
>> than what is the norm in the security industry of
>> saying that "Good Practice" for any system design
>> is to do a threat analysis ("If I do X, what threats
>> does this expose users to, and how do I mitigate
>> those threats"), and then give some of the considerations
>> to be taken into account doing such a threat analysis.
>> 
>> I recommend the TAG adapt or profile:
>> 
>> http://tools.ietf.org/html/rfc3552
>> "Guidelines for Writing RFC Text on Security Considerations"
>> 
>> for use in TAG findings and other W3C publications.
>> 
>> Larry
>> --
>> http://larry.masinter.net
>> 
>> 
>> -----Original Message-----
>> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of Jonathan Rees
>> Sent: Sunday, February 07, 2010 9:00 AM
>> To: Tyler Close
>> Cc: www-tag@w3.org; Mark S. Miller
>> Subject: Re: ACTION-278 Hiding metadata for security reasons
>> 
>> On Sun, Dec 27, 2009 at 2:20 PM, Tyler Close <tyler.close@gmail.com> wrote:
>> ...
>> 
>>> I think the current section 2.7 should be split into two new sections
>>> that correctly address the concerns raised in the current body text.
>>> The first would motivate:
>>> 
>>> Good Practice: URI assignment authorities SHOULD NOT put confidential
>>> metadata in a URI whose protocol does not support confidentiality.
>>> 
>>> The second section would motivate:
>>> 
>>> Good Practice: URI assignment authorities SHOULD identify a
>>> confidential resource using a URI whose protocol provides
>>> confidentiality.
>>> 
>>> Good Practice: URI assignment authorities SHOULD identify a
>>> confidential resource using an unguessable URI.
>>> 
>>> I am happy to provide body text for these two new sections.
>>> 
>> 
>> I would be interested in seeing this, and hope it meets with better success
>> than my version.
>> 
>> 
>>> I don't like Jonathan's proposed replacement text, since my impression
>>> is that it only begrudgingly condones the use of unguessable URIs;
>>> whereas I think the TAG should be enthusiastic supporters of them.
>>> 
>> 
>> My approach was tactical, attempting to anticipate the objections that
>> Noah and others would have. My goal was only to draft advice that
>> (unlike the finding) is not at variance with current common practice.
>> I'm certainly not opposed to having URIs used for access control more
>> generally than they are now, but that is a different ambition.
>> 
>> 
>

Received on Monday, 8 February 2010 14:22:23 UTC