The future of security
Anne & Lynn Wheeler
lynn at garlic.com
Fri May 28 12:44:17 EDT 2004
At 09:27 AM 5/28/2004, Peter Gutmann wrote:
>No they won't. All the ones I've seen are some variant on the "build a big
>wall around the Internet and only let the good guys in", which will never work
>because the Internet doesn't contain any definable inside and outside, only
>800 million Manchurian candidates waiting to activate. For example
>MessageLabs recently reported that *two thirds* of all the spam it blocks is
>from infected PCs, with much of it coming from ADSL/cable modem IP pools.
>Given that these "spammers" are legitimate users, no amount of crypto will
>solve the problem. I did a talk on this recently where I claimed that various
>protocols designed to enforce this (Designated Mailers Protocol, Reverse Mail
>Exchanger, Sender Permitted From, etc etc) will buy at most 6-12 months, and
>the only dissent was from an anti-virus researcher who said it'd buy weeks and
>not months. The alternative proof-of-resource-consumption is little better,
>since it's not the spammers' resources that are being consumed.
the caveat to that is many of the infected machines were originally
infected by spam with spoofed origin ... somehow convincing users to click
on something. authentication would help somewhat with that ... and, in
fact, some of the spam being sent out by the infected machines, in turn
uses spoofed origin. authentication might also help address the
identity-theft oriented spam ... claiming to be your bank and needing
personal information.
it doesn't help with ... click on this to get the latest, greatest game ...
where there isn't any attention at all paid to the origin ... just looking
for instant gratification.
the 60s/70s time-sharing systems nominally had some assurance applied to
the introduction of executables into the environment. this is my comment
about the desktop systems having diametrically opposing requirements ...
the original design point of totally unconnected, stand alone environment
where an introduced executable could take over the whole machine ... and at
the same time fully wired to an increasingly hostile environment needing
signficant safeguards and processes associated with assurance of introduced
executables. the intermediate step was that some of these stand-alone
machines acquired interconnect capability for a local, safe, isolated
departmental/office network. This had hardly any restricted execution and
access capability ... again not worrying about protection against a hostile
and unsafe operation.
the shared environment analogy is highway traffic and rules about operating
an unsafe vehicle could result in both having your license revoked and the
vehicle confiscated (it doesn't require the driver to be a highly trained
car mechanic ... it just holds the driver responsible).
connecting systems that were designed for fundamentally safe and isolated
environment to wide-open anarchy hostile operation exposes all sorts of
problems. somewhat analogous to not actually needing a helmet for riding a
motorcycle ... or seat belts and airbags to drive a car.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list