Subject: RE: [Simple] <except-domain> element issue for common policy

From: [email-masked]
Date: Thu, 16 Jun 2005 17:33:49 +0300

Hi Ted,

I don't still get your point why this type of exceptions within a particular rule/directive would be against the additive model of permissions. I think you would still get the same results whichever way you evaluate the permissions, and you would never reveal more if a permission is lost - which seem to be the two main points of additive permissions.

In fact, the separate post-processing after the authorization decision has been already done, is much more contradictory to the model, since then you may be enforcing exceptions that are "global", and if that part of the process fails, you may end up revealing more information. As Jonathan was asking, I see little difference in having a rule in common policy saying "deny this guy" (which is clealy wrong in terms of the additiveness principle) and having a separate facility saying "if this guy gets through the auth policy, deny him".

The point about identity/domain minting is valid, however. It is clear that you will not get perfect protection with identity or domain exceptions, because of the reasons you explain. My view of the situation is still a bit different than yours for the following reasons:
1. If someone is concerned about identity minting, they can decide NOT to use the exceptions.
   This decision can be done at many levels: service provider can ban them, client vendor can band them, UI designer can ban them, the user can decide not to use them. The main point: I do *NOT* think that in this case it is the IETF's business to do this decision! In fact, I'm afraind that it IETF does this, other organizations and vendors are forced to hack around this with the loss of interoperability, since as far as I know, some sort of black-listing capability is a clear must from user expectation point of view.
2. There are many many cases where users would not need to care about identity minting. For instance, if I want to block my mother for a while, I can be pretty sure she won't go about minting another identity to get the access.

