Re: [Asrg] Re: New draft on trust-path-discovery (Ono, Kumiko)

[[e-mail]]

On Mon, 18 Jul 2005, "Ono, Kumiko" <[e-mail]> wrote:
>Hi,
>
>Thanks for your comment. 

You're welcome.

>Content-filtering is effective for anti-spam/spim (unsolicited bulk 
>instant messages), but unfornately not for unsolicited bulk calls, 
>because the call cannot be analyzed before the user answers it, as 
>mentioned in a SIPPING draft, draft-ietf-sipping-spam-00.txt. 

I don't dispute that, but then again that's not what we're addressing HERE.

Our charge here is to deal with spam E-mails.  It may well be that dealing with 
"calls" requires some DIFFERENT technology or approach than what will be 
suitable for E-mails.

>Also, the number of my friends and their friends whose machines have 
>been converted to spambots is very low. 

1)  Congratulations, but (like in investments) past performance is no guarantee 
of future results.

2)  I still consider that basing E-mail acceptance purely on the REPUTATION of 
the (supposed) sender is LESS reliable than by using a criteria which combines 
the SENDER (if they are familiar to you) ALONG WITH the TYPE of E-mail content 
that you expect to receive from that sender.

3)  A sender who suddenly sends you something that does not "look like" the type 
of stuff you EXPECT AND TRUST to receive from that sender, ought to wave a 
yellow (or even red) flag.  

4)  There MIGHT be, for some recipients, SOME people who they correspond with 
who have a legitimate reason to occasionally (or even more often) send 
executable content.  My Aunt Gertrude probably doesn't need ANYBODY to EVER send 
her any executable content... this includes 170K .PIF files, JavaScript, ActiveX 
enclosures, or other such stuff, in her E-mail messages.

5)  There is probably NEVER a LEGITIMATE need for a previously unknown or 
unfamiliar sender to send attachments, scripting, or bulky HTML-burdened content 
to a recipient, before first establishing that the recipient is able to deal 
with (and willing to trust) such content from that sender.  If they wish to send 
such stuff, they ought to negotiate that with the intended recipient in advance.

6)  It is noteworthy that the GREAT majority of tricks and strategems that 
spammers use to evade antispam content scanner filters are based on attachments, 
scripting, or HTML.  Simply forbidding such (ultimately unnecessary) stuff in 
incoming E-mails from unfamiliar, unknown, or untrusted senders is an 
exceedingly effective way to dramatically increase the effectiveness of antispam 
content scanner filters.

7)  Eliminating HTML, scripting, ActiveX, attachments, and other forms of 
executable content from E-mail from unfamiliar senders is a HIGHLY effective way 
to virtually eliminate the possibility of sending viruses, worms, and other 
malware from typical, relatively unsophisticated users (and thus, HUGELY 
reducing their likelihood of finding their machines suddenly turned into zombie 
spambots).

8)  This kind of finely-grained permissions list (controlled by the recipient, 
and with a fine-mesh of E-mail content restrictions based on the sender of the 
E-mail... and with a suitably restricted set of default rules for those not 
specifically whitelisted) also permits just about ANYTHING that is possible 
today, while dramatically reducing the risks from E-mail transmission of virses, 
worms, and the like... and simultaneously striking a major body blow in the war 
against spam.

>We understand our propsal is not a perfect solution. However, there is 
>no single technique that can solve all spam problems. 

I concur that there is probably no single "magic bullet" which instantaneously 
eliminates and prevents E-mail hassles, now and forever into the future.

But then again, while nice, it's not REQUIRED that we eliminate 100.0000% of all 
spam (if for no other reason than the fact that some recipients consider mail 
objectionable even if it doesn't, strictly speaking, adhere to any specific 
universally-accepted definition for "spam".)

Therefore, what I think we ought to be looking for are minimally-invasive, 
minimally-disruptive techniques which rapidly provide a maximum of benefits in 
the war against viruses, worms, spam, and other malicious E-mail content, at a 
minimum cost.


As for these "trust relationships", especially when chained, perhaps it's 
instructive to tell a little story.

Twenty-odd years ago, near the start of the AIDS phenomenon, there were all 
manner of approaches that folks were using as they grasped at straws to try to 
continue their previous styles of (ultimately, irresponsible) behavior.

A friend of mine moved to San Francisco and joined a sex club there.  In order 
to join the club, you had to present the results of an HIV test proving that you 
were HIV negative, and to absolutely vow that henceforth you would only have 
sexual relationships with other members of the club.  Within the club, as one 
might expect, the members had outrageous amounts of totally unprotected sex.

