[Cryptography] ISPs caught in STARTTLS downgrade attacks

[Jerry Leichter]

On Nov 14, 2014, at 11:43 PM, Bill Frantz <frantz at pwpconsult.com> wrote:
>> that is, the only service that encrypted connections would break - is spam and malware detection.  And there are alternative architectures even there, and strong arguments for why such services belong at the endpoints, not in the network itself.
> I hope these alternative architectures which put the services in the end point include an economic analysis of the load of email that would be sent over cell phone connections with their limited "free" data.
"Not in the network" doesn't mean "in the phone".  Unless you're running an IMAP server or something like that in your phone, your mail is received by some system out in the cloud somewhere.  It can do - and probably already does - spam detection and such.  What it sees is "mail at rest" (often, "mail on its way to being at rest", but that's an implementation detail), which is *not* what what STARTTLS is about.

I will grant you that if you encrypt your mail at rest in such a way that the server cannot access the plaintext, you're giving up the ability to do spam filtering and such on the server.  Different patterns of usage have different tradeoffs.  The more generic computational power you assume at the user endpoint, the more you can potentially keep encrypted.  If all that's at the user endpoint is an arbitrary Web browser, there's not much choice:  The server has to have access to the unencrypted mail.  (It doesn't have to *store* it unencrypted, but it has to have access.)  A modern phone with an appropriate app could easily and safely decrypt mail that the server would have no access to, but you would indeed have to do the de-spaming on the phone - probably marginally possible because of power costs today, but you'd pay for the data transfer costs.  Once you get to a laptop with a WiFi connection, you can pretty easily do a decent job of spam detection at the endpoint.  (I rely on Mail.app's built-in spam detector, but some of my mail providers also do spam detection.  Where possible, I have them pass the messages through but add a marker.  To what degree Mail.app's detector is being triggered by the markers, rather than by intrinsic qualities of the message, I have no way to tell.  The combination works pretty well but has enough false positives that I manually check everything before flushing it.)

                                                        -- Jerry