RE: ACTION-278 Hiding metadata for security reasons

I wrote:

> This is almost exactly the note I wanted to write as I was 
> reading through 
> this thread. 

I hope it's clear that what I meant was:  ">your note< is almost exactly 
what I wanted to write".  Thank you.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Noah Mendelsohn
02/08/2010 03:07 PM

        To:     Larry Masinter <masinter@adobe.com>
        cc:     "Mark S. Miller" <erights@google.com>, Jonathan Rees 
<jar@creativecommons.org>, Tyler Close <tyler.close@gmail.com>, 
"www-tag@w3.org" <www-tag@w3.org>
        Subject:        RE: ACTION-278 Hiding metadata for security 
reasons


Larry,

This is almost exactly the note I wanted to write as I was reading through 

this thread. 

> Can we agree that "confidential" really covers a large
> space of actual requirements for confidentiality?

Yes, and I agree with your implication that we haven't been sufficiently 
careful in characterizing the cases of interest here.

> 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, ...

Yes, but I think there's another dimension or axis we need to be careful 
about.  I think that the creation of unguessable URIs is done for at least 

two main reasons:

I. To avoid revealing some particular details about the resource.  If, for 

example, an airline puts my name and flight number in clear text in a URI 
query string, then anyone who gets hold of the URI knows that I'm on that 
flight.  By creating a secure hash and putting that in the URI instead, 
the airline can still mint a unique URI for each passenger on each flight, 

but the name and flight number aren't revealed.  I believe that 
unguessable URIs are an excellent technique for this purpose.  Crucially, 
there is no implication of access control.  Anyone who gets hold of this 
URI and tries to reference it will still (I posit) be told that they 
aren't allowed to see information about the resource.  That is, I'm 
assuming that access control must be provided by some other means if 
desired.  In these scenarios, there's no need to protect or limit 
distribution of the URI itself.

II. (webkey-style) Situations in which knowledge of the URI would allow 
one to access or manipulate the resource.  In these scenarios, those 
involved believe that they can limit >distribution< of each particular URI 

so that, with high probably, only those who can be sufficiently trusted 
will find it.  In these cases, making the URI unguessable is done 
primarily to avoid the possibility that someone could infer a URI based on 

publicly available information.  That is, we don't want you to be able to 
cancel my magazine subscription just because you:  knew my name, knew the 
name of the magazine, inferred the cancellation URI, and used it to 
cancel.

I think we need to carefully distinguish these cases.  #1 is just fine, 
IMO, and it's good reputation sometimes contributes to people saying "but 
unguessable URIs are widely used."  I believe that II. is really the case 
we're discussing here.  Regarding that:

Larry Masinter writes:

> [Ashok Malhotra writes:]
>
>> 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.

> Not too bad, but I'm not sure "non-public" captures the sense.
> Whether something is or isn't "public" depends on whether
> it has been disclosed publically, and so whether URIs are 
> 'public' depend on where you are in the life cycle. 
> "unguessable URIs" for me captures the spirit more:

I agree: this is the right general direction, but I agree that 
"non-public" is shorthand for too many subtlties. What I think we're 
trying to say is closer to (this is too wordy, but I want to get the 
nuances...if it's otherwise right, we can try to make it tighter):

"For the most part, the Web imposes no restrictions on the copying, 
logging, transcription, or redistribution of URIs.  Such copying or 
redistribution may occur using the mechanisms of the Web itself (e.g. via 
HTTP), or through other means (URIs may be emailed, may be stored and 
retrieved from system logs, etc.) Nonetheless, there are may be particular 

circumstances in which the distribution of a URI is in fact limited, e.g. 
because the URI has been mailed to some particular user using an email 
system that is believed to be suitably secure for the purpose.  In such 
cases, the value gained from using a URI as a capability mechanism, in 
which knowledge of a the URI is sufficient for access to or manipulation 
of protected information, may exceed the risks of inadvertent disclosure 
of the URI.  Such use is acceptable.  To avoid the risk that malicious 
parties could infer the URI(s) for some such resource(s), the mapping from 

publicly available information (resource metadata?) to the URI itself 
should be secret."

Good practice: use explicit security mechanisms to control access to Web 
resources, except when the risk that URIs will (leak? fall into the wrong 
hands?) is sufficiently low

Good practice: for resources that are not sufficiently protected by 
explicit security mechanisms, use URI's that cannot be inferred from 
publicly(?) available information.

Noah







--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Larry Masinter <masinter@adobe.com>
Sent by: www-tag-request@w3.org
02/07/2010 12:30 PM
 
        To:     Jonathan Rees <jar@creativecommons.org>, Tyler Close 
<tyler.close@gmail.com>
        cc:     "www-tag@w3.org" <www-tag@w3.org>, "Mark S. Miller" 
<erights@google.com>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: ACTION-278 Hiding metadata for security 
reasons


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 22:28:14 UTC