Subject: RE: [Simple] Another idea for presence authorization

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Jul 2001 17:52:59 -0400

> -----Original Message-----
> From: Michael Hammer [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2001 5:49 PM
> To: Jonathan Rosenberg
> Cc: Jonathan Rosenberg; Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel
> Starin'; [email-masked]
> Subject: RE: [Simple] Another idea for presence authorization
> 
> 
> At 05:22 PM 7/17/2001 -0400, Jonathan Rosenberg wrote:
> 
> >OK, let me try again. Telemarketer A decides to use presence 
> as a great way
> >to sell stuff. When someone logs in, they send them an IM 
> asking to buy the
> >latest widget. So, the telemarketer gets a huge list of 
> addresses, and
> >starts sending SUBSCRIBEs. Most sane people go and upload 
> authorization
> >policy that prohibits the subscription. However, the 
> telemarketer responds
> >to that in an interesting way. When the telemarketer refreshes the
> >subscription, they detect whether a negative authorization, or no
> >authorization has been provided. They then send an email to 
> the user, saying
> >"you still haven't approved subscriptions from widgets inc. 
> Please do so now
> >to find out the latest and greatest!".
> 
> They could just as easily do this when they notice after some 
> time that I 
> never seem to generate any subsequent Notify.  Nothing 
> gained.  Once they 
> recognize this behavior, it loses all credibility and value.

Except that its still a valid real scenario. How long does the attacker wait
before guessing that they weren't really authorized? No way to know.
However, if you don't send a NOTIFY when the attacker is not authorized,
they get an immediate, definitive piece of information on their
authorization state. In the telemarketer case, it may not be important to
know for sure, since they'll spam you anyway. But, there are cases where the
authorization data is sensitive. 

So, forget the mechanism to protect it. The first question to answer is
whether there is consensus here that SIMPLE should specify how to ensure the
confidentiality of authorization decisions (one can always opt-out and not
use it). I say we want that.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Daniel Starin" <[email-masked]>
Date: Tue, 17 Jul 2001 19:01:15 -0400

So we are all on the same level...

As I understand it... there are 6 possible states when user A makes a
subscription request to user B...

User B is?/The response to the subscription was?

1. Present/Accepted
2. Present/Pending
3. Present/Rejected
4. Not Present/Accepted
5. Not Present/Pending
6. Not Present/Rejected

If we send "Offline" notifies every time...

If User A gets an Offline notifies...
he knows the state is one of the following

2. Present/Pending
3. Present/Rejected
4. Not Present/Accepted
5. Not Present/Pending
6. Not Present/Rejected

If User A gets an Online notify..
He knows the state is...

1. Present/Accepted

The "Online" notify method does indeed hide whether User A knows whether
or not his subscription was Accepted or not.  BUT... mathematically, it
gives User A something else to play with.... If the probability of all
six options are equal... User A knows that when he gets an "Offline"
notify that the percent chance that User B is really Offline is 60%
(3/5).  Mathematically, that is better than the 50/50 probability User A
has of knowing if User B is present or not that I will prove that you
get without sending any notifies at all...

Without sending notifies before authorization...

If User A gets No notify...
he knows the state is one of the following

2. Present/Pending
3. Present/Rejected
5. Not Present/Pending
6. Not Present/Rejected

if he get a Offline notify...

he knows the state is..
4. Not Present/Accepted

if he gets an Online notify...

he knows the state is
1. Present/Accepted

When user A recieves No notifies, there is a 50% chance that User B is
Present and a 50% chance that User B is not present... this truly
divulges no information about User B's presence to User A....

In this scenario... Jonathans statement is valid...

In non-mathematical terms, if I always tell you its sunny outside,
irregardless of whether it is or isn't, can you ever know whether it
really is or isn't? Have I told you anything useful? No!

In the notify every time scenario... this statement does not
apply...User A has a 60% chance of knowing User B's true presence
REGARDLESS of whether he is authorized or not...

In my mind... that makes notifying every time a bad idea... both
information wise and bandwidth wise...

Either way, I do understand the argument you make Jonathan.  You want to
exchange the knowledge of whether a subscription is granted or not for a
little bit of presence information (that 10%).... I feel, though, that
it is more important to protect presence than subscription
authorization.... Isn't ABSOLUTELY (so that User A only has a 50/50
chance) hiding your presence what rejecting a subscription is about?

-Dan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jonathan
Rosenberg
Sent: Tuesday, July 17, 2001 5:53 PM
To: 'Michael Hammer'; Jonathan Rosenberg
Cc: Jonathan Rosenberg; Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel
Starin'; [email-masked]
Subject: RE: [Simple] Another idea for presence authorization

> recognize this behavior, it loses all credibility and value.

Except that its still a valid real scenario. How long does the attacker
wait
before guessing that they weren't really authorized? No way to know.
However, if you don't send a NOTIFY when the attacker is not authorized,
they get an immediate, definitive piece of information on their
authorization state. In the telemarketer case, it may not be important
to
know for sure, since they'll spam you anyway. But, there are cases where
the
authorization data is sensitive. 

So, forget the mechanism to protect it. The first question to answer is
whether there is consensus here that SIMPLE should specify how to ensure
the
confidentiality of authorization decisions (one can always opt-out and
not
use it). I say we want that.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Daniel Starin" <[email-masked]>
Date: Tue, 17 Jul 2001 19:09:19 -0400

PLEASE disregard the other message and read this one... I missed a typo
which could ruin my argument...

1. Present/Accepted
2. Present/Pending
3. Present/Rejected
4. Not Present/Accepted
5. Not Present/Pending
6. Not Present/Rejected

2. Present/Pending
3. Present/Rejected
4. Not Present/Accepted
5. Not Present/Pending
6. Not Present/Rejected

