From nobody Sun Nov 16 21:28:02 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD911A00F8 for ; Sun, 16 Nov 2014 21:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntzonj_Gzo22 for ; Sun, 16 Nov 2014 21:27:59 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FDEC1A00F4 for ; Sun, 16 Nov 2014 21:27:59 -0800 (PST) Received: by mail-yk0-f179.google.com with SMTP id 19so2018976ykq.38 for ; Sun, 16 Nov 2014 21:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LFUFfAZgvndftdK7CQjjrWsTEr8+vPMvUmVq7IwQCho=; b=PQCFuQF13WBVTo2qrudXrBQO/lPWJoBpjE+4IM9ImMw1qGDhRusHJ4wHMmfK4m66wj aiqrbMdg1T83Ccahtei5IZlB380XdCgwPvtLMnTKGnLHluPaxYVLoh+T2tJzdKdtW8GD CTgwAZ58QciRdlU49Uqb988SGDQ/N0NhxKcGtybKbwIOzB66c9Pwo+m8+HnjRVqOk9tm PvjDygC36Xw+Lim4gCiGt5x5wJPG1vUC6E+zJRfAiiMKyJ6eDH8SqBxFUCJnu8tO1PPB 3V3SEHuyt7QW7ZxNc2SAYUQz55rhbxyG8VV81yRXl6cemh7V4p0QfKnBTYavEg6tM5cL 9cSg== MIME-Version: 1.0 X-Received: by 10.236.227.163 with SMTP id d33mr373466yhq.85.1416202078305; Sun, 16 Nov 2014 21:27:58 -0800 (PST) Received: by 10.170.195.203 with HTTP; Sun, 16 Nov 2014 21:27:58 -0800 (PST) Date: Sun, 16 Nov 2014 21:27:58 -0800 Message-ID: From: Watson Ladd To: endymail Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/bNBee0FtLqGf_tciiT5sw2DQ9vU Subject: [Endymail] We're not done yet X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 05:28:01 -0000 Dear all, Last email was a few months ago. There are a few drafts: I think Paul Wouters had a DNSSEC key discovery draft around, but I feel we are a long way from declaring victory. It would be nice to know that this is because silently we solved the problem and deployed the solution over the past month, but I've got a feeling its more likely we gave up. So if I could summarize the problems they are: 1: keys are hard 2: spam is hard 3: discovery is hard. UI work is needed for 1. 2 I have no idea. 3 seems to have some good ideas floating around to solve it. Of course, in an ideal world we would get perfect secrecy, but that's much harder, although methods are floating around to do it. Sincerely, Watson Ladd From nobody Sun Nov 16 22:39:55 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2691A0144 for ; Sun, 16 Nov 2014 22:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roSHp6aWP02z for ; Sun, 16 Nov 2014 22:39:50 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96B91A0137 for ; Sun, 16 Nov 2014 22:39:50 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EAB99284B0F; Mon, 17 Nov 2014 06:39:48 +0000 (UTC) Date: Mon, 17 Nov 2014 06:39:48 +0000 From: Viktor Dukhovni To: endymail@ietf.org Message-ID: <20141117063948.GX13179@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/7fmM3h4_9OghKDwtYHnKlhfd7oQ Subject: Re: [Endymail] We're not done yet X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: endymail@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 06:39:53 -0000 On Sun, Nov 16, 2014 at 09:27:58PM -0800, Watson Ladd wrote: > So if I could summarize the problems they are: > > 1: keys are hard > 2: spam is hard > 3: discovery is hard. > > UI work is needed for 1. 2 I have no idea. 3 seems to have some good > ideas floating around to solve it. Of course, in an ideal world we > would get perfect secrecy, but that's much harder, although methods > are floating around to do it. So at least in terms of keys and discovery, the DANE-specific obstacles as are I see them (feel free to contribute to the Dec 02 DANE WG interim): 1. Mapping user addresses onto DNS: a. Email addresses use an alphabet more extensive than DNS labels. b. Email address localparts can (infrequently) be longer than DNS labels, and base32 or similar encodings make the problem worse. c. Email addresses are often, but not always case insensitive. d. DNS names are case insensitive. e. There are for better or worse significant concerns around directory harvesting (even with NSEC3). f. Some folks want key lookups to work with DNAMEs, with the keys published just once and automatically functional for all domain name variants. The current draft proposal lookup keys are base32 encoding of SHA2-254 hashes of the just the user address localparts. This addresses a/b/f and very marginally e. However, the conflict between c and d is rather severe. Key lookups will only succeed when the email address query is for the canonical capitalization of the email address. If the email address were something like: First.Last@example.com and the destination domain supported case-insensitive delivery (e.g. via LDAP in which addresses are not case-sensitive), one might publish the same keys for each of: First.Last@example.com first.last@example.com FIRST.LAST@example.com and hope that these combinations cover all the likely variants. 2. Revocation, or where does one attach the horse to the motor car? http://www.psmag.com/blogs/time-machine/electric-hybrid-cars-cyclists-pedestrians-traffic-safety-52337/ - DANE is an online system for publishing fresh key material. - Ideally revocation in DANE is a matter of just removing the relevant records from DNS, and publishing only those keys are valid at the present time (modulo TTLs and ideally short RRsig lifetimes). - Since X.509 PKI certificates (OCSP notwithstanding) are typically long-term offline attestations, carrying over the web PKI "revocation" compensating measure is not necessarily a good idea for DANE. - Furthermore, in current mail client S/MIME implementations there is no semantically sound treatment of revoked or expired certificates. Mail that arrives today should indeed avoid no longer applicable keys (whether revoked or simply no longer published). However mail that arrived while the key was still valid and was successfully verified at the time, should generally remain valid even if the key is (sufficiently) later withdrawn. - So we are still talking past each other with completely different models and associated requirements, some want to put the horse before the cart, others say the cart is a motor car. - There needs to be a life-cycle model of key management in a world where today's keys are published online, that defines not only how the current keys are located, but how saved mail is handled and whether any sort of "revocation" is required, or whether de-publication is sufficient. -- Viktor. From nobody Sun Nov 16 22:57:22 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58E41A0164 for ; Sun, 16 Nov 2014 22:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avtDNqmSD5uJ for ; Sun, 16 Nov 2014 22:57:18 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63E41A0162 for ; Sun, 16 Nov 2014 22:57:18 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 805AF817C1 for ; Mon, 17 Nov 2014 01:57:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1416207436; bh=2Iyyp32J/4tXNd6u1L/UMZfDzebhrPbF7HxffVlt15Q=; h=Date:From:To:Subject:In-Reply-To:References; b=pdbEjKFH+vMsAsYMGWfPc0BLTJux/m+QbiV1D0EV8nNTA8p0l2R1Q8t1cfNi+CN28 8iRP7G7MmBwcQz8fOTXIOixz/bc8xJma1iIMlIfwLgAj8y/r8Y9yJTI4uYVrJ9s/87 nhEmmHDGzqbexA4oYs4leRqzW6rIjkIAqxx+QM4o= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sAH6vFSn008159 for ; Mon, 17 Nov 2014 01:57:15 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 17 Nov 2014 01:57:15 -0500 (EST) From: Paul Wouters To: endymail@ietf.org In-Reply-To: <20141117063948.GX13179@mournblade.imrryr.org> Message-ID: References: <20141117063948.GX13179@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/kIkOHYfvNgwlxkfIw0-b7daF_54 Subject: Re: [Endymail] We're not done yet X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 06:57:21 -0000 On Mon, 17 Nov 2014, Viktor Dukhovni wrote: > However, the conflict between c and d is rather severe. Key > lookups will only succeed when the email address query is for > the canonical capitalization of the email address. If the > email address were something like: > > First.Last@example.com > > and the destination domain supported case-insensitive delivery > (e.g. via LDAP in which addresses are not case-sensitive), one > might publish the same keys for each of: > > First.Last@example.com > first.last@example.com > FIRST.LAST@example.com > > and hope that these combinations cover all the likely variants. That problem already exists at the SMTP level. There is nothing we can do anymore. Implementations for OPENPGPKEY or SMIMEA will just have to try some varients, or just lowercase it all. The discovery of those records in cheap and the DNS probes can be sent in parallel. > 2. Revocation, or where does one attach the horse to the motor car? Use the key that is valid NOW and in DNS. There is nothing else better. I don't see these two as a problem (and the fact that people are implementing OPENPGKEY is a good sign they believe this too) For me, the biggest problem in this is for people who don't run their own DNS. It would be good if there was some kind of method for people with just a gmail account to also be able to publish their public keys. I think something along the lines of "DLV like" but requiring proof of ownership of both email address and public key for registration, with a requirement to keep signing something to keep the key in the "DLV like" publication space (DNS or otherwise). Paul From nobody Sun Nov 16 23:25:52 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7551A019B for ; Sun, 16 Nov 2014 23:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV0PRdR2OLld for ; Sun, 16 Nov 2014 23:25:38 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4FB1A0169 for ; Sun, 16 Nov 2014 23:25:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6BC55284B0F; Mon, 17 Nov 2014 07:25:36 +0000 (UTC) Date: Mon, 17 Nov 2014 07:25:36 +0000 From: Viktor Dukhovni To: endymail@ietf.org Message-ID: <20141117072536.GY13179@mournblade.imrryr.org> References: <20141117063948.GX13179@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/leb6Opf1c2WPf2Zo1TrCSJKRaM4 Subject: Re: [Endymail] We're not done yet X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: endymail@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 07:25:50 -0000 On Mon, Nov 17, 2014 at 01:57:15AM -0500, Paul Wouters wrote: > > one might publish the same keys for each of: > > > > First.Last@example.com > > first.last@example.com > > FIRST.LAST@example.com > > > > and hope that these combinations cover all the likely variants. > > That problem already exists at the SMTP level. There is nothing we can > do anymore. Implementations for OPENPGPKEY or SMIMEA will just have to > try some varients, or just lowercase it all. The discovery of those > records in cheap and the DNS probes can be sent in parallel. The client does not know whether these are safely treated as the same address, so should only query for the address it is sending to as-is. Any variant equivalent lookup keys should be created at the receving domain. So there's only one lookup. > >2. Revocation, or where does one attach the horse to the motor car? > > Use the key that is valid NOW and in DNS. There is nothing else better. For the record, I agree. We still need to explain how this works to others, why revocation is out of scope, and document the complete life-cycle requirements (including the need for MUAs to save signing keys associated with the message at time of delivery, and to securely tag already verified messages, so that old mail can still be verified). Users likely also need to store old private keys forever so that old mail can still be read. The complete architecture for encrypted email has many parts we're not making explicit, but all have a bearing on key management requirements for MUAs. -- Viktor. From nobody Sun Nov 16 23:34:29 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC56E1A01E5 for ; Sun, 16 Nov 2014 23:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7tpcrfSkeML for ; Sun, 16 Nov 2014 23:34:08 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098841A0171 for ; Sun, 16 Nov 2014 23:34:08 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 08372817C1 for ; Mon, 17 Nov 2014 02:34:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1416209647; bh=1kosXseKp518b4FhPtFjpi+XBmWgJlh0mZVUgCOVje8=; h=Date:From:To:Subject:In-Reply-To:References; b=dD8ZWcCyIRDoBIZe1AsGDWEH2s5bIXDUVjcyH+kP7EiyxK3D8t82AHtOdRg/nB7ab BQeccyuJk79F78W+0MQefF8bMjmTtEHIqdDDfz+n+De1DhmEG6UajtLnY3N3OMD3U/ 4p1gY6vHbE0UocKQDvxOQjuPGotvkrUIP3yFZmB0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sAH7Y6uo012712 for ; Mon, 17 Nov 2014 02:34:06 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 17 Nov 2014 02:34:06 -0500 (EST) From: Paul Wouters To: endymail@ietf.org In-Reply-To: <20141117072536.GY13179@mournblade.imrryr.org> Message-ID: References: <20141117063948.GX13179@mournblade.imrryr.org> <20141117072536.GY13179@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/MPy7G00_f8e-a52g5mC2yEF4Dlc Subject: Re: [Endymail] We're not done yet X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 07:34:12 -0000 On Mon, 17 Nov 2014, Viktor Dukhovni wrote: > The client does not know whether these are safely treated as the > same address, so should only query for the address it is sending > to as-is. Any variant equivalent lookup keys should be created at > the receving domain. So there's only one lookup. Well, that's a nice theory. Now in practise what happens is that SMTP servers really don't have different accounts for LHS that are only different in case. And we have the issue of too many phone input boxes and webforms automatically capitalizing names. I just happened to me today on my phone, so it send email to Paul@nohats.ca. If those are different people those people are going to end up with each others email already. So the problem will not be worse. > Users likely also need to store old private keys forever so that > old mail can still be read. The complete architecture for encrypted > email has many parts we're not making explicit, but all have a > bearing on key management requirements for MUAs. I'd call that out of scope. I think of OPENPGKEY as a transport plus data in rest protection while in-transit. Once the final enduser gets the email, I expect their email client to decrypt it and store it locally, so it remains searchable, indexable, etc. I also expect them to use full disk encryption to protect all their email. This method does not require keeping old private keys. Paul From nobody Sun Nov 16 23:49:46 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70661A0363 for ; Sun, 16 Nov 2014 23:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SBPV84s_C9t for ; Sun, 16 Nov 2014 23:49:42 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897561A026C for ; Sun, 16 Nov 2014 23:49:42 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CC0FA284B0F; Mon, 17 Nov 2014 07:49:41 +0000 (UTC) Date: Mon, 17 Nov 2014 07:49:41 +0000 From: Viktor Dukhovni To: endymail@ietf.org Message-ID: <20141117074941.GA13179@mournblade.imrryr.org> References: <20141117063948.GX13179@mournblade.imrryr.org> <20141117072536.GY13179@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/eEusJfGOYLBepez9nRh21M0Ktcg Subject: Re: [Endymail] We're not done yet X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: endymail@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 07:49:45 -0000 On Mon, Nov 17, 2014 at 02:34:06AM -0500, Paul Wouters wrote: > >Users likely also need to store old private keys forever so that > >old mail can still be read. The complete architecture for encrypted > >email has many parts we're not making explicit, but all have a > >bearing on key management requirements for MUAs. > > I'd call that out of scope. I think of OPENPGKEY as a transport plus > data in rest protection while in-transit. Once the final enduser gets > the email, I expect their email client to decrypt it and store it > locally, so it remains searchable, indexable, etc. I also expect them > to use full disk encryption to protect all their email. This method > does not require keeping old private keys. It is out of scope for the DANE SMIMEA and OPENPGP documents, but it is not out of scope for an architecture or requirements document. The pieces have to fit together. Decrypted local storage is a fine model. We need more MUAs that support that mode of operation. We also need to consider the implications for sign-then-encrypt vs. encrypt-then-sign, and how signature validation status is retained. Yes, of course not in the DANE-specific documents, but these should be part of a more complete architecture (IIRC something along those lines is an argument that PHB is making). -- Viktor. From nobody Mon Nov 17 21:11:07 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7361AD0C9 for ; Mon, 17 Nov 2014 21:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYcKlz8B_FIx for ; Mon, 17 Nov 2014 21:11:03 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9701AD10A for ; Mon, 17 Nov 2014 21:11:03 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id 9so4703883ykp.22 for ; Mon, 17 Nov 2014 21:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uaStfQFlFq2mYhWTJXeEG6LUbVXtX5F+qBFTKIAIS2o=; b=YHZ+1Zjq3GFZg19E5vaEi6LoTcTKk4I+jabBvZsX27ss5nLLAFnMRUbGuqL08KJugM G3opGzntKej5WsrgINe4YdNrs+lggENBW5qHPQQzJHosKj8k774Vcn+k75xNgmdalTaa PpVygt1I3kS7hWKYDhX/Kwp2KDrNOLlt++KhGPxIPyDhUdZXrQvZq6GOTIs0RQxveelA FCiyOWslbZid55rIuxhRb4j4Fp7W5Em20K+7+BHxc54D1dkAUQv9kXJLk1NdH6Kf6xSi /nrG6ApKpZGQKK4/NLBlNLeVV++W1eLTm4hH+ryEuZSdaW132udiXBXLolN23G7fytwQ DYDA== MIME-Version: 1.0 X-Received: by 10.170.125.146 with SMTP id r140mr18781ykb.122.1416287462149; Mon, 17 Nov 2014 21:11:02 -0800 (PST) Received: by 10.170.195.203 with HTTP; Mon, 17 Nov 2014 21:11:02 -0800 (PST) In-Reply-To: <20141117074941.GA13179@mournblade.imrryr.org> References: <20141117063948.GX13179@mournblade.imrryr.org> <20141117072536.GY13179@mournblade.imrryr.org> <20141117074941.GA13179@mournblade.imrryr.org> Date: Mon, 17 Nov 2014 21:11:02 -0800 Message-ID: From: Watson Ladd To: endymail Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/NmSIlk6lBn8P4hlKQ1tDbVCFJXc Subject: Re: [Endymail] We're not done yet X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 05:11:05 -0000 On Sun, Nov 16, 2014 at 11:49 PM, Viktor Dukhovni wrote: > On Mon, Nov 17, 2014 at 02:34:06AM -0500, Paul Wouters wrote: > >> >Users likely also need to store old private keys forever so that >> >old mail can still be read. The complete architecture for encrypted >> >email has many parts we're not making explicit, but all have a >> >bearing on key management requirements for MUAs. >> >> I'd call that out of scope. I think of OPENPGKEY as a transport plus >> data in rest protection while in-transit. Once the final enduser gets >> the email, I expect their email client to decrypt it and store it >> locally, so it remains searchable, indexable, etc. I also expect them >> to use full disk encryption to protect all their email. This method >> does not require keeping old private keys. > > It is out of scope for the DANE SMIMEA and OPENPGP documents, but > it is not out of scope for an architecture or requirements document. > The pieces have to fit together. Provide mechanism not policy. How MUAs decide to handle old messages and keys isn't really relevant, nor should we force changes from existing practice: people already have keys they will want to use with whatever system for discovering keys we make. Do architecture and requirements documents actually work? Or do they end up overcomplicating solutions, as designers attempt to address things that maybe should be punted on, as they cost too much to implement? They certainly don't help with analysis: the requirements documents may be wrong themselves! > > Decrypted local storage is a fine model. We need more MUAs that > support that mode of operation. We also need to consider the > implications for sign-then-encrypt vs. encrypt-then-sign, and how > signature validation status is retained. Yes, of course not in > the DANE-specific documents, but these should be part of a more > complete architecture (IIRC something along those lines is an argument > that PHB is making). The correct construction is sign-then-encrypt. However, it could be that authenticated encryption is a better idea, but S/MIME and PGP do not support this. One weakness of DNS vs. HTTPS is that HTTPS works in javascript for browser extensions, while DNS data access may be an issue. I understand Google wants to put PGP in the browser: the easiest way to access keys would then be via HTTPS at a well-known URL. However, a DANE-to-Web bridge shouldn't be that much of a pain if needed. This minor, probably wrong, technical point, underscores a broader deployability issue. Success of e2e email depends on everyone in the world doing something. I'd be more confident in our getting this right if people who understood the limitations and possibilities of webmail better would participate in the discussion, or if we had running code for whatever solution was being proposed. Sincerely, Watson Ladd > > -- > Viktor. > > _______________________________________________ > Endymail mailing list > Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Nov 17 21:22:22 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF53D1AD0C5 for ; Mon, 17 Nov 2014 21:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-7KJwMvzyvG for ; Mon, 17 Nov 2014 21:22:19 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EAD1ACD56 for ; Mon, 17 Nov 2014 21:22:18 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 09EA3282D5A; Tue, 18 Nov 2014 05:22:18 +0000 (UTC) Date: Tue, 18 Nov 2014 05:22:18 +0000 From: Viktor Dukhovni To: endymail@ietf.org Message-ID: <20141118052217.GV13179@mournblade.imrryr.org> References: <20141117063948.GX13179@mournblade.imrryr.org> <20141117072536.GY13179@mournblade.imrryr.org> <20141117074941.GA13179@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/BHjoXCywv6EVE5WfT6oBOviClcM Subject: Re: [Endymail] We're not done yet X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: endymail@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 05:22:21 -0000 On Mon, Nov 17, 2014 at 09:11:02PM -0800, Watson Ladd wrote: > This minor, probably wrong, technical point, underscores a broader > deployability issue. Success of e2e email depends on everyone in the > world doing something. I'd be more confident in our getting this right > if people who understood the limitations and possibilities of webmail > better would participate in the discussion, or if we had running code > for whatever solution was being proposed. Absolutely, the correctness of the ideas is only apparent once there are implementations, and running code is a major part of that. The DANE SMTP draft was developed in parallel with an implementation. Work on both began in March of 2013, the implementation was done by July, and officially released in January 2014, the draft is just now in WG Last Call. So for endymail, whether key management is via DANE or HTTPS, the important thing is working code. Fork Thunderbird, or Evolution, do something real that's not just a toy. The discipline of having to create a fully usable implementation will bring all the hidden problems to the surface. -- Viktor. From nobody Tue Nov 18 01:43:56 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738121A00E5 for ; Tue, 18 Nov 2014 01:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6YUxbd86Zhr for ; Tue, 18 Nov 2014 01:43:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E87B1A0041 for ; Tue, 18 Nov 2014 01:43:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1A641BE39; Tue, 18 Nov 2014 09:43:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQNaWRa8IZP6; Tue, 18 Nov 2014 09:43:47 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.42.22.166]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 96C01BE32; Tue, 18 Nov 2014 09:43:46 +0000 (GMT) Message-ID: <546B14D2.2060109@cs.tcd.ie> Date: Tue, 18 Nov 2014 09:43:46 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Watson Ladd , endymail References: <20141117063948.GX13179@mournblade.imrryr.org> <20141117072536.GY13179@mournblade.imrryr.org> <20141117074941.GA13179@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/o_vKvlgxJEyg6IJKPPdGh2QLE10 Cc: Dave Crocker Subject: Re: [Endymail] We're not done yet X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 09:43:54 -0000 On 18/11/14 05:11, Watson Ladd wrote: > Do architecture and requirements documents actually work? Or do they > end up overcomplicating solutions, as designers attempt to address > things that maybe should be punted on, as they cost too much to > implement? They certainly don't help with analysis: the requirements > documents may be wrong themselves! Oftentimes, those documents don't work in the IETF, I agree. This might be an exception, since there are a bunch of folks who're developing full solutions outside of the IETF and part of the point of this list is to see if there are things the IETF can do to help multiple of those solutions. (In the hope that one of 'em cracks it and would then get sufficient adoption that it'd be worth standardising later.) I know Dave Crocker has done some work in this space (and he's the author of RFC5598 as well) - so Dave, do you think there'd be value in an RFC along those lines describing an architecture for a modern secure interpersonal messaging system that could scale and supports implementations with privacy friendly features? (I'd like to see such a document myself, but am unsure if doing one now-ish would be effective or not - we might be too early or late.) S. From nobody Tue Nov 18 04:39:25 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECA51A0369 for ; Tue, 18 Nov 2014 04:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45Sd_-OTZBD3 for ; Tue, 18 Nov 2014 04:39:19 -0800 (PST) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C75C1A0364 for ; Tue, 18 Nov 2014 04:39:18 -0800 (PST) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id sAICdIXY020415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2014 13:39:20 +0100 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id sAICdHlC020414 for endymail@ietf.org; Tue, 18 Nov 2014 13:39:17 +0100 Date: Tue, 18 Nov 2014 13:39:15 +0100 From: carlo von lynX To: endymail@ietf.org Message-ID: <20141118123913.GA20077@lo.psyced.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/H2BlHxgBKuG_DH94lgWM6OrPkSM Subject: Re: [Endymail] We're not done yet X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 12:39:22 -0000 On Sun, Nov 16, 2014 at 09:27:58PM -0800, Watson Ladd wrote: > So if I could summarize the problems they are: > > 1: keys are hard > 2: spam is hard > 3: discovery is hard. >From my point of view these are all very solvable problems, but that is because I stand looking from a technologically completely different place. In the following contribution I describe how either Distributed Social Graph or the GNU Name System or a combination of the two can be used to solve the three problems listed above quite nicely. https://moderncrypto.org/mail-archive/messaging/2014/001081.html Please ask any questions if there are any logical building blocks missing. Probably there are. Or check out documents on http://secushare.org From nobody Tue Nov 18 14:04:03 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CE51A8A52 for ; Tue, 18 Nov 2014 14:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwoFpEJqUiGc for ; Tue, 18 Nov 2014 14:02:54 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46CC01A1B0C for ; Tue, 18 Nov 2014 14:02:49 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sAIM2joo020385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Nov 2014 14:02:48 -0800 Message-ID: <546BC201.6030004@dcrocker.net> Date: Tue, 18 Nov 2014 14:02:41 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: endymail References: <20141117063948.GX13179@mournblade.imrryr.org> <20141117072536.GY13179@mournblade.imrryr.org> <20141117074941.GA13179@mournblade.imrryr.org> <546B14D2.2060109@cs.tcd.ie> In-Reply-To: <546B14D2.2060109@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 18 Nov 2014 14:02:48 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/J8vp7CpwzP-VnsVbbI6ZJWYEPaE X-Mailman-Approved-At: Tue, 18 Nov 2014 14:04:00 -0800 Subject: Re: [Endymail] We're not done yet X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 22:02:56 -0000 On 11/18/2014 1:43 AM, Stephen Farrell wrote: > > > On 18/11/14 05:11, Watson Ladd wrote: >> Do architecture and requirements documents actually work? Or do they >> end up overcomplicating solutions, ... > I know Dave Crocker has done some work in this space (and he's > the author of RFC5598 as well) - so Dave, do you think there'd > be value in an RFC along those lines describing an architecture > for a modern secure interpersonal messaging system that could > scale and supports implementations with privacy friendly > features? Whether it's code, protocol specifications, architecture or requirements, whatever is written requires serious discipline and careful attention to utility -- that is, to being useful. Each of these has a long history of examples of impracticality, bloat, and/or silliness. (The worst piece of code I've ever seen what written in a highly structure-oriented language; the prettiest piece of code was written in assembler. So code is as subject to abuse as architecture documents.) Requirements docs tend to suffer from failures to distinguish between what really is essential, versus what is merely desired. (Hence, almost all the IETF documents that call themselves 'requirements' should be re-labeled, IMO.) Architecture defines components, objects and the relationships among them. Good architecture docs clarify things well and guide further work. Architecture exists whether we document or not. The difference is that when it is documented, we have a better chance of sharing the same understanding of it, and therefore meaning the same thing as we discuss things. (As a consequence, good architecture docs often allows debugging issues prior to the work of coding.) Quite a bit of discussion on this list has been about architecture, when it hasn't debated specific algorithms. But I'm unclear what goals are being agreed to or met or how decisions being made satisfy them. Documenting the architecture doesn't answer such questions, but it provides a useful place for reviewing whether the decisions match and satisfy the goals. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net