S/MIME and TLS - The #DirectProject

 by Arien Malec

John Halamka today posted on a topic that has been a huge item of historical discussion in the Direct Project: whether we can enable simple, direct, scalable and secure transport in support of meaningful use based just on TLS.

Our conclusion was that you couldn't, at least not simply, and we felt that S/MIME was the natural proven fallback.

To explain why, I'm going to go moderately deep on bits and bytes in a rather long post. I apologize in advance. If you want to get to the meat, go to the paragraph that starts "so why is this a problem?"

First, I want to distinguish server authenticated TLS from client (or mutually authenticated) TLS. Server authenticated TLS is the form you are likely most familiar with. You connect to a website using SSL (https), and your browser's lock turns green (in some sites that use Extended Validation (EV) certificates, your browser's lock turns green with the name of the organization you are connecting to). Your browser is checking:

• That you have a strong SSL encrypted connection
• That the certificate that the server is using for the connection was actually assigned to the server
• That the certificate was issued by a CA that your browser trusts

This gives you, the shopper, assurance that the channel is encrypted and that the server is not spoofing the organization it pretends to be (for example, ensures that when you shop at Amazon, you aren't actually shopping at BadHacker.com, who is syphoning off your credit card and CCV number and not shipping you any books).

Your browser has a list of root certificates (for example, this is the list of roots approved by the Mozilla Foundation for Firefox) that it trusts. As I mentioned above, there are two kinds of trusted SSL certificates in common use: the ordinary kind, that verify that the certificate holder actually controls the domain in question, and the EV kind, that verify that the certificate holder is the actual legal entity it purports to be.

So far, so good. This approach works well, and promotes a good ecosystem of certificate issuers who compete on cost without lowering overall quality.

The only problem is that this approach authenticates the server, but not the client. In the context of information exchange, it would give assurance that the receiver of information was the individual or organization it purported to be, but would give no assurance whatsoever about the sender. Oops.

If you want to authenticate the client and the server in an TLS-encrypted channel, you can use mutual authentication. In this mode, the server presents its certificate and encrypts the channel, as before, and then requests that the client present its certificate. If the client trusts the server and the server trusts the client, the transaction can proceed. Brilliant!

Here was the problem we ran into: in the TLS negotiation process, the server presents one and only one certificate path. In typical implementations*, the server also verifies the client certificate against one and only CA root. That means for every pair of client-server connections, the server and the client have to have the same root CA.

So why is this a problem? Well, if everyone lives in the same exchange, it's not a problem. The exchange hands client certificates to everyone, and everything works. If people use different exchanges, it falls apart. Consider a typical practicing physician:

• She receives her exchange connectivity through StateHUB, her state HIE provider
• The cardiologist she typically refers to has an EHR provided by GreatEHRCo, which also runs exchange connectivity
• She refers to two hospitals, GeneralIDN, and MemorialIDN, one of whom uses VeronaSoft as its EHR and exchange capability, the other of whom uses KCTech as its EHR and exchange capability
• She has some patients who are veterans, and she needs to exchange data with the VA
• She uses two national reference labs, LaboratoryCo and Journey, each of whom run lab specific exchanges

This is not a crazy situation; in fact, the real world will likely have more exchanges in the mix (many EHR vendors are building exchange capabilities into their products). Based on the way TLS currently works, for this model of real world exchange to work, every exchange would have to use the same CA. If StateHISP got its certificate from Verizon, GreatEHRCo got its certificate from Verisign, and GeneralIDN got its certificate from Thawte, they couldn't connect based on the mutual-authenticated TLS of today.

If you take anything away from this long post, take this away: using TLS with mutual authentication would require central coordination and configuration. That is, unlike the browser bundle I mentioned above, which provides a market-based approach where anyone can stand up a CA, and, assuming they pass validation by WebTrust or a similar credentialing organization, can play on an equal footing with the established CAs, in the single rooted world, there would be only one master CA. Assuming ONC provided that single master CA root or bundle, getting the operational and governance mechanisms to make that work, and rolling it out nationwide, and enabling a robust market for identity assurance would take us a ways out in the future.

In addition, authentication in this approach is explicitly machine to machine, not organization to organization. To get organization to organization authentication, the SNI extension would be needed because TLS servers provide a single server certificate for the IP address on which the server runs. In cases where the same machine is used for multiple organizations (e.g., an HIE or a HISP), SNI allows virtual hosts to be used on the same IP address. Unfortunately, SNI is not well supported across web servers or SMTP servers. Without SNI, authentication is exchange to exchange, not organization to organization, which bumps the policy requirement for identity assurance to the intermediary.

There are inventive ways around this problem, by using TLS extensions like SNI** and agressive (and by agressive, I mean agressive) use of DNS RRs like SRV and NAPTR and CERT to allow discovery of the certificate in use by a particular exchange participant, or using server-auth TLS and client signed Oauth bearer tokens but it ends up being pretty knotty and uses a technology stack that is not well supported. We tried. We really wanted TLS to work.

S/MIME, by contrast, works today, is well supported, has multiple interoperable implementations, works on the PKI infrastructure that is in common use today, is well described by IETF and is forward compatible to a day where we have authentication and digital signatures at the individual provider level. That's why we went that direction in the Direct Project, and I feel just as good about that decision today as when we made it.

`* The TLS spec supports multiple CAs for client authentication but only one cert chain for the server. Multiple client CAs are supported in Apache and IIS, but not in Nginx.