All went well, for a short while, until the first member of the club 
seroconverted (and who can be sure whether it was because the person's test was 
inaccurate, or because they simply broke their promise to only play with other 
group members).  But the (totally predictable) result was that the whole house 
of cards came tumbling down, and a large percentage of the members of the group 
seroconverted in quick turn.


These "house of cards" trust relationships in the E-mail sphere are exactly 
comparable... and it's every bit as predictable that spammers will somehow 
acquire "trust", and/or eventually commandeer the system(s) of someone who IS 
trusted.

It's simply dumb for us, as responsible CS engineers, to try to deny the reality 
of this problem.  

There ARE approaches which provide a BIG improvement at a minimum cost (and 
without ANY serious downside).  It is irresponsible and inexcusable for us to 
not pursue such approaches.

Meanwhile, the stupidity of trusting SPF and such "reputation/authentication" 
approaches to control spam is evidenced by the following report that came out 
within the last week... (and please forgive me if this has already been reported 
here)...

[quote]

According to Denver-based message security vendor MX Logic, spammers are 
continuing to adopt Sender ID and Sender Policy Framework (SPF), two of the 
prominent e-mail authentication schemes that are actually intended to stop spam.

MX Logic tracked a sampling of 17.7 million messages that passed through its 
servers from June 19 through June 25, and found that of the 9 percent from 
domains with published SPF records, 84 percent was spam. Of the even smaller 
number of messages from domains with published Sender ID records (just 0.14 
percent), 83 percent were spam.

"Spammers continue to leverage SPF and Sender ID with the intention of making 
their messages appear more legitimate," said Scott Chasin, MX Logic chief 
technology officer, in a statement.

[end quote]

Based on that observation, one approach to spam filtering that would be right 
some five to six times more often than it would be wrong would be to trash all 
E-mail messages as spam if they use SPF or "Sender ID" authentication.  :-)

>
>Regards,
>Kumiko
>
>At 15:17 2005/07/15, [e-mail] wrote:
>>[quote]
>>
>>Henning and I wrote up the I-D that proposes a mechanism to find friends
>>-of-friends and trusted domains, which could be used as a tool to make 
>>white-list for filtering emails/calls. 
>>
>>We could not find any WG in the IETF that this draft belongs to, but we 
>>believe this RG might be interested in this draft. 
>>
>>Any comments are welcome.
>>
>>>	Title		: Trust Path Discovery
>>>	Author(s)	: K. Ono, H. Schulzrinne
>>>	Filename	: draft-ono-trust-path-discovery-00.txt
>>>	Pages		: 14
>>>	Date		: 2005-7-12
>>>	
>>>   Chained or transitive trust can be used to determine whether incoming
>>>   communication is likely to be desirable or not.  We can build a
>>>   chained trust relationship by introducing friends to out friends, for
>>>   example.  We propose mechanisms for discovering trust paths and
>>>   binary responsive trustworthiness.  The trust paths are based on a
>>>   chain of trust relationships between users, a user and a domain, and
>>>   domains.  We apply this model to relatively low-value trust
>>>   establishment, suitable for deciding whether to accept communication
>>>   requests such as emails, calls, or instant messages from strangers.
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-ono-trust-path-discovery-00.txt
>>
>>[end quote]
>>
>>None of these really work for spam protection, for the simple reason that all 
it 
>>takes is for a "reputed/trusted" machine to be taken over by a spambot zombie 
>>and then you start getting a flood of "trusted" spam.
>>
>>I recently read on another list that something like 84% of the spam one group 
>>received (that HAD SPF 'protection') was in fact spam...!  Of course, I've 
been 
>>pointing out for more than a year that SPF is stupid because it plain and 
simple 
>>DOES NOT SOLVE THE PROBLEM it's being proposed to solve.
>>
>>I really think it's shameful for these people to claim that these schemes are 
>>suitable for preventing or controlling spam when in fact they do little or 
>>nothing at all towards that goal.  :-(
>>
>>And, again, many of us have a legitimate need to receive unsolicited (or at 
>>least unexpected) E-mails from folks who will will not have on any kind of 
>>whitelist.  What I like about MY proposal is that it's content-specific... I 
am 
>>willing to accept more advanced forms of mail from specific people, depending 
on 
>>who they are;  but I'm willing to accept (subject to it passing approval by an 
>>additional antispam content filter, of course) at least a restricted subset of 
>>mail features in a preliminary contact, and that from just about anybody.
>>
>>Gordon Peterson                  http://personal.terabites.com/
>>1977-2002  Twenty-fifth anniversary year of Local Area Networking!
>>Support free and fair US elections!  http://stickers.defend-democracy.org
>>12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
>>12/09/00: the date the Republican Party took down democracy in America.
>>
>>
>>
>>_______________________________________________
>>Asrg mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/asrg

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections!  http://stickers.defend-democracy.org
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.



_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg