Subject: [dix] More requirements

From: "Ben Laurie" <[email-masked]>
Date: Thu, 13 Jul 2006 20:43:14 -0400

On the plane to IETF I realised that there were several more potential
requirements to add to ekr's list:

12. Single Site Unlinkability (SSU)
The user should be able to visit the same site multiple times without
the site being able to tell that it is the same user, even if the user
is, for example, asserting the same external claims each time. This
protects the user's privacy. Obviously if data provided by the user is
unique to that user (for example, age and address combined are often
sufficient to uniquely identify a person) then no amount of cleverness
can provide SSU, but SSU should be available to the extent permitted
by the uniqueness of the data provided.

13. Multiple Site Unlinkability (MSU)
The user should be able to visit multiple sites without the sites
being able to collude to correlate the data provided by the user. This
is a weaker requirement than SSU (that is, MSU does not guarantee
SSU). Again, this protects the user's privacy.

14. Attack Resistant Credentials (ARC)
Credentials should be such that the (computationally limited) verifier
cannot reconstruct the original credential by brute force. Note that
the impossibility of this may rely on the user choosing strong
secrets, which is often unlikely, for example where the sole source of
entropy is a password.

15. Claim Minimality (CM)
The ability to show only exactly what is needed, (for example, the
user is over 21 rather than the user's exact age, or if there are
mutlple claims the ability to show a subset). This improves privacy
and reduces linkability.

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: EKR <[email-masked]>
Date: Fri, 14 Jul 2006 05:03:26 -0700

> by the uniqueness of the data provided.

This is an interesting requirement and obviously of value, but
it's worth noting that there are contexts in which linkability
(CI) is precisely what's desired--blog comments, for example.

So, you wouldn't want to design a system that always provided
SSU. :)

> mutlple claims the ability to show a subset). This improves privacy

Note that this ties in with IAC.

-Ekr

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 14 Jul 2006 08:38:55 -0400 (EDT)

> So, you wouldn't want to design a system that always provided SSU. :)

I think many of the requirements (no, haven't made a list yet) have the 
assumption of "when appropriate", or "when desired", where "desired" is 
some combination of what the user wants and what the application wants or 
will permit.

  - RL "Bob"

---

From: "Ben Laurie" <[email-masked]>
Date: Fri, 14 Jul 2006 08:39:54 -0400

> some combination of what the user wants and what the application wants or

Yeah, I see the list as being a list of things you might want, at this
stage. Presumably at some point we have to choose which things we
actually want, and which are optional or not-always-used.

---

From: Jeff Hodges <[email-masked]>
Date: Fri, 14 Jul 2006 06:30:03 -0700

RL 'Bob' Morgan wrote:
 > some combination of what the user wants and what the application wants
 > or will permit.

Indeed, many of these are distinct "security properties". Note in the intro to 
his note, ekr termed the content of his note as:

   "a taxonomy of requirements/features and technical options"

JeffH

---

From: "Ben Laurie" <[email-masked]>
Date: Fri, 14 Jul 2006 08:38:18 -0400

> So, you wouldn't want to design a system that always provided

Totally agreed.

> Note that this ties in with IAC.

Right - the distinction is that rather than merely separating claims
you want to be able to prove properties of claims instead of revealing
their actual content.

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 14 Jul 2006 09:51:11 -0400 (EDT)

> Indeed, many of these are distinct "security properties". Note in the intro 
> to his note, ekr termed the content of his note as:
>

Right, a problem we often have with stating requirements is 
differentiating between "X is required to be possible/negotiable" and "X 
is required to always be done"; where the first of these produces 
derivative requirements about the nature of the negotiation of and/or 
policy around the feature.

  - RL "Bob"

---

From: "Ben Laurie" <[email-masked]>
Date: Sat, 15 Jul 2006 10:05:40 -0400

On 7/15/06, Paul Gleichauf <[email-masked]> wrote:
> I have missed significant parts of this thread, but is there
> assurance that these are in fact computationally feasible?
>
> There are cases where such guarantees are often found possible to
> break in unanticipated ways. Recently the focus is on medical records
> and the ability to identify a specific person in a large population
> when an anonymization algorithm had been appropriately applied by
> correlating data from a variety of sources.  Below is one set of
> citations often cross referenced in this area:
>
> http://lab.privacy.cs.cmu.edu/people/sweeney/confidentiality.html

I explicitly stated that these kinds of attacks were out of scope. I'm
talking about the avoidable kind of linkage, for example where you
present the same X.509 client cert everywhere.

>
> Paul
>
> On Jul 13, 2006, at 5:43 PM, Ben Laurie wrote:
>