I was horrified when I woke up this morning and discovered Microsoft’s positioning in this Electronic Frontier Foundation (EFF) article (republished by Gizmodo) on encryption.  Of course, that’s because it was EFF’s intent to shock vendors into action.  Or rather, to shock their customers into demanding action.  The question is, to what extent does this chart of EFF recommendations really matter right now.  And in Microsoft’s case, why might the chart not be as damning as it looks.  And even after addressing all that, given its Trustworthy Computing efforts, should Microsoft be a leader on this issue rather than a follower?

The chart contains three HTTPS/TLS usage recommendations that Microsoft doesn’t currently support.  Let’s start with outlook.com’s lack of support for STARTTLS.  STARTTLS is a way to automatically upgrade a non-encrypted connection, primarily for the POP3 and IMAP email protocols, to encrypted connections.  This sounds like a great thing and I do believe all email systems should support it wherever relevant.  However, how much does this matter in the case of outlook.com (aka, Hotmail)?  Not much.

Outlook.com’s primary communications protocol is the always encrypted EAS .  It offers POP3/SMTP support for two things.  You can use POP3/SMTP to access your outlook.com email, but it requires you to specify an encrypted connection (TLS).  There is no support for the use of unencrypted POP3/SMTP connections and thus STARTTLS is irrelevant.

The second place POP3/SMTP is used is to pull mail from another email provider into outlook.com.  Of course you get to specify if you need/want a TLS-encrypted connection to the other email provider.  And here is the interesting bit, just like outlook.com they can require an encrypted connection.  Most importantly, it is safe to say that if they support STARTTLS (and few do) then they also already support the use of an encrypted connection.  If they don’t mandate the use of TLS it is to support legacy clients that can’t use TLS, and so wouldn’t support STARTTLS in any case. Which leaves exactly one scenario where STARTTLS would help.  It would prevent you from miss-configuring outlook.com’s access to another provider’s email system when they allow unencrypted POP3/SMTP.

STARTTLS for outlook.com is a limited scenario ease of use enhancement and not a fundamental, or even modest, improvement in the security of email.

Next up is HTTP Strict (HSTS), a proposed standard that was published a year ago.  HSTS is definitely something that every server and client should support as way to move towards fully encrypting web traffic.  But HSTS also has a limitation that needs to be addressed outside HSTS itself.  What HSTS does is let a server force the client (e.g., web browser) to switch a connection from the non-secure HTTP to the secure encrypted HTTPS.  Of course many web sites do this already by having a non-secure web page redirect to the secure web page.  The hole in the redirect scheme is that the initial connection to the web server is non-secure and can be hijacked.  The limitation of HSTS is that it doesn’t address this hole.

I suspect Microsoft’s lack of support for HSTS is related to both the newness of the standard and the need to come up with a, currently proprietary, means of addressing the initial connection problem.  On the former point the development of Windows Server 2012 R2 (for IIS support), Windows 8.1, and IE11 began before RFC 6797 was approved for publication as a draft standard.  Microsoft could have chosen to work with the unapproved draft, but that would have added risk to an already very tight schedule.  More importantly, implementing HSTS without addressing the initial connection problem was likely felt to be a losing proposition.  Google addressed this latter problem by having Chrome load a list of sites known to require HSTS into the browser.  But that is not a scalable solution (imagine having to load a list of 100s of thousands or millions of sites).  Microsoft may have decided it was better to wait for a cleaner solution, preferably one with industry support.  For example, an ideal solution (well, ideal if DNS security is addressed) would be to have sites mark in DNS that they use HSTS.

One note about solving the initial connection problem vis a vi IE is that Microsoft already has a mechanism in place for managing lists in the browser just like Chrome is using for this.  The Compatibility List could just be augmented or cloned and used as a HSTS list mechanism.  If HSTS support appears in IE12 then I wouldn’t be surprised if Microsoft does exactly this.

EFF’s real problem with Microsoft and HSTS is that Microsoft’s current penchant for secrecy prevents them from coming out and saying what their rollout plans are for it.  This same problem applies to Forward Secrecy.  The latter prevents someone from recording an encrypted conversation and then decrypting it later should they obtain the encryption keys.

Forward Secrecy is another thing that everyone should implement but is also not the panacea that users will associate with it.  It protects old communications when someone obtains encryption keys, through a subpoena for example, but not if they manage to crack the encryption code.  Does it greatly increase the protection of communications?  Yes.  Does it prevent the NSA or its peers around the world from reading your communications?  Perhaps not.  In any case this is one that Microsoft should support, and may be planning to support, but needs to announce their plans if they want to get credit.

Forward Security, HSTS, and STARTTLS really only help when both parties to communications support them.  It will take years for that support to be ubiquitous, and the only way to get the ball rolling is for the big players in the industry to take the lead and quickly roll out support for their software and infrastructure.  From a practical standpoint these technologies will have at best modest short-term benefit, but if leaders don’t lead then they’ll never have any benefit at all.  This is an area where Google is showing leadership and Microsoft isn’t. If you are a Microsoft fan (or just a customer) then that is a bad thing.

The last issue on EFF’s list is the encryption of traffic between data centers.  Until we learned that the NSA was breaking in to this communications encrypting it was in the “nice to have” category.  Now it is in the “must have” category.  Not necessarily because of the NSA breach, which was bad enough, but because if the NSA can do it so can others.  Back in the 70s a phone hacker broke into the telephone central office of a major university and installed his own equipment for manipulating the telephone switch.  If a hacker can do it, and the NSA can do it, then organizations between those extremes can do it.  Encrypting communications eliminates obtaining physical access as a direct way to intercept communications.

Microsoft has been focused on other, and perhaps more widely beneficial, privacy protection efforts and that should no doubt be part of their defense.  And along with that the currently limited benefits of implementing the features that EFF is calling for probably represents a logical explanation of the status quo.  But it’s a losing proposition from a marketing standpoint, and far from the position a company claiming the privacy high ground should find itself in.