[perpass] Proposal for e2e email encryption
Yakov Shafranovich <yakov-ietf@shaftek.org> Mon, 02 September 2013 20:02 UTC
Return-Path: <yakov@shaftek.org>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C085421F9B8A for <perpass@ietfa.amsl.com>; Mon, 2 Sep 2013 13:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.662
X-Spam-Level:
X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4AqDUV9b5oY for <perpass@ietfa.amsl.com>; Mon, 2 Sep 2013 13:02:36 -0700 (PDT)
Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id B924121F8DDD for <perpass@ietf.org>; Mon, 2 Sep 2013 13:02:35 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id ib11so3440577vcb.28 for <perpass@ietf.org>; Mon, 02 Sep 2013 13:02:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=44B3rTZFAi7Yn0LJtOhrXrzPUUYWxdh/FuRvn7tdC9U=; b=PGB9b3HIlg4k1PrNA++Pw2SjC6jX0EXqkzXQyOiSvLnuDNp04C7o3OxTGJbWzrL0+D MGifRbNCX76iRfUqkhsncN8GTb9g7kHjfOErMA169CJn6nD3MIHdVrNloBVaAwR7CNH2 rQ92B9JRC5aQozNSCilWxn6KBLeCOVOY9954Z7mOeV63Ffz+6wa/2kBrZ6d7CiNvC4h/ b/pF5enQfrvB3qQB0UA3EBQ0MGz3P1mmxLYrxs1ksj1I5cZJ6LTOnv0PliQuVR/a+v03 dNybX46bQME4lHwUQS5gQJYgmbA3uV7NaUy8NmMlmHaCbMFqDiaFKvCWrfagJ6nSywnu dWNA==
X-Gm-Message-State: ALoCoQlSPft4+tF6RPlvTkvNypXx+t0niKGYDFpQmuNmzUuNrSHnXLSb5rv97E18sdvGyNEsKDUY
X-Received: by 10.58.136.4 with SMTP id pw4mr24990782veb.10.1378152154900; Mon, 02 Sep 2013 13:02:34 -0700 (PDT)
MIME-Version: 1.0
Sender: yakov@shaftek.org
Received: by 10.52.183.4 with HTTP; Mon, 2 Sep 2013 13:02:04 -0700 (PDT)
X-Originating-IP: [96.244.132.139]
From: Yakov Shafranovich <yakov-ietf@shaftek.org>
Date: Mon, 02 Sep 2013 16:02:04 -0400
X-Google-Sender-Auth: Ghev9gdiRNErbAo0eH5KuEP0UoI
Message-ID: <CAPQd5oQpEfOKcheKJEf8ozC6gt7vHJ-YVPs9evokPYTdjiSSgA@mail.gmail.com>
To: perpass@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [perpass] Proposal for e2e email encryption
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2013 20:02:41 -0000
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] Proposal for e2e email encryption Yakov Shafranovich
- Re: [perpass] Proposal for e2e email encryption Nick Doty
- Re: [perpass] Proposal for e2e email encryption Yakov Shafranovich