Eat this RIAA (or, the war has begun?) - Why not all ISPs?

Mailman List Mirror (Read Only)
1

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.

    --Steve Bellovin, http://www.research.att.com/~smb (me)
    http://www.wilyhacker.com ("Firewalls" book)

2

Steven M. Bellovin(smb@research.att.com)@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

3

[snip]

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

What you're proposing sounds rather like the PGP Web of Trust
<http://www.gnupg.org/gph/en/manual.html#AEN554>. An excellent idea, but
difficult to build. Until a trust model of this type reaches a certain
critical mass, it has little effect on those outside the model. I've already
done my part by signing my friends' keys and having them sign mine, but until
a critical mass of users begin to sign mail by default (and then start
signing each others' keys), the web of trust doesn't have much weight outside
those involved in it. That is to say, we can't exert much pressure on those
not in the web.

We end up in a situation akin to the much-debated SMTP extensions/rewrite -
good ideas that will likely be impossible to adopt with any success.

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.

Oop, there you went and mentioned it directly. I hadn't read that far yet. To
my knowledge, the PGP web of trust is the only model of its kind that has
enjoyed even a limited success to date.

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.

The only problem that really bears consideration is adoption. Until the users
(in AOL or Microsoft quantities) adopt a thing, it will have little market
power (whether your market is financial or technical). Compared with the
adoption problem, the engineering details are trivial.

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)

Good idea, but very likely impossible to implement effectively. At any rate,
a mailing list for such a thing might not be a bad idea.

4

...
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. ...

A friend of mine recently started Habeas (see http://www.habeas.com/) and
since I have no financial or operational connection to them I feel pretty
free to state publically that there are non-web-of-trust introducer models
available which might pan out pretty well even though they're profitable.