Subject: [Rucus] Next Steps towards the EG

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 01 Apr 2008 22:57:10 +0300

A little time passed after the IETF meeting and now we need to go back 
to work.

We now need to determine the expected outcome of the Exploratory Group 
(otherwise it cannot get chartered).

My impression from the discussion at the IETF meeting was that we would 
want to determine what mechanisms (that got proposed so far) are useful 
enough for most of the folks in the group to later work on. To make it a 
bit more "challenging" we should limit the number of items we want to 
standardize to a small number. Let's say "3".

Is that a useful expected outcome? Decide on 3 solution approaches that 
we would like to standardize.
We would obviously want to describe on what "properties" we get when we 
have these three mechanisms.

Ciao
Hannes

_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Apr 2008 16:05:23 -0700

Jonathan's presentation at the Philadelphia RUCUS meeting, "RFC 5039 Overview"
<http://www3.ietf.org/proceedings/08mar/slides/rucus-0.ppt>, had a slide that
showed each RFC5039 solution in red, yellow, and green.  The intent, as I
understood it, is that red meant solutions that were difficult to implement or
were not likely to be successful, green is for solutions that should be
relatively easy to implement and should be relatively successful, and yellow
is between green and red.

Red solutions:
  * Content Filtering
  * Address Obfuscation
  * Computational Puzzles
  * Payments at Risk

Yellow solutions:
  * Black Lists
  * Reputation
  * Limited Use Addresses
  * Turing Tests
  * Legal Action

Green solutions:
  * White Lists
  * Consent
  * Circles of Trust
  * Centralized Providers

and text to the right on Jonathan's slide said "Strong Identity a Key For Many
of these!".

I propose that RUCUS concentrate on the first three listed as green, namely:

  * White Lists 
  * Consent 
  * Circles of Trust 

I don't believe there is much to be standardized with the last green solution,
Centralized Providers.

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Hannes Tschofenig
> Sent: Tuesday, April 01, 2008 12:57 PM
> To: rucus BoF
> Subject: [Rucus] Next Steps towards the EG
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 1 Apr 2008 19:44:25 -0400

Hannes should speak for himself, but I thought we were talking a bit  
more general, rather than specific spam prevention solutions. For  
example, one tool that's been discussed repeatedly is the marking of  
calls and the various call treatment options. I don't think it's  
particularly productive to go through all the spam techniques.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Apr 2008 22:23:55 -0600

> I propose that RUCUS concentrate on the first three listed as green, namely:

+1

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John Levine <[email-masked]>
Date: 2 Apr 2008 04:38:09 -0000

>My impression from the discussion at the IETF meeting was that we
>would want to determine what mechanisms (that got proposed so far)
>are useful enough for most of the folks in the group to later work
>on. To make it a bit more "challenging" we should limit the number of
>items we want to standardize to a small number. Let's say "3".

I'm trying to figure out a constructive way to say this, but based on
the discussion I've seen so far, I would be concerned that many of the
participants are relatively new to abuse issues, and that it's hard to
predict whether an anti-abuse technique will be effective even when
you've been doing this stuff for a while.

After a decade in the email anti-spam trenches, I cannot tell you how
many times people have arrived with great enthusiasm for techniques
that don't work at all.  (That's why I'm working on the wiki of
anti-spam techniques at http://wiki.asrg.sp.am, largely to document
our failures so we don't have to repeat them.)  Or something works for
a while, the spammers learn to evade it, and then we get into big
fights about whether to change the rules about what's acceptable mail
practice to plug the hole the spammers found, or to try something
else.

I would suggest that it's more likely to be productive to look at
techniques to recognize and whitelist known good actors than to try to
exclude or hide from bad actors.  The set of good actors changes
slowly, and their behavior probably won't change at all, so it's much
more likely that whatever you come up with will continue to work.

I'd agree with Dan's green list except that I happen to think that
centralized (or more likely shared) whitelists are a particularly
promising approach.

R's,
John Levine, grizzled old ASRG chair

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 02 Apr 2008 08:48:07 +0200