1. Present/Accepted

The "Offline" notify method does indeed hide whether User A knows
whether or not his subscription was Accepted or not.  BUT...
mathematically, it gives User A something else to play with.... If the
probability of all six options are equal... User A knows that when he
gets an "Offline" notify that the percent chance that User B is really
Offline is 60% (3/5).  Mathematically, that is better than the 50/50
probability User A has of knowing if User B is present or not that I
will prove that you get without sending any notifies at all...

2. Present/Pending
3. Present/Rejected
5. Not Present/Pending
6. Not Present/Rejected

if he gets an Offline notify...

he knows the state is..
4. Not Present/Accepted

he knows the state is
1. Present/Accepted

When user A receives No notifies, there is a 50% chance that User B is
Present and a 50% chance that User B is not present... this truly
divulges no information about User B's presence to User A....

-Dan

-----Original Message-----

-Jonathan R.

---

---

From: James Undery <[email-masked]>
Date: Wed, 18 Jul 2001 09:36:13 +0100

> he knows the state is one of the following

6 is not an option a rejected subscription will not generate a NOTIFY

> Offline is 60% (3/5).

But the probabilities are nowhere near equal (and you are still wrong about
6), assuming there are 1 million people in the world, the fraction of them
I'd authorise is minimal, meaning only 2 and 5 are likely if I pick a
presentity at random to subscribe to, giving a 50/50 chance.

> Mathematically, that is better than the 50/50

A CPIM decision not a SIMPLE one.

---

From: "Daniel Starin" <[email-masked]>
Date: Wed, 18 Jul 2001 14:29:03 -0400

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of James Undery
Sent: Wednesday, July 18, 2001 4:36 AM
To: Daniel Starin
Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian';
[email-masked]
Subject: Re: [Simple] Another idea for presence authorization

>6 is not an option a rejected subscription will not generate a NOTIFY
I

Wasn't the whole idea of sending a random notify every time to make it
so User A does not know whether or not his subscription has been
accepted or not?  According to Jonathans diagram previously posted in
the thread a Notify is sent every time... That would include the times
when User B is not present and has set a policy on his PS to reject the
subscription... Wouldn't a notify still be sent?.... If a notify is not
sent doesn't User A know that his subscription is rejected and then we
are back to the telemarketer problem Jonathan described?.... I hold that
6 is an option....

> presentity at random to subscribe to, giving a 50/50 chance.

Yes, out of the 1 million people, the ones you would authorize is
minimal... the people who would request to subscribe to you is minimal
as well... User A knows nothing about User B until a subscription is
made... thus he has no way of knowing anything about User B's policies
with respect to subscription authorization... the only thing he does
know is that if he gets an offline notify that there are 5 possible
status' and 3 of them specify that User A is offline... 

> A CPIM decision not a SIMPLE one.

Fine, but I think we have to come to some consensus on the matter... and
Jonathan just brought up another idea... sending random online/offline
status'..... I am willing to back off if everyone disagrees with me but
I think that the "information leak" others have mentioned is because of
the reason described above....

Dan

---

From: James Undery <[email-masked]>
Date: Thu, 19 Jul 2001 09:15:58 +0100

> are back to the telemarketer problem Jonathan described?.... I hold that

well I contend there is option 7 present / appearing offline, back to 50/50

> status' and 3 of them specify that User A is offline...

My main point is the very little I remember about Probability is for complex
situations it is easy to make assumptions to get the answer you want, I
content the argument is flawed as I could say based on the time of day I can
make a better than 50/50 guess, for instance as I write this email, I'd bet
you're at home probably asleep as it is 5am in New York.

> the reason described above....

Well on the information leak I'd disagree, some times the lack of
information is information i.e. the other person doesn't want to or can't
due to lack of presence respond. The idea of using subscribes from multiple
locations breaks the random answer idea. A lie is no good unless it is a
consistent lie and I generally prefer just saying offline.

James Undery

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 19 Jul 2001 10:32:16 -0400

The idea of sending a random online/offline NOTIFY when authorization is
pending or rejected seems rather strange to me. What happens if they receive
an "online" and then attempt to contact that user? Wouldn't the subsequent
failure tell the requestor they were not authorized (or at least give them a
clue)? Why should we encourage more message traffic half the time?

In my mind, personal privacy is paramount and the most sensitive piece of
information that should not be divulged is whether or not the authorization
is pending or rejected. I think that sending "offline", unless the requestor
is authorized and the target user is online is, the right thing to do. The
only thing that the requestor has been told is that they cannot reach the
target user, they have not been told exactly why.

All these probability number being thrown around don't really make sense to
me. If I subscribe to Jonathan's presence for the first time, and I get back
"offline", I would assume that the authorization is pending or rejected
since I have never contacted him before. If I have previously had an IM
session with him, I assume "offline" means "offline".

The response to the subscription with either a notify (or lack thereof)
divulges some information. I think the least sensitive piece of information
is saying the target user is "offline". If that state has a greater than 50%
probability of being correct, so what? Until I accept your subscription to
my presence, I am "offline" to you.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "James Undery" <[email-masked]>
To: "Daniel Starin" <[email-masked]>
Cc: "'Jonathan Rosenberg'" <[email-masked]>; "'Michael Hammer'"
<[email-masked]>; "'Rosen, Brian'" <[email-masked]>;
<[email-masked]>
Sent: Thursday, July 19, 2001 4:15 AM
Subject: Re: [Simple] Another idea for presence authorization

---

From: Michael Hammer <[email-masked]>
Date: Thu, 19 Jul 2001 10:54:36 -0400

Bob,

My only complaint is that this can be assumed and does not require extra 
message traffic to tell you that.

Mike