STARTTLS and sp*m

[Tim]

Hi Michael,

> > OT: Is that really sane?  
> Got to start somewhere.
> > What is your goal in using TLS with email? 
> Prove out interoperability of various MTAs.  Annoy the men in the
> middle. See who else has implemented TLS. And: To hope that a sufficient
> number implement it to one day turn the knob up to the next level.

Sure, that makes sense, and is a valiant effort.  I use IPv6 and am on
this mailing list for similar reasons.  I just wanted to make sure there
was no false sense of security there for you or others.

> >  It really is an all-or-nothing venture, using
> > TLS in this case.  Opportunistic encryption here provides no security
> > without authentication, and merely slows down communications all the
> > while providing a false sense of security.
> >
> >   
> It's not quite that black and white, as per above and below.

Well, if you're interested in actually preventing someone from reading
or modifying mail on a point to point link, this really is pretty black
and white.  No point in arguing it more. I've performed my share of MitM
attacks, and in this particular protocol there are several very
effective strategies if the end points try to be forgiving about
STARTTLS support.  It's just like connecting to SSL sites and clicking
"OK" when the certificate is blatantly invalid.  No security there
either; just a pointless exercise in scrambling bits.


> Anything that increases the computational or memory footprint of a
> spambot aids detection and removal. Also, known spammer certs could be
> blacklisted just as we blacklist via rbls. Generating new certs takes
> non-trivial time and cpu.

I disagree.  If it costs you X to implement the strategy, and it costs
the spammer 1.1*X (or worse yet 0.5*X) then I don't see the benefit in
the long term.  The additional effort on the part of the spammer should
be of the form X^2 or X^3 or 2^X for the approach to be viable IMHO.

As for blacklisting certificates, this is trivial to get past since
spammers can simply generate new ones.  I'd imagine certificate
generation can be quite fast if you're not interested in using secure
PRNGs.


> My point about IPv6 and SMTP was not that IPv6 had anything in it that
> made the spam problem simpler, it was that the current number of the
> ipv6 email MTAs  was small enough to perhaps develop some "best
> practices" - something more coherent to cope with email issues such as
> spam, authentication, crypto, etc, etc.

Yes, I don't disagree with this.  While IPv6 in and of itself will not
change the spam problem, we have an opportunity to start fresh with
different approaches.  This would require a fundamental shift in how
mail is moved.  If something like IM (XMPP?) is really the next big
thing, it's got to overcome the same hurdles.

One approach of course is something like Internet Mail 2000 (god I hate
that name).  Make the sender store all outbound messages on their server
for later retrieval. Requiring spammers to actually host the content for
a long period of time shifts a large part of the resource constraints to
their end and I would think could solve lots of problems.  For instance,
playing shell games with sender IPs to avoid black lists would be much
harder.

> This is pretty OT for this list, but solving it here would help increase
> ipv6 adoption.

That's an interesting point, and worth more consideration.  What if a
streamlined, updated IM2000-like protocol were standardized (and
implemented) for IPv6?  Maybe only for IPv6 and not IPv4 to really
provide incentive?

Anyone else have thoughts?


> The goal is to expend less effort on defense than the bots can spend on
> offense.

Well, sure.  Unfortunately the bot nets will always be bigger than us.
Any effort we put in must require exponentially more effort on their
part for it to be effective.


cheers,
tim