[linux-l] RFCs und Vorschlaege...

Kendy Kutzner kendy.kutzner at e-technik.tu-chemnitz.de
Mi Okt 8 09:56:53 CEST 2003


On 2003-10-08T01:42:03+0200, Steffen Dettmer wrote:
> Ich bin der Meinung, daß das WebOfTrust nicht funktioniert.

> Fetzt der Angriff, oder? Ich find den Klasse :-)
> 
> Hab ich was übersehen?

Meiner Meinung nach ja. Zum ersten kostet die Erzeugung von
Schluesseln relativ viel Rechenzeit, es ist demnach nicht
praktikabel fuer jede spam-mail einen neuen Satz von Schluesseln
zu erstellen. 

Zum Zweiten ist die vergroesserte Pfadlaenge feststellbar. Die
durschschnittliche Pfadlaenge heutiger PGP-Schluessel ist 4-7.
Eine Verlaengerung von 4 (oder wie Du schriebst in einem Fall
sogar 10) ist ein Achtungszeichen. 

Zum dritten wuerden, falls jemand das von Dir beschriebene System
einsetzt, schnell bessere Reputationssystem aufgebaut als wir sie
heute haben. Folgender (aus der hohlen Hand geschossenener)
Vorschlag: Jeder Schluessel erhaelt ein lokales Punktekonto. Fuer
jede eingegangene legitime Mail erhaelt dieser Schluessel 10
Pluspunkte, alle Unterschreiber zusammen ebenfalls 50+ (dh. bei
25 Unterschriften fuer jeden 2+), evtl. alle Unterschreiber der
Unterschreiber nochmal 100+. Fuer jede eingegangene nicht
legitime Mail erhaelt der Schluessel 20-, alle Unterschreiber
zusammen 100- usw.. Damit wuerden auch Deine 900 nichtbenutzten
Schluessel schnell bei hohen Minuszahlen landen und die Sache
waere filterbar.

Mein Fazit: Dein Verfahren macht beides, Spam-Senden und
Mail-Empfangen aufwaendiger.

Da auch hier immer mal wieder neue Verfahren zur spam-Erkennung
und fuer das "viel-besser-als-smtp" Mailsystem auftauchen,
moechte ich eine Mail von der Full-Disclosure Mailingliste
zitieren.

Kendy


From: Valdis.Kletnieks at vt.edu
Subject: Re: [Full-Disclosure] [LONG] Improving E-mail security...
Date: Wed, 27 Aug 2003 00:37:07 -0400
Cc: full-disclosure at lists.netsys.com

On Tue, 26 Aug 2003 23:05:15 EDT, "lceone at comcast.net" <lceone at comcast.net>  said:

[....]

> So maybe it would be in the best interest of the internet community if
> someone stopped and took a look at what the requirements for a good
> communications protocol to replace email would be, and tried to put one
> together from the ground up.  Security, features, and all.  Heck, if I
> can get a group together, I'll take a crack at the darn thing myself.

See the asrg at ietf.org mailing list: https://www1.ietf.org/mailman/listinfo/asrg

Make *very* sure to read the archives before proposing a Brilliant New Idea, as
most of them have already been proposed and then  torn to shreds by people who
run major mail servers for a living.

https://www1.ietf.org/mail-archive/working-groups/asrg/current/maillist.html

Quick guidelines:

1) Make sure your scheme interoperates with itself - for instance, many
challenge-response systems lose here because they deadlock if they encounter
another site running themselves.

2) Examine if your scheme still works if *everybody* does it - for instance,
many "look for this header as spamsign" schemes don't work because spammers
will just change what they do (which is why SpamAssassin keeps shipping new
rulesets - this is NOT a long-term sustainable scheme).

3) Examine if your scheme works when only a few sites have deployed - if it
requires near-universal deployment to work at all, make REALLY sure you discuss
bootstrapping issues.  If you require that AOL, MSN, Yahoo, and the next 4
largest providers all convert their entire user bases *before* you have
critical mass, explain the business logic - in particular, why should one of
those 7-10 sites deploy (with associated expense) without a *guarantee* that
their competition will do likewise?  Why should anybody buy into this if
they're still going to be dragging a legacy-SMTP gateway along until 98% of the
OTHER sites have converted, and said gateway is going to be leaking in spam the
whole time anyhow?

4) Examine your scheme for cost/benefit issues - any scheme where the cost is
born by one end but the benefit is at the other end will have trouble. For
instance, HashCash is a tough sell because the *cost* (cpu in this case) is
born at the sender end, but the *benefit* (rate-reduction of non-whitelisted
mail) is born by the reciever.

5) Examine how your scheme works under scaling - does it Do The Right Thing for
40 million domains and billions of pieces of mail a day?  (Hint - a centralized
server of *any* sort doesn't work, and even DNS is *barely* distributed enough.
If you use DNS for your scheme, make sure to think about things like lame
delegations, timeouts, and similar, and what they do to workability and
perfomance).

6) Examine how your scheme works for actual operational deployment. The two
most common questions are:  (a) Does it Do The Right Thing with mailing lists,
and (b) Does it Do The Right Thing for "Aunt Tillie"?

7) Examine how your scheme works in a non-trusted environment, and note that
there's a lot of distrust on *everybody*'s part.  Some of us don't trust
Verisign (and can point at specific reasons not to, including a CERT advisory),
some of us don't trust another country's government, and there's even some that
don't trust their own government.  (Would you want the US Postal Service to be
your e-mail provider? Why or why not? ;)

8) Examine how your scheme works in a worldwide context, paying attention to
any legal/legislative/jurisdiction issues.  If your solution involves passing a
law, explain how you get it to apply to a site in the Cayman Islands or
Havenco.

9) Actual operational experience and a thick skin are two large bonuses - if an
idea isn't scalable, you may very well be told in excruciating detail why it
*won't* work for an AOL-sized site by somebody who knows what *does* work for
that sized site because he helped design it....

(And that list is a good explanation of why the ASRG hasn't come up with The
Grand Solution either... :)


-- 




Mehr Informationen über die Mailingliste linux-l