Hi Hennig, 

I was looking for this type of feedback since I was actually proposing this "framework" approach as you indicated. Then, Jonathan came along with his idea to write drafts for each individual approach and indicate what the properties are and then to select something. To my surprise people liked his approach, at least at the BOF. 

While I understand that we have to pick a specific mechanism later on I believe that most mechanisms treated in isolation are pretty useless. The only make sense in the context of some architectural assumptions. 

Consider, for example, user-written white lists: They obviously make only sense if there is a way to solve the introduction problem and when you have some strong identity mechanisms. Then, when the evalutation of the identity is done at the end host and the policies are only available at the end host then there is no protocol work todo since the white list handling is purely an implementation issue. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Tue, 1 Apr 2008 19:44:25 -0400
> Von: Henning Schulzrinne <[email-masked]>
> An: Dan Wing <[email-masked]>
> CC: "\'Hannes Tschofenig\'" <[email-masked]>, "\'rucus BoF\'" <[email-masked]>
> Betreff: Re: [Rucus] Next Steps towards the EG

---

From: "Saverio Niccolini" <[email-masked]>
Date: Wed, 2 Apr 2008 15:05:19 +0200

I think the more general approach makes more sense and I see it more
in the scope of an exploratory group.

This does not exclude that the document where the general approach
will be described will also have a list of some techniques (no more
than 2 pages for each) that will be ranked for thei success probability
(like green, yellow, red).

Thus my (concrete) proposal would be:
-- general reference scenario (start from spitstop draft, add the
consideration Otmar/David/others posted, in the end it is enough to
summarize Henning presentation at the BOF)
-- proposal for a framework mapping to the scenario (start from Hannes
draft)
-- list of potential proposal with related ranking (start from classification
of Jonathan, add the mechanisms he left out and that where proposed in
various draft)

--> We have the document :-)

Only if we make successful investigations in this sense we will have
a chance to build standard that will address the real problem

I hope you like it :-)

Saverio

============================================================
Dr. Saverio Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

> Sent: Wednesday, April 02, 2008 8:48 AM
> To: Henning Schulzrinne; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Rucus] Next Steps towards the EG
> 
> Hi Hennig, 
> 
> I was looking for this type of feedback since I was actually 
> proposing this "framework" approach as you indicated. Then, 
> Jonathan came along with his idea to write drafts for each 
> individual approach and indicate what the properties are and 
> then to select something. To my surprise people liked his 
> approach, at least at the BOF. 
> 
> While I understand that we have to pick a specific mechanism 
> later on I believe that most mechanisms treated in isolation 
> are pretty useless. The only make sense in the context of 
> some architectural assumptions. 
> 
> Consider, for example, user-written white lists: They 
> obviously make only sense if there is a way to solve the 
> introduction problem and when you have some strong identity 
> mechanisms. Then, when the evalutation of the identity is 
> done at the end host and the policies are only available at 
> the end host then there is no protocol work todo since the 
> white list handling is purely an implementation issue. 
> 
> Ciao
> Hannes
> 
> > > Jonathan's presentation at the Philadelphia RUCUS 
> meeting, "RFC 5039 
> > > Overview"
> > > 
> <http://www3.ietf.org/proceedings/08mar/slides/rucus-0.ppt>, had a 
> > > slide that showed each RFC5039 solution in red, yellow, 
> and green.  
> > > The intent, as I understood it, is that red meant solutions that 
> > > were difficult to implement or were not likely to be successful, 
> > > green is for solutions that should be relatively easy to 
> implement 
> > > and should be relatively successful, and yellow is 
> between green and 
> > > red.
> > >
> > > Red solutions:
> > >  * Content Filtering
> > >  * Address Obfuscation
> > >  * Computational Puzzles
> > >  * Payments at Risk
> > >
> > > Yellow solutions:
> > >  * Black Lists
> > >  * Reputation
> > >  * Limited Use Addresses
> > >  * Turing Tests
> > >  * Legal Action
> > >
> > > Green solutions:
> > >  * White Lists
> > >  * Consent
> > >  * Circles of Trust
> > >  * Centralized Providers
> > >
> > > and text to the right on Jonathan's slide said "Strong Identity a 
> > > Key For Many of these!".
> > >
> > >
> > >
> > > I propose that RUCUS concentrate on the first three 
> listed as green,
> > > namely:
> > >
> > >  * White Lists
> > >  * Consent
> > >  * Circles of Trust
> > >
> > > I don't believe there is much to be standardized with the 
> last green 
> > > solution, Centralized Providers.
> > >
> > > -d
> > >
> > >
> > >> From: [email-masked] [mailto:[email-masked]] On 
> > >> Behalf Of Hannes Tschofenig
> > >> A little time passed after the IETF meeting and now we 
> need to go 
> > >> back to work.
> > >>
> > >> We now need to determine the expected outcome of the Exploratory 
> > >> Group (otherwise it cannot get chartered).
> > >>
> > >> on.
> > >> To make it a
> > >> bit more "challenging" we should limit the number of 
> items we want 
> > >> to standardize to a small number. Let's say "3".
> > >>
> > >> Is that a useful expected outcome? Decide on 3 solution 
> approaches 
> > >> that we would like to standardize.
> > >> We would obviously want to describe on what "properties" we get 
> > >> when we have these three mechanisms.
> > >>
> > >> Ciao
> > >> Hannes
> > >>
> > >>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 2 Apr 2008 10:52:23 -0400

On Apr 2, 2008, at 2:48 AM, Hannes Tschofenig wrote:

> proposing this "framework" approach as you indicated. Then, Jonathan  
> came along with his idea to write drafts for each individual  
> approach and indicate what the properties are and then to select  
> something. To my surprise people liked his approach, at least at the  
> BOF.

Having informal description of the properties seems like a useful  
project, but John's/ASRG Wiki may well serve this purpose. Even for  
more architectural and protocol work, we clearly have to pick a set of  
general techniques we envision as being most useful and plausible.  
There's no need to think about building a global micro-payment  
protocol, say, if we don't believe that micro-payments are likely to  
be useful or (economically/legally) feasible.

So far, identity and statistical-property-based approaches seem most  
promising, corresponding to the 'green' list.

Henning

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Apr 2008 15:52:28 -0700

>I propose that RUCUS concentrate on the first three listed as green, namely:

Indeed. There are reasonable areas of exploration in each of these, 
and they do avoid many of the ratholes on the red list.

Note that "reputation" and "white lists" go hand-in-hand, but it's 
probably a different "reputation" than RAI folks are used to. Someone 
putting together a white list does so based on some knowledge of the 
organizations listed. That is, in essence, reputation. I think the 
"yellow list" reputation is "every end node needs to be keeping track 
of the reputation of every other party, and that is indeed yellow/red 
list fodder.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 3 Apr 2008 10:43:09 +0200

> you've been doing this stuff for a while.

:-)

I've spent too much time of my life running mail servers not to
agree with you.

> more likely that whatever you come up with will continue to work.

I fully agree with you here. My take is in Section 4.1 of
draft-lendl-speermint-background-01.

As long as you assume the full email-model where every single IP address
on the Internet is a potentially valid source of a call / email leads
to an IMHO unsolvable SPAM/SPIT problem. As I see it, as long as you
don't revisit that assumption, you are going to fail.

Detecting good actors is the only way to go. As you write, this
is a lot easier that just trying to detect the bad guys.

As I see the problem space, there is only one missing piece in the
architecture: How do you route a call if the sending network is not
recognized by receiving network as a "white hat"?

/ol
-- 
-=-  Otmar Lendl  --  [email-masked]  -=-
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: Thomas Froment <[email-masked]>
Date: Thu, 03 Apr 2008 11:04:42 +0200

My understanding was that a there was a reasonnable consensus to fo 
forward with
Jonathan's proposal.
So, goal of the RUCUS charter would not be to focus *right now* on 
(only) 3 mechanisms, but
to define *what kind of contribution* could be expected from RUCUS EG.

What about this proposal?

---

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 3 Apr 2008 17:24:27 +0200

I support the direction "what kind of contirbution do we need"
much more than "let's identify 3 mechanisms and standardize them"

As I said already (nobody commented so far), in my opinon the 
RUCUS output should be:
-- reference scenario
-- reference framework
-- list of potential solutions (categories, not mechanism x/y)
with properties and expected impact in solving the problem

Saverio

> On Behalf Of Thomas Froment
> Sent: Thursday, April 03, 2008 11:05 AM
> To: Hannes Tschofenig
> Cc: rucus BoF
> My understanding was that a there was a reasonnable consensus 
> to fo forward with Jonathan's proposal.
> > would want to determine what mechanisms (that got proposed 
> so far) are 
> > useful enough for most of the folks in the group to later 
> work on. To 
> > make it a bit more "challenging" we should limit the number 
> of items 
> > we want to standardize to a small number. Let's say "3".
> >
> > Is that a useful expected outcome? Decide on 3 solution approaches 
> > We would obviously want to describe on what "properties" we 
> get when 
> > we have these three mechanisms.
> >
> > Ciao
> > Hannes
> >
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Apr 2008 15:04:39 +0300

Hi Henning,

Henning Schulzrinne wrote:
>> came along with his idea to write drafts for each individual approach 
>> and indicate what the properties are and then to select something. To 
>> my surprise people liked his approach, at least at the BOF.
>
> project, but John's/ASRG Wiki may well serve this purpose.
I would even say that we know the properties of most techniques already 
based on http://tools.ietf.org/html/rfc5039.

For other techniques that have a close relationship to techniques 
proposed in the email space we already have John's Wiki.

> Even for more architectural and protocol work, we clearly have to pick 
> a set of general techniques we envision as being most useful and 
> plausible.
Right.

> be useful or (economically/legally) feasible.
Correct.

> promising, corresponding to the 'green' list.
Yep.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Apr 2008 15:08:43 +0300

There are two types of white lists we have discussed in the past:

* End User White Lists
* Domain White Lists

End user white lists do not need a repuation associated with them since 
they are quite likely added based on the interaction between humans. 
This is something like http://www.ietf.org/rfc/rfc5025.txt.

Domain based white lists, on the other hand, is needed for other work we 
did, namely for SIP SAML.

In any case, the actual white list (if someone would want to standardize 
the language) could be based on something we have developed as Common 
Policy (which is also used by RFC 5025).

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Apr 2008 15:13:49 +0300

John, Otmar,

many of us (if not most) agree that whitelists are very good approaches 
to go forward (and blacklists aren't). We had a long discussion about 
this issue in our work on Common Policy/Presence Authorization Policy.

Otmar takes the approach one step further in the context of real-time 
communication in the sense that he suggests a way to deal with the 
introduction problem by using the ability to route calls differently. I 
think that's an interesting approach (and hence I have encouraged him to 
re-publish his draft-lendl-speermint-background-01 document).

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Apr 2008 15:16:02 +0300

Hi Thomas,

> My understanding was that a there was a reasonnable consensus to fo 
I also asked whether the group wants to create a EG to work at all on 
these issues.

> to define *what kind of contribution* could be expected from RUCUS EG.

We wouldn't focus our time in the EG on standardizing the solutions 
details. That's true.

My question hence was indeed targeted towards the expected result from 
the EG. So, what would you like to see as outcome of the EG?

Ciao
Hannes

> Hannes Tschofenig wrote:
>> A little time passed after the IETF meeting and now we need to go 
>> back to work.
>>
>> We would obviously want to describe on what "properties" we get when

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Apr 2008 15:17:48 +0300

> much more than "let's identify 3 mechanisms and standardize them"
Nobody said that we would work on 3 mechanisms in the EG.

> with properties and expected impact in solving the problem
I think we are replicating the results several times. A framework 
describes solutions that would work together.
Typically, individual solutions (at least in this space) have certain 
properties when used in combination with other techniques.

Ciao
Hannes

