[perpass] Proposal for e2e email encryption

[Yakov Shafranovich <[e-mail]>]

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