Regards,
	Markus   

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Ted Hardie
> Sent: 07 June, 2005 20:21
> To: Jonathan Rosenberg
> Cc: Paul Kyzivat; Niemi Aki (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [Simple] <except-domain> element issue for common policy
> 
> 
> Hi Jonathan,
> 
> For some bizarre reason, both copies of this just now turned 
> up in my mail box;
> I apologize for the long delay in replying.  If there are 
> other messages you
> have out to me for which you're expecting a reply, please re-send.
> 
> At 12:13 PM -0400 5/25/05, Jonathan Rosenberg wrote:
> >A question inline.
> >
> >Ted Hardie wrote:
> >
> >>that the automation of the disposition decision does the 
> same job; I can
> >>set up a process (note, not a *rule*) that moves things out 
> of (pending) on
> >>my behalf.  That process can use whatever heuristics I 
> describe and they
> >>can be lots more granular or clever than the <except-domain> can be
> >>(e.g. remove requests from (pending) when there are more 
> than N requests
> >>with the same username substring within Y seconds).  That process
> >>can also be me, the human, when I don't care to automate anything.
> >
> >I'm not sure I understand the difference between a process that 
> >moves things out of pending on my behalf, where presumably that 
> >process places them into "rejected" if they are from select domains, 
> >and a rule that works in the same way.
> 
> There are a couple of things that I was trying to get at here.  One 
> of the issues
> that drove geopriv to the additive permissions only point of 
> view was that
> you didn't necessarily know what order permissions would be granted in
> (especially where some are incorporated from external 
> sources).  That means
> the processing model for an additive/subtractive model requires all of
> the rules to be present and somehow sorted correctly to get 
> to the intended
> state.  If you can't resolve an external reference in that 
> case you either
> get nothing (because you're very conservative) or you reveal 
> to much (because
> you're insufficiently paranoid). In going to an additive 
> permissions model,
> you know that whatever permissions have been granted up to a specific
> point are intended and that you are being at least as conservative as
> was intended.  You also are free to process the directives in 
> any order.
> 
> Except clauses that are clearly tied to specific directives are better
> than all-out negative permissions, but they can remain problematic
> in their interaction with user expectations.  If I say "Grant anyone
> access to my timezone, except Hisham" and also say "Grant any
> wg chair in APPs access to my full location", Hisham will get my
> time zone--but this may not be what a user expects, especially
> if the user expectation is driven by a sense of "override" and
> wrote the "except Hisham" after the first rule was in place.
> 
> For a process model, all of the additive rules are done first
> before a process kicks in--this means that you can guarantee 
> an evaluation
> order-- all the rules and then later the processes (which I 
> should probably
> call something other than "process").  Personally, I think that helps,
> especially if the rules are constructed so as to put those which
> require post-rule evaluation into what are essentially pending
> states (as this leaves the "you are being at least as conservative
> as intended" in place).  A human can do the post-rule evaluation,
> or it can be done by a process/agent/heuristic engine of whatever
> complexity is appropriate.
> 
> That's the other main point--I believe that the "grant any, except
> domain" is so close to useless that it is not worth it; it is 
> trivially
> easy to mint identities that escape this clause.  To get to something
> that actually successfully excluded someone here, I think you'd
> eventually need something of close to arbitrary complexity, and
> that this does not belong in the rules language "Anyone may 
> know my timezone
> except those whose identities are associated with domains 
> that have been
> recently minted, are in this list, or were paid for by credit cards
> traceable to "Hisham Khartabil" or were paid for in ways that are
> not traceable." *might* succeed in keeping Hisham from knowing
> what timezone I'm in.  But even then, he has only to get a friend
> to loan him a cc to get past it.
> 
> 			regards,
> 				Ted
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 24 Jun 2005 11:48:41 -0700

Howdy,
	Sorry for the long delay in replying, and thanks to Robert for
the reminder.

>I don't still get your point why this type of exceptions within a particular rule/directive would be against the additive model of permissions. I think you would still get the same results whichever…

I agree that having the <except> clause for applicability within the rule is better
than the cases GeoPriv was most concerned with (it's always processed at the same
time, so the evaluation order problem isn't salient).  It is, though, a negative
permission--it's a grant to all followed by a revoke to a limited set.   One of the
issues I expressed is that the limited set isn't useful, because of identity minting.
The other is that the except clause here forces a change to the processing model.
I'm concerned that changing the processing model to (Grant, followed by revoke)
will open us to things that will have the problems GeoPriv wanted to avoid.

>In fact, the separate post-processing after the authorization decision has been already done, is much more contradictory to the model, since then you may be enforcing exceptions that are "global", a…

I was arguing that the auth policy does not say "grant", but says
"mark for further processing"; from my perspective, that means
that you have *not* granted any permissions and that any later processing does not
have the same effect as revocation of a previous grant.  It also means that
there is no chance that the failure of that process to run will reveal more
information; if the post-processing is faulty, obviously, you can end up
with it doing wild and crazy things.  Since I don't think the post-processing
is a subject for standardization, I agree that this is a risk.  I think, though,
that we're going to see post-processing in any case (as I don't see the
standards mechanisms meeting all the needs).

>   This decision can be done at many levels: service provider can ban them, client vendor can band them, UI designer can ban them, the user can decide not to use them. The main point: I do *NOT* thi…

Do you believe that this except-based processing is enough to meet the market
needs here, or will we see post-processing in any case?  I can't, personally,
imagine someone selling a black-listing capability that worked at the granularity
of a domain, and that was one of the reasons I asked for use cases.

To put this another way, if we keep fairly strictly to additive permissions in
rules, it is clear to an implementor how to manage those rules; if we have
some Grant/Revoke logic at the rule level and a different set of Revocation
logic that is only available through post-processing, I think we are putting
things at risk for less predictable results.

>2. There are many many cases where users would not need to care about identity minting. For instance, if I want to block my mother for a while, I can be pretty sure she won't go about minting anothe…

Again, though, is this the right granularity for the use case at hand?

And again, my apologies for the delay in replying.
				regards,
					Ted Hardie

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 24 Jun 2005 17:35:50 -0400

Ted Hardie wrote:
> I agree that having the <except> clause for applicability within the
> rule is better than the cases GeoPriv was most concerned with (it's
> always processed at the same time, so the evaluation order problem
> isn't salient).  It is, though, a negative permission--it's a grant
> to all followed by a revoke to a limited set.   One of the issues I
> expressed is that the limited set isn't useful, because of identity
> minting. The other is that the except clause here forces a change to
> the processing model. I'm concerned that changing the processing
> model to (Grant, followed by revoke) will open us to things that will
> have the problems GeoPriv wanted to avoid.

I don't quite agree with the statement of the model made above. This is
not "grant, then revoke". Rather, the exception condition restricts the
matching of the rule. Logically speaking, rule processing proceeds in
two phases:

(1) Determine if the rule matches a request (subscription, location
request, etc.)

(2) Execute the actions and grant the permissions (it's a bit more 
complicated, but irrelevant for this discussion).

The "all except" part only affects the matching (step 1), not the action
(step 2).

This is an important difference, as it avoids the privacy unsafety
issues that grant-then-revoke would have. Rules are binary in matching,
i.e., they either match or don't, and thus the consequences you seem to
fear cannot occur, inside or outside of the geopriv context.

I want to make the difference clear since I was also confused on this
point when this whole discussion started a year or so ago.

Thus, to make up another example that avoids the identity-minting issue,
"Apply this rule at any location except New York" would be perfectly fine.

The distinction becomes clearer if you consider hypothetically that we 
might allow regular expressions in the matching part. We could have 
something like

[^0-9]

which can be phrases as "any character except 0-9". Or, if we had a 
numeric matching condition, something like "x > 9 || x < 0" could just 
as easily be phrased as "any x except between 0 and 9". Clearly, neither 
of these examples are "grant/revoke" conditions.

> Do you believe that this except-based processing is enough to meet
> the market needs here, or will we see post-processing in any case?  I
> can't, personally, imagine someone selling a black-listing capability
> that worked at the granularity of a domain, and that was one of the
> reasons I asked for use cases.

This is apparently common for email. For example, there are folks who 
blacklist aol.com, yahoo.com and hotmail.com as they perceive them to be 
favorite sources of fake email addresses and/or individuals whose 
communication they can do without. I've put email domains on my 
blacklist when somebody didn't pay attention to my unsubscribe request.

> 
> To put this another way, if we keep fairly strictly to additive
> permissions in rules, it is clear to an implementor how to manage
> those rules; if we have some Grant/Revoke logic at the rule level and
> a different set of Revocation logic that is only available through
> post-processing, I think we are putting things at risk for less
> predictable results.

Please see above. I don't think it is helpful to phrase this as 
grant/revoke, as it does not fit that model. There is never anything 
granted that could be revoked - the rule just isn't invoked.

Henning