At 1:01 PM -0500 2003/08/23, gep2(_at_)terabites(_dot_)com wrote:
Most of these recipients who allowed this worm to infect their
computer probably would NOT have had authorized those senders
to send attachments at all, let alone EXECUTABLE attachments.
I disagree.
That's mostly because you didn't pay attention to what I said, or didn't hear
the discussion on these points here before.
If you have a consent framework system, and the
dominant monopoly application vendor chooses to default to turning
off all security,
Points:
1) If all the security is turned off, it doesn't matter what type there was
or who turned it off... there's no security.
2) I've always proposed as key elements of my suggested consent system that
the default state (for unspecified senders) is to disallow HTML and to disallow
attachments. Recipients could turn enable HTML, and/or attachments, at their
option FOR SPECIFIC INDIVIDUAL SENDERS (or sender domains) and probably also
specifying WHICH classes of attachments they expect from any of those senders.
So if a user follows the "path of least resistance" they'll get only plain
ASCII
text E-mails, which are relatively easily handled by content filters.
by far the vast majority of users will leave it
that way. Thus, they would remain vulnerable.
Right basic argument, but reaching the wrong conclusion. Most users will leave
the default protections in place for most senders, only opening it up where
needed. Since *few* senders ever have need to send attachments (and
particularly even fewer needing to send executable ones!) it's a safe bet that
SoBig would have never achieved anything like this kind of wild success if the
great majority of its propagating E-mails went directly into the bit bucket.
This entire problem would have been a non-event even without a
consent framework system, if the dominant monopoly application vendor
actually paid any attention whatsoever to the issue of security from
a user perspective.
Actually, even if Outlook and IE and Windows were all "secure", I think one can
fairly argue that there are 'enough' clueness users of AOL's insecure client
software that there would still be a problem. The consent framework, and
default to removing (or better, intercepting entirely) HTML and attachments on
a
per-sender, per-addressee basis, really ought to be done at the ISP or domain
provider level.
I fully agree that Microsoft has done some pretty stupid crap over the years,
including enabling HTML by default, but a lot of other software suppliers
aren't
a whole lot better.
A consent framework system is neither a necessary condition nor
sufficient,
Nor is anything else, when you get right down to it. If there were an obvious,
100% watertight, 100% effective solution to these problems we wouldn't have to
have this list and be discussing all these different ideas... the problem would
have been fixed a long time ago.
But the consent framework that I proposed is still a simple, cost-effective,
user-comprehensible, surprisingly effective system that will put a serious dent
in BOTH spam AND malware, and moreover will do so in a way that is
incrementally
implementable and that offers a near-immediate payback to those who go to the
effort to put it in. That sounds to me like it covers a lot of the requisite
bases, and while avoiding nearly all the 'headaches' and implementation
barriers
that most of these other systems we've proposed are afflicted with.
unless it is a fundamental requirement of the most basic
kind of operations.
It ought to be offered by ISPs and domain providers, although interested
individual users could still set it up, I'd think, if the programming for it
were done appropriately.
However, such a system may be an enabler,
especially during a time of transition from an old system that
doesn't use it to a new system where it is integral.
I don't think you're going to see a worldwide transition to a totally new
E-mail
framework anytime soon. There are too many individual mail packages and too
much 'integrated' stuff already out there which adhere to the current standard.
However, to be truly effective, we have to make sure that we do
everything possible to create a system in which all possible
implementations default to "secure" mode, as opposed to "insecure".
That's the intention for the Secure Computing Initiative, which is what
Microsoft is calling their development effort.
It wasn't all that long ago that Sendmail (et al) all defaulted to installing
with open relays and such too, so it's not as if Microsoft is the only guilty
party in this industry.
Gordon Peterson http://personal.terabites.com/
1977-2002 Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment! Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg