I think this is a good move that establishes a useful foundation, building on the work that Google has done thus far in their Safer Email effort. The quality of the security depends on the implementation details, but being Google, I would expect the Gmail team to have considered these issues carefully, and to have a plan for the future.

There are a number of short term and long term benefits. A few years ago, a significant majority of all email was transmitted in plaintext. Google's Safer Email Transparency Report called attention to this, and provided an incentive for ISPs to enable opportunistic TLS and increase their TLS percentage to 100%. This first step appears to have had a meaningful impact on the amount of TLS employed by large senders and ISPs.

At this point, however, messages appear identically to email receivers, whether sent across TLS or not. This report alone was not enough motivation for all large senders and ISPs to employ TLS. Much like how websites with the "lock icon" have a privileged status in browser UIs, the next step of displaying the TLS status (or lack of TLS) in the UI will provide an incentive for senders to employ it.

Employing more TLS today is a benefit even as things stand. Opportunistic TLS protects against passive eavesdropping, which is still a win, and it allows you to detect active MITM interception with scrutiny: MITM interception will leave a permanent trail in message metadata. Plus, one only needs to employ a basic degree of path validation to deter most casual MITM interception (based on self-signed certificates). Gmail could establish tiers of trust, analogous to the types of HTTPS lock icons, and require senders to use a properly path-validated client certificate from a generally trusted CA in order to achieve the highest degree of trust, analogous to the lock icons in HTTPS. The STARTTLS protocol anticipates this kind of authentication [1], but does not specify it:

> Both the SMTP client and server must check the result of the TLS negotiation to see whether an acceptable degree of authentication and privacy was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document.

I would expect Gmail to raise the bar over time. This initial effort creates an incentive to roll out opportunistic TLS, even if poorly implemented such as with self-signed certificates. Simply getting TLS in place universally will be a great starting point for further refinement.

Over time, I'd expect to see additional features such as, perhaps: (1) incentives to use path-validated certificates from a trusted CA, over self-signed certificates (2) mechanisms for sending domains to declare what kind of certificate and TLS they'll use when sending, such that receivers can validate TLS connections and reject invalid client certificates. There was some talk in the past about adding this to the DMARC standard, but that fizzled out. There is another effort toward establishing a convention for this by applying DNS-based Authentication of Named Entities (DANE) to SMTP [2]. Although the existing DANE SMTP protocol only establishes a convention for server authentication and not client authentication, there is still value for senders, and I expect work to progress toward client authentication over time. Protocols aside, Gmail could also establish their own conventions, out-of-band mechanisms, or tiers of authentication, like browsers have for EV certificates. We might also see (3) better support for grappling with identity alignment, i.e., emails from example.com are expected to be sent across TLS using an example.com client certificate (perhaps not necessary given DKIM).

In the interim, Gmail can add metadata to the message that captures the client certificate used to transmit the message. A security-conscious receiver can inspect those details, perhaps using a plugin or with a visual scan. It would not be so hard to build a plugin that pins certificates or expected CAs for popular domains, for example.

To summarize, I think this is useful and is heading in the right direction. It's not a complete solution, but it's difficult to go directly from where email is today to a complete solution.

[1] https://tools.ietf.org/html/rfc3207 [2] https://tools.ietf.org/html/draft-ietf-dane-smtp-01