Email transit security is not a new concept, but it deserves more attention in terms of adoption and practice.

Email has become the key component for information access – every online service identifies you through your email id. All online transactions (not just financial transactions) have one or more transactional email sent to you. Examples of transactional emails are – file share notifications, password reset mails, shipment notifications and account information change notifications. Despite not having direct financial information, all these mails have potential to compromise the security of an individual or company’s information.

We all take ample care while accessing our emails over a secure connection using tools like Thunderbird, Outlook or web based secure access. These secure connections ensure that  email is accessed securely from a mail server to a client device like desktop or phone. However, what is the assurance that the mail actually traveled from the sender to the mail server in a secure way?

Securing email during transit is not a new concept. There are enough protocols and processes in place for ensuring email security during transit. However, email security during transit isn’t adopted by all major service providers and organizational senders. This poses risk to the information carried over by emails to individuals and organizations.

Google’s safer email campaign and email transparency report focus on documenting metrics and best practices related to email transit security.  A couple of pictures on this page describe how TLS helps ensure security of email in transit.

Adoption of TLS for email transit security is not a unilateral fix by one or more ISPs. When email is hopping between two ISPs, it requires both the ISPs to agree upon the use of TLS for transmitting the email. So none of the ISPs or individual organizations can claim that they send/receive all their emails over a secure channel. At the time of writing this article, only 74% of mails from Google are accepted by recipients over secure connection. That number is much better, when compared to the 54% mails received by google from other ISPs over secure connection.

There are several techniques employed by eavesdroppers to make meaningful information out of even non-confidential content.  Ensuring email transit security helps an organization in the long run. Even if security of mail content is not of prime concern for an organization today, it is highly recommended that the email is sent securely during transit. That way, the organization is not giving away information easily to the eavesdroppers.

Do you trust? That is a vague question. It is very difficult to reply to this question with a definitive answer.

Do you trust [something]? That is a better question. Most likely, one will be comfortable to give a specific answer.

Do you trust [someone]? Here comes the complexity. The process of determining to trust someone has sevaral factors to weigh in. Trusting a person almost always requires an action or objective to qualify with, so that the affirmation of trust can be deduced. Trusting a non-human also requires additional qualification, but with a non-human, the purpose is mostly inherent and intended.

When I read this article on New York Times about the evolution of trust, it raised a few questions about trust and how we model in in computing and compute driven social environments. The computability of (or quantifying) trust and deduction of trust is, in general, an ever evolving and complex problem.

For non-humans we encounter in digital world, the establishment of trust is thru hashes, digital certificates, digital signatures, etc. and are continuously solved by entities like EMC’s RSA. For example, we may readily trust a PGP signed email or a shopping site that is protected by an SSL Certificate.

Trusting humans we meet online is nothing new. Social networking sites took the concept of acquaintance to a new dimension. Social Networking is slowly morphing the concept of acquaintance to a basis of trust establishment. For example, how many Facebook applications did you install (and trust) recently? How many people (those you have never met in the real world) did you befriend online and as a result, trusted them with your contacts, some amount of personal details, pictures, etc.? More often than not, social networking thrives on establishing trust beyond the immediate circle of acquaintance. Alluring to trust a friend of a friend  is the concept on which social networking thrives.

Shopping sites like EBay and Amazon have rating systems both at the product level and at seller level. Most of these ratings are based on previous transactions and respective human responses. The ratings quantify the transaction and response information to form a basis for trust. Customers make shopping transactions that are heavily influenced by these seller and product ratings.

Those two needs of trusting humans, for digital information and shopping transactions, have certain level of intrusion into the personal space. But the intrusive nature of services like Airbnb into one’s personal space is more physical and prominent.  The concept of giving someone (you possibly don’t know) access to physical resources has a considerable mental barrier. Service providers in this space will continuously try to lower that barrier or find ways to pass that barrier with quantified computation of trust. New dimensions of trust establishment are likely to emerge for solving this need. This space is likely to go beyond simple rating systems by the service providers.

I have been working on DKIM for the last couple of years and the journey has been very interesting.  Started with simple DKIM signing of mails and eventually spent considerable time on Signer Actions and Verifier Actions best practices. The later part is, to put it in a nutshell, an amazing experience.

If you live on the leading edge of any Internet technology that needs multi-vendor support and is cross-platform, you would know how critical the RFCs (http://www.ietf.org/rfc.html) turn out to be. As RFCs (and the respective consumers) evolve, the room for interpretation of the constructs in RFCs increase and you would see a lot of discussion around these interpretations.

Here is an example related to DKIM. For quite some time, all the DKIM signing entities are used to publishing public key records in the following format

“k=<proto>\; p=<pubkey>”

The above format is minimal and functional format for quite some time. For example, this is what gmail uses for this particular selector 20120113:

$ dig +short @ns1.google.com 20120113._domainkey.gmail.com txt
“k=rsa\; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87/UeJjenpabgbFwh+eBCsSTrqmwIYYvywlbhbqoo2DymndFkbjOVIPIldNs/m40KF+yzMn1skyoxcTUGCQs8g3FgD2Ap3ZB5DekAo5wMmk4wimDO+U8QzI3SD0” “7y2+07wlNWwIt8svnxgdxGkVbbhzY8i+RQ9DpSVpPbF7ykQxtKXkv/ahW3KjViiAH+ghvvIhkx4xYSIc9oSwVmAl5OctMEeWUwg8Istjqz8BZeTWbf41fbNhte7Y+YqZOwq1Sd0DbvYAD9NOZK9vlfuac0598HY+vtSBczUiKERHv1yRbcaQtZFh5wtiRrN04BLUTD21MycBX5jYchHjPY/wIDAQAB”

However, in the recent weeks, there is a growing set of ISPs that are mandating the other fields of a DKIM record. For example, RFC 5863 discusses DKIM verifier considerations in Appendix 1.2. The considerations around the DNS record talk about

If a DKIM verifier finds a selector record that has an empty “g” field (“g=;”) and it does not have a “v” field (“v=DKIM1;”) at its beginning, it is faced with deciding if this record was:

1. from a DK signer that transitioned to supporting DKIM but forgot to remove the “g” field (so that it could be used by both DK and DKIM verifiers); or

2. from a DKIM signer that truly meant to use the empty “g” field but forgot to put in the “v” field. It is advised that you treat such records using the first interpretation, and treat such records as if the signer did not have a “g” field in the record.

Looks like the notion of an empty “v” field is generating lot of noise from a few ISPs in the recent weeks. Even though the field is deemed optional, the interpretations by these ISPs have some ripple effects on how the other fields (like the granularity field) are seen in such situations.

Having read this RFC (and RFC 6376) a few times back and forth, it is time to test the DNS records by adding a  “v” field. I should be able to see the impact on those ISPs that changed their interpretations recently.