Re: [Asrg] 0. - General - Consent and SoBig

[[e-mail]]

>At 1:01 PM -0500 2003/08/23, [e-mail] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg