Action-278

Excerpts from email, minutes, and other sources, chosen somewhat arbitrarily, and collected into one place.

The original discussion

NM: so, advice in 2.7 of Metadata in URIs is still good advice?
JAR/DC: no, Tyler et al say this is bad advice!
LMM: advice is good for some situations, bad for others
TBL: appropriate to say that there are two patterns of use - 1) ACL is
  done orthogonally to URI metadata (metadata MAY be public)
  ... and another, where URI must be completely secret
HT: you are fooling yourself if you think URIs won't get out into the wild
([scribe] missed TBL third case) - secret information in URI, as noted
   in 2.7 of metadata in URI spec.
TBL: (describes tripIt 'send to' case)
NM: there is a story about if I use HTTP, then URIs will appear in several places
... and with HTTPS, fewer places
TBL: re-open the metadata in URLs finding, explain capability use-case 

2.7 Hiding metadata for security reasons

A bank establishes a URI assignment policy in which account numbers are encoded directly in the URI. For example, the URI http://example.org/customeraccounts/456123 accesses information for account number 456123. A malicious worker at an Internet Service Provider notices these URIs in his traffic logs, and determines the bank account numbers for his Internet customers. Furthermore, if access controls are not properly in place, he might be able to guess the URIs for other accounts, and to attempt to access them.

Good Practice: URI assignment authorities SHOULD NOT put into URIs metadata that is to be kept confidential.

Use cases:
  Google calendar
    http://lists.w3.org/Archives/Public/www-tag/2010Jan/0089.html
  Unsubscribe - Dan finds the email aspect confounding
    http://lists.w3.org/Archives/Public/www-tag/2010Feb/0051.html
    also see re Google policy
      http://mail.google.com/support/bin/answer.py?hl=en&answer=81126#unsub
  Google docs
    http://lists.w3.org/Archives/Public/www-tag/2010Jan/0087.html
  CSRF defense
    http://waterken.sourceforge.net/web-key/#cap_xsrf
  Tripit
  Doodle
  Webex readycast "join meeting now"
  ...

URI communication ("leak") paths that have been mentioned:
  Bookmark lists
  Browser history
  Server history (logs)
  Sniffing
  Referrer header
  Phishing detection services
  Copy/paste (e.g. to email)
  delicious.com bookmarklet  (deliberate action)

"One pattern is using unguessable URIs as a resource identifier for a temporary-validity 'resource' which really acts as a capability to perform some action -- access a document or calendar entry, unsubscribe from a mailing list or some such. When used with time-limits and other protection mechanisms intended to slow or minimize the possibilities of accidental disclosure, unguessable URIs may be useful in situations where requirements for confidentiality aren't high."

-- LMM

"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?"

-- John K

"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

"Good Practice: A URI assignment authority SHOULD NOT put guessable, confidential metadata in a URI."

"Good Practice: A URI assignment authority SHOULD only identify private resources with unguessable URIs."

-- Tyler

Note that nowhere does my draft text require that an unguessable URL alone be sufficient to grant access to a resource. It only says that private resources SHOULD use unguessable URLs. It doesn't say that you can't use additional security measures.

-- Tyler

From Minutes of 11/2 teleconference:

<masinter> suggested ACTION: ask thomas & web-security group to take this up
...
<DanC> NoahM, the 2nd GPN in your proposal looks pretty similar to the
2nd GPN in what tyler wrote; I don't see a clear distinction. As far
as I have read so far, they're both OK by me...
...
<masinter> I think the security considerations need to combine the
risk of disclosure with the consequences of inadvertent disclosure and
how the risks of inadvertent disclosure are mitigated. Such as:
unsubscribe link requires explicit POST, results in a confirmation
email being sent and [can be] undone, is only valid for a limited time
and only one-time.