Subject: [perpass] Proposal for e2e email encryption

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 2 Sep 2013 16:02:04 -0400

This is a followup on Jim Fenton's proposal and is somewhat inspired
by Cyberpunk remailers and Tor/Onion routing.

My goals are to compartmentalize the knowledge in the mail handling
process to as needed only:

1. Only the author's and recipient's message user agents (MUA) have
access to the full headers and body of the email.

2. Only the author's message user agent (MUA) and the receipient's
message delivery agent (MDA) would know the destination mailbox of the
email, and the author's domain. However, the receipient's MDA would
not be able to know the sender's mailbox or see the message itself.

3. The author's message submission agent (MSA) would know the author's
mailbox and how to resolve a bounced email back to the author, and the
destination domain of the email, but not the recipient's mailbox or
the anything in the email itself.

4. The author's message transfer agent (MTA) and all the other MTA's
between the author and the recipient would only know the domain names
of the author and recipient but not their individual mailboxes. They
also would not be able to see what's inside the email.

5. All transactions including SMTP and local submission would require
TLS/SSL as per Jim Fenton's proposal.

This would work as follows:
1. Domains participating in this protocol would publish an S/MIME or
PGP key in DNS, and a mailbox address to be used for secure email.

2. Authors that send email to domains participating in this protocol,
would encrypt their email using S/MIME or PGP, addressing it to the
recipient's mailbox. They would then encrypt the inner message a
second time, wrapping it in outer envelope, addressed from the secure
mailbox of the author's domain, and addressed to the secure mailbox of
the recipient's domain. This should be done in the MUA, either a
software client, or a browser plugin for webmail. It can also be
digitally signed at that point.

3. The email would then travel via SMTP to the author's MSA, with
TLS/SSL required as per Jim Fenton's proposal. At this point the
author's MSA would need to record some information about the message
in order to handle bounce backs. It can also be digitally signed using
DKIM or similar mechanism.

4. The MSA would hand it over the MTA, using SSL/TLS, and the email
would be delivered to the destination domain via one or more MTAs,
addressed from the secure mailbox of the author's domain to the secure
mailbox of the recipient's domain.

4. The destination domain would receive the email, unwrap the outer
envelope and find the recipient's mailbox, and then deliver the
message, optionally digitally signing it as well via DKIM.

5. The recipient would then unwrap the message a second time, finding
the original email.

In the ideal world, where all steps along the way are compliant with
this protocol, everything would be encrypted with TLS/SSL for
transport, and the message information itself would not reveal to any
MTA who the parties are.

Here are some fallback provisions:

1. If one of the MTAs along the way does not support "TLS/SSL
required" for SMTP, the message would automatically be delivered via
non encrypted SMTP. At that point any attacker monitoring the channel
would only learn that the message is traveling from the generic
"secure mailbox" of domain A to the same on domain B. With commercial
providers like Gmail, etc. delivering millions of messages via this
mechanism, it would be pretty hard to figure out the parties involved.
Same goes if the TLS/SSL process is somehow hacked along the way, or
the TLS/SSL key is obtained from the MTA via a court order. The
digital signatures from the author's MSA tied to DNS would prevent MIM
attacks.

2. If the receiver's MDA is compromised, the most they will learn is
which domain the message came from as well  but not the mailbox of the
sender. In order to learn that, both the sender's MSA and the
receiver's MDA would need to be compromised. In that case, the inner
email is still encrypted. If multiple gateways are used, then the
number of providers that need to be compromised increases.

3. If the sender's MSA does not support this protocol, the most an
attacker can learn is that a message is being send from the author's
mailbox but not to whom, only the domain of the destination.
Additionally, one can envision the author using this protocol with any
email system today, as long as the receiver's domain publishes the
correct data, and the author's MUA can encrypt it.

4. This system does not assume a prior agreement between the sender's
and receiver's mail providers, just like things work today. As long
they publish their information in DNS, it can work. Obviously, there
is still an issue of key exchange among individual users.

5. Spam and abuse are obviously an issue here. If the messages are
encrypted e2e, then it would be hard to analyze them for spam,
phishing, etc.

6. SSL/TLS key issues, key rotation, etc are still a problem.

7. This assumes DNS SEC.

It becomes really interesting if you start doing what Tor does with
multiple gateways for the message.

Thanks,
Yakov

---

From: Nick Doty <[email-masked]>
Date: Mon, 2 Sep 2013 17:17:31 -0700

I don't consider myself qualified to comment on all the details of your proposed protocol, but I find one property interesting. Encrypting email for a domain (and then separately for a user) can help with the problem of metadata revealing our communication partners, but only to the extent that domains are shared by lots of people. For those of us who maintain personal domain names, knowing that an email comes from a particular domain sufficiently identifies an individual author; e.g., emails sent from any address @npdoty.name always come from me. Revelations about NSA activities and user privacy concerns have created some renewed interest in owning one's own email address (for example [0]). It would be surprising (and I think, unfortunate) if advice was to *avoid* using personalized domains or services in order to support a privacy model.

The question of centralization/decentralization in this case might help us clarify the threat model. A common privacy concern of centralization is that a governmental adversary can compel that single bottleneck to reveal the contents, or in this case, the to/from information of many communications. If we all use @foo.com email addresses but Foo Inc. is compelled by a PRISM-like program to allow an adversary to search for who is emailing whom, then the proposed protocol may not provide an advantage. On the other hand, if the adversary is inspecting unencrypted traffic diverted from a backbone provider, then anonymizing recipients down to the foo.com domain name could provide a real advantage.

—Nick

[0] https://konklone.com/post/take-control-of-your-email-address

On Sep 2, 2013, at 1:02 PM, Yakov Shafranovich <[email-masked]> wrote:

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 2 Sep 2013 20:37:15 -0400

Even for personal domains often another larger party handles the email
traffic. Just like SPF, DKIM, SMTP information, etc. today can point
to another provider, you can point to another provider as handling the
secure email for you. For example, if your personal domain handles its
own email but uses something like LavaBit for secure email, you can
point to them via DNS. The actual email traveling would be addressed
to "secure@lavabit" as opposed to your domain. Of course there would
be a question of securing the DNS lookup itself.

Regarding centralization, the nice thing about this proposal is that
if an ISP is compromised, whether by a hacker or the government, the
amount of leaked data would be limited. For the sender's ISP, only
which domains email is being sent to would be known. For the receiver
ISP only which domains email is coming from and for what user. The
MTAs in between only see domains and not even users. It would take
effort to control both the sender and the receiver's ISP in order to
see the email traffic, and in that case, the inner layer of encryption
would still protect the message.

Thanks,
Yakov