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 Sunday, 7 February 2010 17:31:38 UTC