[liberationtech] The missing awareness: SMTP Security Indicator in Email|WebMail clients

[carlo von lynX]

Thanks for taking on the challenge to discuss things for real.

On Mon, Nov 02, 2015 at 07:11:00AM -0500, Rich Kulawiec wrote:
> On Sun, Nov 01, 2015 at 06:42:23PM +0100, carlo von lynX wrote:
> > Let's frame the threat models. Bulk collection probably does 
> > not include using OS backdoors so the suggestion to use mutt
> > on BSD isn't wrong, but not necessary to move a step forward.
> 
> And why not?  If the endpoints aren't reasonably secure, then what happens
> in the middle doesn't matter.  We *could* completely re-architect SMTP
> from scratch, design and build in as much security as we possibly can,
> but if someone foolishly insists on using Windows or a smartphone to
> send/receive mail, it won't matter a bit.  (I trust everyone is aware
> that Windows 10 is spyware pretending to be an OS.  It doesn't *have*
> to be backdoored en masse, it ships that way from the factory.  And
> "smartphone security" is essentially an oxymoron.)

Certainly the way Windows is systematically imitating the G-Mail success
model by running everything you do and type through advertizement models 
is terrible. Are Android or iOS already sending everything back home?
AFAIK only Microsoft is trying to take back the lead in the race to the
bottom of civility.

As long as those OS's do not systematically send keylogging data back
to their homebases, an attacker doing a targeted attack to get at the
stuff would be visible in the traffic - thus it is not as low hanging 
fruit as bulk sniffing of TLS as seen with BULLRUN.

> So at this moment -- without a completed, peer-reviewed, implemented
> replacement for SMTP globally deployed -- the single biggest things that
> end users can do are (a) use a hardened OS (b) use a hardened email client
> (c) do not use webmail (d) do not use freemail providers.  These are easy
> steps well within everyone's reach.  They don't solve all the problems
> (and they don't try to) but they tackle the obvious/easy ones.  They raise
> the bar for attackers and they only require using things *that already exist*.

That's all true, but the bulk of mail traffic is still unencrypted...
And when it isn't, it resides on mail servers that are usually not
so very hard targets. So this is the threat order I would guess:

1. SMTP + X.509
2. your OS, especially if you didn't read the T&C of Windows
3. the ever luring Web
4. vulnerabilities in GUI mail clients

> > Do the new "Received" headers really reflect such info
> > and how would you explain what certain headers mean to
> > the end user?.. given the "Received" headers are accurate,
> > as questioned in previous mail.
> 
> I'm not questioning them, I'm pointing out that the hard cold
> reality is that you CANNOT trust any that weren't put in place
> by your own MTA.  Period, full stop, end of discussion.

So Alice sends a mail to her server. That server forwards it
to a mailing list server, adding a header about the fact that
the mailing list server was found to have an invalid certificate.
The mailing list server may forward this header or even delete
it. When Bob picks up his mail, he finds Alice wrote to the
mailing list. No reasonable way to find out, that she got MITM'd.
There may be traces of information in some untrustworthy
"Received" headers, but they could also be intentionally put
in there by the evil mailing list server to cause confusion.
At least that would be the threat model if you say "full stop.
end of discussion."

> Here's an example from this morning, reformatted for readability.

Thanks you for the nice example. I'm sorry you elaborated so much
on this, but I hope some other readers didn't know about these
problems yet and have gained knowledge this way.

> So before we even get to the question of whether or not that putative
> prior hop was via TLS, we have to answer the question of whether or
> not that hop *even existed*.  And we can't, because we are not in
> possession of the information necessary to do so.

Correct. Still it makes no sense for benevolent nodes to fabricate
false warnings about insecure TLS usage. Question is if it makes
sense for malevolent nodes to do so, maybe in order to distract
from something else.. or if it doesn't make sense for them either.
If it doesn't, then warnings in "Received" headers are useful even
if they aren't securely delivered.

> The sad reality is Paranoia is
> worse than nothing, because it relies on information that can be
> and quite often is wrong or fabricated.

You're probably right. Sorry, naif.

> > It's less work to design a new mail system from scratch
> > than to reduce the insecurities of SMTP from 31 to 30.
> 
> If you want to write a draft for SMTPv2 (or whatever it's going to
> be called) and submit it to the IETF, I commend your efforts.

Revolutions never came out of the IETF. I know. I've been
there, I've worn that t-shirt myself.

The next not so simple mail transfer protocol needs to be
so dramatically different, it doesn't even make sense to
name it similarly:

- it must protect content and metadata, by design.
- no server federation: it has to work with agnostic relays
  like tor. yet it needs to be able to store & forward
  messages without knowing from whom and to whom.
- it needs to have a trustworthy strategy for discovery of
  authentic public keys.

That's why secushare provides a mail system using distributed
routing and storage on gnunet relays and discovery over the
private social graph. If seven of my friends say XXYY is your
public key, I assume that is your public key and can mail to
you rightaway. The UX therefore is simpler than Facebook, yet
the result is end-to-end authenticated encrypted untraceable
communication.

The only problem with making a near perfect new mail system
is that it needs more voluntary help - because there can be
no revenue model for constitutional basics. And IETF is full
of hawks that would hate their revenue model go up in fumes
because suddenly there is a safe mail system that just works,
without any need of maintenance.


-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/