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