North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

introducer trust model, Was: Eat this RIAA (or, the war has begun?)

  • From: Karsten W. Rohrbach
  • Date: Thu Aug 22 08:30:13 2002

Steven M. Bellovin([email protected])@2002.08.22 02:03:32 +0000:
> I assume you're talking about the Berman bill -- for the full text, see
> http://thomas.loc.gov/cgi-bin/query/D?c107:1:./temp/~c107Pidyhy::
> (it's not law yet).  Note in particular that although they have to 
> notify the Attorney-General of the technologies they intend to use, 
> the bill doesn't say anything about IP addresses.  Note also that the 
> technology list is confidential.
> 
> Actually, the entire text is pretty appalling -- but read it for 
> yourself.

hmmmmmmm....

all of the efforts to block/modify connections via adress based methods
(blackholing whole networks, bh based on AS, ...) are up to no avail,
IMHO. let their ``hacker'' folks just order a bunch of dsl lines
distributed all over the major providers, and those methods don't make
any sense.

the same problems apply to blocking incoming SMTP connections, or mails
from/to specific addresses, SPAM.

thinking a little bit more about the issue with networked services in
general (including SMTP and the spam/abuse problems, as well as
filesharing and many more), the conclusive decision would be to define a
bullet proof standard on introducer based trust, deriving a certain
trust level or metric from a peer-trust based trust chain. this has
several (dis)advantages:
- no central authority involved, nobody will charge your creditcard for
  issuing a certificate
- somewhat more unsharp but still pretty restrictive method of applying 
  permissions to use resources
- follows the basic paradigm behind TCP/IP, delivering a
  never-lights-out trust model that cannot be compromised easily, if it
  is good in design and implementation

i am not an expert in this field, but i think that a generic standard
for this kind of trust model is long overdue, the only application
nowadays out there in the wild using it being pgp's model of the web of
trust. 

creating such a generally applicable model of introducer trust, starting
from design over implementation of a portable library that does it all,
up to plug-in extensions to existing software (like hooking it up to
SMTP greetings of the major flavours of MTAs, adding it to certain
protocols, like HTTP, where it could easily replace most HTTP-Basic-Auth
style systems of most community sites, like adding it to say gnutella's
protocol, etc.) would solve a whole bunch of problems we all got today.
with a certain amount of engineering effort, it might be applicable to
IPSEC, too.

of course there will be new problems that arise, and we need to take
them into account. together with a bunch of folks that feel theirselves
at home in the networked services, PKCS and protocol areas, there should
be an (half)open discussion, to pave the road to get such a thing on
track. this won't be an easy or short term project. also, i'm quite sure
that there has been done quite some research in this field, being open
or closed source/papers already, which should be aggregated to see the
big picture.

suggestions welcome, tell me what you think, even if you think that it's
a moronic idea (in any case, the ``why'' is the important point)

regards,
/k

-- 
> In protocol design, perfection has been reached not when there is nothing
> left to add, but when there is nothing left to take away. 
> --Networking truth #12, Ross Callon, RFC 1925 
WebMonster Community Project -- Reliable and quick since 1998 -- All on BSD
http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.de/
GnuPG:   0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4  A113 B393 6BF4 DEC9 48A6
REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE  DF22 3340 4F4E 2964 BF46
REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C  5F 0B E0 6B 4D CD 8C 44
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 10x

Attachment: pgp00022.pgp
Description: PGP signature