Re: ACTION-278 Hiding metadata for security reasons

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.
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 Sunday, 7 February 2010 22:51:15 UTC