email confidentiality

Wed 04 June 2014

Confidentiality mechanism (Photo credit: Wikipedia)

This is a trivial reminder about end-to-end security.
First of all, the Internet is designed so that every complicated stuff should be made on the border, i.e. on computers or other hosts connected to the Internet. For example, for stream based connection, the flow and congestion control, the order the data are presented to application, and every other services related to streams are managed by hosts. just look at wikipedia page of TCP, SCTP, RTP, ...
The assumption behind is that the network is not reliable. This is a quite safe assumption. This allow network components to be simple, fast, cheap. If the network does not beahave as expected (e.g. bit modifications or packet loss), hosts are expected to bypass the problem. In few words, network is not expected to be trusted, only hosts can be.
Then, cryptography ensures few security services, namely authentication, confidentiality and integrity. If the only services wanted for a communication are authentication and integrity, everyone should be able to check the entire flow integrity and authentication. In other word, anyone can intercept the communication and check it has not been altered and comes from the expected computer.
Finally, end-to-end security must rely on extremities of a communication. The only stuff middleman should be able to do is the authentication and integrity checks on plain unencrypted communication. Confidentiality service can only be achieved by end users, or more precisely by theirs computers.

Now lets consider emails. If you want to add confidentiality to your mail exchanges, you migth consider end-to-end ecnryption solutions such as pgp [1. it only ensure confidentiality of the content of the mail]. This solutions takes place in the end user's computers and nowhere else. If you want to ensure authentication and integrity check, pgp's signature must be done on the emmitter's computer, the differents checks can be done everywhere.

Now lets think the life of an email. It borns somewhere in an host. In many case, thanks to a MUA. It then transits toward a first MTA, usually designated by the part after the @ of the sender's email address. Then, it transits between several MTA [2. this transit does not use any web's application protocol (HTTP, HTTPS, XHTML, CSS, ...), the standard protocol is SMTP.] until it reaches the last MTA, designated by the part after the @ of the receiver's email address. Then the receiver's MUA enters into effect. During this transit, when an email can be read (in plain clear text)? if some security service is wanted, where can it be done? Depending on the solution you apply, where is your email secure (in which MTA or MUA)?

This is my point of view. That is why I consider email encryption should only be made on end user's MUA and nowhere else. Email encryption can be done offline, before sending all emails in batch.

Lets now consider the confidentiality of the parts of emails not covered by pgp-like email encryption. That is to say the metadata (email header and lower level). An email must be delivered, so it must have a valid receiver. The easiest way to bypass this limitation is by using a one-time-email-address. The algorithms to agree ont eh email address to use can be related to the one used for one time passwords. The sender can hide himself by modifying the "from" field and by sending its email from elsewhere (e.g. using TOR).

That's why I'm really puzzled about this google transparency report annonce.

(Non-)Related articles