STARTTLS and sp*m (was: Re: current usage of AAAA implicit MX?)

[Tim]

> (Postfix has a sane setting:
> "smtpd_tls_security_level=may") which  tries initiating TLS if a
> STARTTLS offer is recieved, then falls back to plain text if that fails)

OT: Is that really sane?  What is your goal in using TLS with email?  Is
it to protect the contents?  Authenticate the source server?  If an
attacker wanted to read the mail and STARTTLS wasn't required, he could
just strip that option from the initial conversation and Postfix would
accept the cleartext communication.  What's the point in supporting
STARTTLS again?  The same goes for man-in-the-middle attacks with
unvalidate certificates.  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.

Do I use STARTTLS?  Sure, but I require it's use between hosts I have
authenticated.  Do I allow opportunistic encryption with it?  Sure, but
only because it causes mail to be stamped with a few key words that my
bayesian filters might benefit from.  My point is, once the spammers
feel TLS will help them, they'll just connect and anonymously spam with
TLS.  We're in the same boat.


> With IPv6 perhaps we could convince a bot-battered world to get email
> working "right" this time.

I'm all for that, but unfortunately there isn't much fundamentally
different about SMTP over IPv6.  More on that in a minute.

> If they took the plunge now, it would be worse than eternal september;
> it would be "bot heaven", as the existing rbl mechanisms would fall over
> and die.

Well, yeah, if a lot of ISPs and other services started supporting IPv6
but had no RBLs to support it, there would be a problem.  I imagine any
large mail provider that took the plunge would have some mitigations in
place before doing this though.

> Greylisting helps, but the explosion of email address/ipv6 tuples would
> swamp most databases. Perhaps weaker greylisting, based solely on the
> email address, would help.

Greylisting itself works ok right now, but slows down mail and I suspect
will become less effective in the future.  If everyone were using it,
the bots will just try multiple times.  It's inherently a tit-for-tat
game.  You're shooting yourself in the foot a little bit right now
(slower delivery of initial email, having to track sources, etc) and
it's currently working because most spammers aren't bothering to get
past it.  When they do try to do it, their bots will only be getting
hurt as much as you're hurting yourself (within a costant factor of
course).  At that point, one might as well throw it out.

> Pushing back the MTA into the clients (most linux distros still include
> a MTA by default) would shrink the list of available recipients to
> manageable levels on the client at the expense of hoping for correct
> configurations on zillions of clients...

Not sure what I think about this, theoretically, but I don't see it
happening anytime soon.

> Requiring all email connections be auth/crypted via starttls would (at
> the very least) increase the footprint of an ipv6 capable bot... but
> would annoy certain agencies of 3 letters....

See above.  The 3 letter agencies wouldn't be bothered much, since they
can just MitM stuff if they really need to with most server
configurations.

> On my bad days I tend to write off email as a good idea overwhelmed by
> events, and that we should just give up on it, and outsource it all to
> gmail et. al.

It is becoming increasingly painful, isn't it?

> Rotating mail servers around a set of ipv6 addresses, and
> updating/expiring the mx record appropriately would "secure by
> obscurity", making it much harder for a bot to find a working relay in
> the first place, and ensure that only MTAs that actually look at MX
> records get mail out - (however this technique could also be used by the
> bad guys for sending mail, and makes greylisting harder)

Ok, so try taking this idea to the extreme.  That's what I did for my MS
thesis not long ago [1].  Here's a brief outline:

If you don't select an obvious IPv6 address for your mail server, then
the bots won't be able to scan the addresses to find port 25.  They
*must* use the DNS in order to find hosts.

Now suppose you can dedicate a /48 to your mail server.  What if the
remaining 80 bits were actually an encrypted cookie generated by your
DNS server?  This encrypted cookie could contain information about what
DNS resolver IP address (to an approximation) requested the MX/AAAA
record.  It could also store a time stamp to guarantee proper expiration
of the cookie, and even have room left over for a few flags and a
checksum.

Once a port 25 connection comes in to this IPv6 address (48 bit prefix
plus 80 bit cookie) your firewall decrypts it, checks the source DNS
resolver for it's level of "evil" and possibly grey/white/black lists
based on that and possibly other information.  I haven't really thought
through the best approach for this part, but there's the teaser.  It
essentially gives you more information about /who/ is initiating the
connection, since now you have an idea of where they got the DNS record
in addition to what their actual source IP is.

Is this approach complicated?  Yes.  Does it require nasty NAT?  Yes.
Is there a reliable real-world implementation of this system? No.

The up side is that you can use this general approach for a whole host
of other things, including completely transparent port knocking (i.e.
white listing based on requested DNS record), and it can help a bit with
spoofed DoS attacks.

Anyway, this all tries to take into account the only inherent difference
between running services on IPv4 and IPv6: the size of the address
space.  Everything else seems to be a lost cause to me, unless there is
a big change to some RFCs.

Maybe we could do something completely tangential to IPv6 and require
DKIM or something in the RFCs whenever we use SMTP with IPv6.  Doubt it
would fly though.

Sorry if this was too OT.
tim


1. http://www.sentinelchicken.com/research/tdm_ms_thesis/