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

From: Ted Hardie <[email-masked]>
Date: Mon, 16 May 2005 10:42:53 -0700

Howdy,
	In today's GEOPRIV meeting, Hannes pointed out that
at IETF 62, the SIMPLE WG agreed to ask for the
introduction of an <except-domain> element to the common
policy document.  Sorry that I wasn't there to follow the discussion directly,
but I believe this is contrary to the basic design of additive
permissions.  In previous discussions within GEOPRIV, the
relative ease with which some identities may be minted has
led to the conclusion that this would either be useless
or would encourage people to warp the additive permissions
principle.
	To put this in concrete terms, if a grant of permissions to
<any identity> element contains an <except-domain>
element of "evil.example" in order to prevent the
folks from "evil.example" from access, the relative
ease with which "evil.example" folks can create
"unknown-ethics.example" makes this of questionable
utility.  At most, it forces the attacker to mint an identity.
What's the use case for which this is not true?  Or the
use case in which an additive permission does not behave
in this way?
	I would really appreciate this use case being
put forward before the common policy document is changed.
	Thanks,
			Ted Hardie

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

---

From: Aki Niemi <[email-masked]>
Date: Thu, 19 May 2005 11:32:33 +0300

Hi,

ext Ted Hardie wrote:
> utility.  

Yes, and I don't think anyone is arguing otherwise. But at least this 
seems of less questionable utility compared to excepting identities 
only, where simple URL scheme / application specific constructs like 
[email-masked]' are an easy way to get around the 
exceptions.

The next step is to use except a domain, then a TLD. I think the 
asusmption is that registering a new domain name, let alone a new TLD 
requires increasingly more effort.

> At most, it forces the attacker to mint an identity.

I don't quite follow. Are you saying domain exceptions should always be 
wildcards for domains?

> put forward before the common policy document is changed.

I have put forward this use cases several times, which I think 
demonstrates the need for the any-except construct. It is the ordinary 
reactive authorization policy, where everyone *initially* gets to ask 
for permission to subscribe to your presence information. I say 
"initially", because a user has to have an option not to be bothered by 
any more of these requests coming from the "example.com" domain that has 
proven a playground for phishers and spammers.

For implementing this policy with common policy, we need the 
any-identity condition to match any authenticated identity for the 
"confirm" action. In addition, we need safeguards against the weak 
domains, namely the domain exception.

Cheers,
Aki

---

From: Ted Hardie <[email-masked]>
Date: Tue, 24 May 2005 13:58:28 -0700

Aki Niemi writes:
>Yes, and I don't think anyone is arguing otherwise. But at least 
>this seems of less questionable utility compared to excepting 
>identities only, where simple URL scheme / application specific 
>constructs like [email-masked]' are an easy 
>way to get around the exceptions.
>
>asusmption is that registering a new domain name, let alone a new 
>TLD requires increasingly more effort.

I believe there is no functional difference in the difficulty of 
getting the identity
[email-masked] and [email-masked].
The hoop that must be jumped through to get an identity in any number of
domains is quite small; even if all of those domains were successfully included
in except-domain clauses the cost for minting a domain is around 5 euros
and less in bulk.  That means that someone at "evil.example" would have
to exhaust all of the y*, a*, m* and similar identity minting
domains before having to shell out anything and could then do so
for trivial costs.

>demonstrates the need for the any-except construct. It is the 
>ordinary reactive authorization policy, where everyone *initially* 
>gets to ask for permission to subscribe to your presence 
>information. I say "initially", because a user has to have an option 
>not to be bothered by any more of these requests coming from the 
>"example.com" domain that has proven a playground for phishers and 
>spammers.

Doing it this way doesn't require the underlying protocol to behave this way;
setting it up as reactive authorization so that someone can pre-program the
answer "no" to any set they like has the same effect and fits far better into
the model.  It is still trivially circumvented with the same methods above,
of course, but at least in the mean time you haven't changed the model for
permissions.

>domains, namely the domain exception.

I think this is based on a fundamentally flawed assumption, that the set of
"weak domains" is bounded and knowable.  We have ample experience in
other contexts to demonstrate that this is not the case for lots of other
cases.  That set changes over time, sometimes at great rates, and the use
of a higher-layer denial for it is both as effective and more appropriate.

Speaking personally, I do not believe the "except domain" 
construction is sufficiently
useful to warrant introduction at this stage of protocol work.
			regards,
				Ted Hardie

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 May 2005 17:26:04 -0400

Ted,

How do you imagine people should administer their presence authorization 
rules? It would seem that watcherinfo and pending status cannot in 
general work as the way to learn who wants to be authorized. If I set 
the default authorization to pending then I get spammed with 
authorization requests, but if I set the default authorization to 
reject, and only consider subscribers from a named set of domains, then 
I never learn about legitimate subscribers from other domains.

	Paul

Ted Hardie wrote:
>> [email-masked]' are an easy way to get around 
>> the exceptions.
>>
> I believe there is no functional difference in the difficulty of getting 
> the identity
>> "initially", because a user has to have an option not to be bothered 
>> by any more of these requests coming from the "example.com" domain 
>> that has proven a playground for phishers and spammers.
> 
> 
> Speaking personally, I do not believe the "except domain" construction 
> is sufficiently

---

From: Ted Hardie <[email-masked]>
Date: Tue, 24 May 2005 15:25:31 -0700

At 5:26 PM -0400 5/24/05, Paul Kyzivat wrote:
>Ted,
>
>How do you imagine people should administer their presence 
>authorization rules? It would seem that watcherinfo and pending 
>status cannot in general work as the way to learn who wants to be 
>authorized. If I set the default authorization to pending then I get 
>spammed with authorization requests, but if I set the default 
>authorization to reject, and only consider subscribers from a named 
>set of domains, then I never learn about legitimate subscribers from 
>other domains.
>
>	Paul

Paul,
	Let's say the real rule is "I grant the following permissions 
to those in the
set (authorized)".  To get into the set (authorized), I must put you 
into the set either
via a rule or by explicit action.  I can create a rule that says 
"Everyone from mycompany.example is in set (authorized)".  I can 
create a rule that says
"Everyone may be placed in set (pending) from which I may place them 
in (authorized)".
If I want to avoid seeing all of the entries in (pending) because I 
don't want to be
spammed by requests, I can do one of two things:  try to limit access 
to (pending)
via a set of rules on who may be in (pending) or treat the problem as 
automation
of the disposition decision.  As I understand it, Aki is arguing that 
the <except-domain>
element is a useful mechanism for limiting access to (authorized); it may also
be a tool he'd use for limiting access to (pending).  I don't think it
is useful, for the reasons I've outlined, and I do believe it runs 
contrary to the
additive permissions model in a way that is going to pose later 
problems.  I also believe
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.
	The fundamental problem you pose: "I never learn about legitimate
subscribers from other domains" also occurs in any case where 
legitimate subscribers
and black-hats can be matched on the same rule.  Yes, it does occur for the
"reject all, grant to mycompany.example" case.  Unless all legitimate
subscribers abandon those for whom minting an identity is easy, though, the
<except-domain> is also particularly subject to this problem.   You can ease
it with multi-stage processing (automation moves some from (pending) to
(suspicious) and others to (probably good)).  But if you are going to use
the system in a way that allows potentially anyone to request authorization
(that is, without a white-list), dealing with unwanted requests is 
one of the costs
of allowing legitimate requests through.  I personally believe that 
<except-domain>
style approaches are just not likely to be the right bang for the buck.
			regards,
				Ted Hardie

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 May 2005 19:17:43 -0400

Ted - comments inline.

	Thanks,
	Paul

Ted Hardie wrote:
>> authorization rules? It would seem that watcherinfo and pending status 
>> cannot in general work as the way to learn who wants to be authorized. 
>> If I set the default authorization to pending then I get spammed with 
>> reject, and only consider subscribers from a named set of domains, 
>> then I never learn about legitimate subscribers from other domains.
>>
>>     Paul
> 
> 
> Paul,
>     Let's say the real rule is "I grant the following permissions to 
> those in the
> "Everyone from mycompany.example is in set (authorized)".  I can create 
> a rule that says
> "Everyone may be placed in set (pending) from which I may place them in 
> (authorized)".

Both of those are fine in some cases, but maybe not sufficient.

> spammed by requests, I can do one of two things:  try to limit access to 
> (pending)
> via a set of rules on who may be in (pending)

This is hard if you can't anticipate all the places legitimate 
subscribers may come from.

> or treat the problem as 
> be a tool he'd use for limiting access to (pending). 

It was my interpretation that he was proposing to use it to limit access 
to pending. That is what I had in mind too.

> I don't think it
> is useful, for the reasons I've outlined,

It certainly isn't perfect. But it can be another tool in the bag to 
help manage a problem. If there was an alternative that would do as well 
then maybe we wouldn't need it, but I haven't seen the alternative.

> and I do believe it runs 
> problems. 

We already have other similar "exceptions" to the additive model. I 
believe they have been framed in a way that avoids the problems.

> I also believe
> with the same username substring within Y seconds). 

Yes, that is a possibility. But that particular rule has easy work arounds

But I wonder if rules to detect malicious subscribers are what is 
needed. I may be naive, but I don't anticipate a flood of malicious 
subscribers. What is the point? The only one I can think of is DOS, and 
there will no doubt have to be some other solution to that.

I think it is more likely that there just might be a lot of distinct 
pests. For instance, if you participate in some public forum where your 
address becomes well known, there might just be lots of "groupies" 
bugging you. If you can block them in big chunks (e.g. everybody at 
qualcomm.com seems to be a pest) then that is just a help.

> That process

That is always an option. Its just not always good enough.

> subscribers from other domains" also occurs in any case where legitimate 
> subscribers
> "reject all, grant to mycompany.example" case. 

Yep. That is why use of any such tool must be a thought out decision. 
("Are the problems from this domain bad enough to block it?" OR "Do I 
want to allow people to pend from that domain even though there may be 
some pests there?")

> Unless all legitimate
> (suspicious) and others to (probably good)). 

I don't know what you have in mind here regarding the status of these 
potential subscribers, and the UI at each end, while they are in these 
interim states. Without changing the event package, at the 
implementation level they are either rejected, pending, or accepted. 
Additional states have to map into one of these. Then they could affect 
the UI on the notifier end, but not on the subscriber end.

> But if you are going to use
> (that is, without a white-list), dealing with unwanted requests is one 
> of the costs
> of allowing legitimate requests through. 

Yes, that is understood. The trick is to minimize the pain of doing so.

> I personally believe that 
> <except-domain>

There is certainly room for different opinions on how much bang you get. 
But how big a buck are we talking about here? If its not such a big 
buck, then perhaps it is worth allowing as an option.

The biggest buck here is probably in the design of user friendly UIs to 
manage all of this. That is somebody else's buck.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 May 2005 12:13:29 -0400

A question inline.

> 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.

Can you clarify?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com