Subject: RE: supporitng blacklists, was: Re: [Simple] Comments on: First draft of text on semantic-based authorization policies [exceptions]

From: [email-masked]
Date: Thu, 25 Mar 2004 00:24:19 +0200

Hi,

Inline:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Henning Schulzrinne
> Sent: 24 March, 2004 16:09
> To: Jonathan Rosenberg
> Cc: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: supporitng blacklists, was: Re: [Simple] 
> Comments on: First
> draft of text on semantic-based authorization policies [exceptions]
> 
> 
> 
> 
> >> I think the concept of 'everybody gets to ask for 
> permission before 
> >> subscribing except bad guys A, B and C who I've already 
> told to get 
> >> lost' is useful and might implementable by an appropriate 
> ordering of
> >>  actions. For example, if you order actions as
> >>
> >> known_reject (highest), permit, ask, dont_bother (lowest, default)
> >>
> >> the right thing happens. However, caveats about file merging apply.
> > 

And I guess that one of the design goals was that if you have a rule that permits something, there can't be a rule which takes it away ('known_reject' clearly gives out less than 'permit'), as if the rules come from different places and some of them are somehow not "executed", more information is revealed that what was the intention. 

> > 
> > Henning - I dont understand how this is privacy safe. In 
> your ordering, 
> > there is not a strictly increasing amount of information 
> revealed as the 
> > values increase.
> 
> The idea is 'known reject' trumps all other values. Thus, if your 
> identity matches such a rule, it gets bounced even if a more 
> encompassing rule allows to request permission.
> 

Still I guess this would be against the spirit of privacy safety?

> This is unnecessary if we agree that global blacklists are a bad idea 
> even for the subscription (as opposed to information 
> delivery) phase. My 
> notion is only needed if you want to support the notion:
> 
> "Everybody in the world, in any domain, gets to *ask* to 
> subscribe to my 
> presence, but Alice, Bob and Carol have already been told to 
> take a hike 
> and thus shouldn't even be able to ask."
> 
> Is this the type of rule we want to be to support?
> 

This is exactly what I'm trying to get supported (even if I made negative comments about the proposal above...)! Can someone explain what would the problem with

<identity>
      <any/>
      <except>[email-masked]</except>
      <except>[email-masked]</except>
</identity> 

I see this so that the <identity> element defines a set with an "atomic" operation, i.e. if something goes wrong the end-result would be an empty set (same as with external lists within <identity>). The permissions that follow would then be applied to this set. 

So there isn't anything like defining a rule which makes an exception to permissions given in another rule, which I understand is bad. The whole exception handling happens wihin the scope of <identity> element in a single rule.

Here's an example: Let's say that there are two rules, which provide the same permission. Identity-elements for those are defined like this:

Rule 1:
<identity>
      <any/>
      <except>[email-masked]</except>
</identity>

Rule 2:
<identity>
      <any/>
      <except>[email-masked]</except>
</identity> 

Taking an union of these sets results in <all> and is according to the additiveness principle.

> Henning

Markus

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Mar 2004 18:43:00 -0500

> And I guess that one of the design goals was that if you have a rule
> that permits something, there can't be a rule which takes it away
> ('known_reject' clearly gives out less than 'permit'), as if the
> rules come from different places and some of them are somehow not
> "executed", more information is revealed that what was the intention.

Indeed; this variation violates this to some extent, but doesn't really 
reveal information. Again, I'm not proposing this, but it seems the best 
solution to the "blacklist A from asking" problem without breaking other 
things.

> Still I guess this would be against the spirit of privacy safety?

There are two kinds of privacy safety: data revealing and asking. Data 
revealing is really bad, allowing asking doesn't (directly) reveal 
information, but can be a nuisance, due to the need to say no again and 
again. (Just ask parents with small children about that...)

Privacy safety violations occur if removal of a rule provides more data 
than before. Removal of this rule doesn't directly provide more data, 
but allows A to be more of a nuisance. Any exception rule will have (at 
least) this property and may, if done carelessly, also reveal 
information directly.

> <identity> <any/> <except>[email-masked]</except> 
> <except>[email-masked]</except> </identity>
> 
> I see this so that the <identity> element defines a set with an
> "atomic" operation, i.e. if something goes wrong the end-result would
> be an empty set (same as with external lists within <identity>). The
> permissions that follow would then be applied to this set.
> 
> So there isn't anything like defining a rule which makes an exception
> to permissions given in another rule, which I understand is bad. The
> whole exception handling happens wihin the scope of <identity>
> element in a single rule.

I think this can work, with the caveats of the danger of revealing 
information.

> 
> Here's an example: Let's say that there are two rules, which provide
> the same permission. Identity-elements for those are defined like
> this:
> 
> Rule 1: <identity> <any/> <except>[email-masked]</except> </identity>
> 
> Rule 2: <identity> <any/> <except>[email-masked]</except> </identity>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Mar 2004 18:43:00 -0500