>>> A little time passed after the IETF meeting and now we need 
>>>       
>> to go back 
>>     
>>> to work.
>>>
>>> We now need to determine the expected outcome of the 
>>>       
>> Exploratory Group 
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 5 Apr 2008 18:18:21 -0400

There are two kinds of end-user white lists, individual and shared.  
Building individual white lists ("everybody in my address book") is  
relatively straightforward. Building shared address lists ("everybody  
my friends and colleagues have called") requires a bit more work.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 5 Apr 2008 23:45:52 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hannes Tschofenig
>

+1.  It is an excellent draft.

-hadriel

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 06 Apr 2008 14:41:17 +0300

Hi Henning,

> my friends and colleagues have called") requires a bit more work.
That's true. The later aspect would go into exploiting your 
relationships you have in a social network.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 07 Apr 2008 08:47:09 -0500

> relationships you have in a social network.

Right; that is exactly what I thought as well.  But there is a
problem.   Jagatic et al. [1,2] conducted a study on the effect of
social networking on phishing.  Their results indicate that 72% of
the recipients responded to the phishing email that purported to
originate from a friend within their social network, while only 16%
of the recipients responded when the phishing email was from an
unknown address.

So ... if we go the social networking route, does that mean that
you become an easier target for phishing attempts by someone
pretending to be on your social list?

[1] T. Jagatic, N. Johnson, and M. Jakobsson, "Phishing attacks
  using social networks," manuscript, Indiana University Human
  Subject study 05-9892 and 05-9893, 2005.
[2] T. Jagatic, N. Johnson, M. Jakobsson, and F. Menczer, "Social
  Phishing," Comm. of the ACM, 50(10), pp. 94-100, October 2007.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Apr 2008 15:23:25 -0700

> On Behalf Of Vijay K. Gurbani
> Sent: Monday, April 07, 2008 6:47 AM
> To: Hannes Tschofenig
> Cc: [email-masked]

I believe I found a brief write-up of that research at
http://www.indiana.edu/~phishing/social-network-experiment/

The key is 'proported'; we wouldn't want to do that, and with 
SIP's strong identity, we wouldn't have messages from a *proported*
member of the social circle (but which is actually from a spammer).
Rather, we would have a message that is provably from a member of
the social circle.

-d

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 10 Apr 2008 15:12:24 -0500

Dan Wing wrote:
vkg> So ... if we go the social networking route, does that mean that
vkg> you become an easier target for phishing attempts by someone
vkg> pretending to be on your social list?
vkg>
vkg> [1] T. Jagatic, N. Johnson, and M. Jakobsson, "Phishing attacks
vkg>   using social networks," manuscript, Indiana University Human
vkg>   Subject study 05-9892 and 05-9893, 2005.
vkg> [2] T. Jagatic, N. Johnson, M. Jakobsson, and F. Menczer, "Social
vkg>   Phishing," Comm. of the ACM, 50(10), pp. 94-100, October 2007.
dwing>
dwing> I believe I found a brief write-up of that research at
dwing> http://www.indiana.edu/~phishing/social-network-experiment/
dwing>
dwing> The key is 'proported'; we wouldn't want to do that, and with
dwing> SIP's strong identity, we wouldn't have messages from a *proported*
dwing> member of the social circle (but which is actually from a spammer).
dwing> Rather, we would have a message that is provably from a member of
dwing> the social circle.

Dan: I am not arguing with what you write above.  The fundamental
straw that binds this work has to be Identity (modulo the
concerns on it that have been expressed by
draft-rosenberg-sip-rfc4474-concerns-00 and
draft-kaplan-sip-baiting-attack-02).

However, my post was in response to what Prof. Schulzrinne
described as "Building shared address lists ("everybody my
friends and colleagues have called") requires a bit more work."
This is the aspect of social networking that is challenging when
you consider transitive trust issues in social networks where
people are separated from each other by 3 or 4 degrees.

For instance, if I have a filter that allows all my colleagues
in LinkedIn to contact me, have I opened myself to spit if
a tertiary connection gets her identity stolen and spams me?

Thanks,

- vijay