[Cryptography] Facebook on the state of STARTTLS

[Joe St Sauver]

Hi,

Eric asked:

#Could you explain why CA certs are futile for SMTP? It's not immediately
#obvious to me. (I'm new to STARTTLS, have never configured it.)

I wouldn't say "futile," but I would say that there are some challenges.

Some of the challenges I see include:

-- Quick: what trust anchors does/should your favorite MTA trust? (This is
   not meant as a glib question, it's a real issue and not one that's
   easily solved. I'd love for the CAB Forum to come up with a consolidated
   list that EVERYONE agrees to trust, but so far I don't see much sign of
   that ever happening). If Exim and Postfix and Qmail and proprietary
   vendors A, B, C and D don't agree, I predict problems may arise.

-- Are all globally trusted certs equally acceptable? E.G., is a $10 domain
   validated cert is on par with a multihundred dollar "extended validation"
   "green bar" cert, at least for email? 

-- Assume there's a problem with the cert you're offered. What do you do?
   If you programatically reject the cert as unworthy, do you send the 
   traffic in plain text? Do you queue the traffic and try again? For how
   long? Once that timer runs down, what then? 

   Or is ANY sort of crypto arguably better than NO crypto?

-- Mail delivery is hop by hop. What if the cert for the first hop is okay,
   but the cert for the 2nd hop (or the 14th hop) is flawed? How do I know
   that subsequent hops even care about opportunistic TLS?

-- During the mail delivery process, a site may legitimately route its
   traffic through an intermediary site (such as an anti-virus or anti-spam
   service). How can I distinguish between a legtimate site of that sort,
   that should be trusted to handle email for my recipient, and an evil
   MITM site that's going to violate my privacy and pervasively monitor
   my traffic? Is there any notion of domain matching on certs used for
   SMTP, as there is for certs used for web SSL/TLS? (certainly you can
   check to make sure the cert matches the host it's on, but how do you
   know that host should be in the delivery path?)

-- Assume I'm an SSL/TLS-savvy user, and I'd like to know if my email
   followed a 100% SSL/TLS-protected path. How is that currently signaled
   to me? 

-- What if as a sender I want to express a policy preference (hypothetically,
   if at any point you CAN'T negotiate an SSL/TLS connection, silently
   drop the message, perhaps) how would I signal that to the mail delivery 
   path currently? (FWIW, I don't think that sort of signaling is currently
   possible)

-- If a recipient has multiple MX's, how do I know which of those is most
   secure? Should I be able to tell?

-- Does it make your spine tingle to think about a dozen or more 
   opportunities for email to be decrypted, queued, encrypted and sent
   on? Do we know that each of those intermediate hops isn't an opportunity
   for traffic monitoring? Wouldn't an end-to-end option be a nicer
   alternative? Should we be working to increase uptake of PGP/GPG (or 
   S/MIME, or ...)

These are some of the issues that I think we're going to need to tackle
at some point.

Regards,

Joe

Joe St Sauver, Ph.D. (joe at oregon.uoregon.edu)
http://pages.uoregon.edu/joe/

Disclaimer: all opinions strictly my own