Re: [perpass] Proposal for e2e email encryption

[Nick Doty <[e-mail]>]

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 <[e-mail]> wrote:

> 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
> _______________________________________________
> perpass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perpass