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