Google’s recent announcement that they’ll be adding encryption (TLS) and authentication (DKIM/DMARC) status icons to Gmail is a great initiative.

What they do

In addition to being displayed for received email, the encryption indicator works when composing email as well. It’s however not updated in realtime, and seems to be cached per domain. For example, a warning is displayed “@cox.net”, but not for “@coxhomesecurity.com”, despite pointing to the same MX. We haven’t been able to verify how long it takes for the warning to display; after setting up a new (non-TLS) domain one day ago and sending numerous email to it from different Gmail accounts, the warning is nowhere to be seen. We presume that the sessions of sent email are being used is material, since we didn’t record any additional probes/callouts to our test server.

I fully appreciate Google’s rationale behind displaying a red broken lock icon when TLS is absent, rather than a green lock when it is used; I just wished they addressed the shortcomings of non-authenticated TLS and took a stance on how we could move on to proper email encryption.

The problem

As I discussed in a recent blog, TLS is widely deployed for email, but virtually no-one is doing verification (checking authenticity). In the case of a web browser, TLS without verification triggers a warning (such as a red lock). It might be confusing for users that a similar symbol in Gmail indicates something different. In my opinion, there should have been at least an explaination or comment that non-authenticated (opportunistic) TLS doesn’t protect against active attacks (eavesdropping, downgrade, etc).

The main issue, of course, is that there’s currently no widely deployed mechanism for SMTP TLS name verification. This stems from the fact that email is security-agnostic (unlike the web, where you type “https://”) and that the DNS MX structure makes normal CA-based name verification ambiguous.

What they could do

The most promising technology right now for proper, verified encryption (TLS) is probably DANE, which builds on DNSSEC. It’s already implemented in Postfix (the second most popular email server) and (of course) Halon. Furthermore, many European providers and operators have either deployed, or is planning to deploy, DANE. It even serves as a cornerstone for Trusted Email Services initiative.

While its dependency on DNSSEC is likely hampering adoption, I’m encouraged by its strong community support. It feels like widespread email encryption is finally within reach!