Re: Why are mail servers not also key servers?

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 20 April 2017 18:53 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857071292FC for <ietf@ietfa.amsl.com>; Thu, 20 Apr 2017 11:53:31 -0700 (PDT)
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 autolearn_force=no
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 FJOKA577d-7o for <ietf@ietfa.amsl.com>; Thu, 20 Apr 2017 11:53:30 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86513129BA2 for <ietf@ietf.org>; Thu, 20 Apr 2017 11:53:28 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3839F7A32F1 for <ietf@ietf.org>; Thu, 20 Apr 2017 18:53:27 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Why are mail servers not also key servers?
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <f5149504-12a1-728b-e685-3f75be6869c1@gmail.com>
Date: Thu, 20 Apr 2017 14:53:27 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: IETF general list <ietf@ietf.org>
Message-Id: <063FA8A5-D94C-4537-8141-2A04374D4091@dukhovni.org>
References: <849511c0-6526-ecbe-2b56-7b459eaf010b@hawaii.edu> <B897A3A3-4A47-4C74-B79F-4F93C86A338C@gmail.com> <82ab9e4d-05ba-bc39-c7d1-bda6ee8d9be5@hawaii.edu> <20170420173551.GN25754@mournblade.imrryr.org> <f5149504-12a1-728b-e685-3f75be6869c1@gmail.com>
To: IETF general list <ietf@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/dkuHrCYotWlRpq76fhgQpVA8TmY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Apr 2017 18:53:31 -0000

>> A major problems with all E2E email encryption proposals is unrelated
>> to key distribution, none of the extant MUAs provide an adequate
>> interface for E2E encrypted email.
>>       + Encrypted email is not searchable.
> 
> Sure it is, by the recipient MUA, else the user could not read their email.
> It would not be searchable by a 3rd party - which is the point of encryption.

Which MUAs index content of encrypted messages?  How does this work for clients
that store only a cache of recent messages, or webmail?

>>       + Encrypted email is difficult to scan for spam and malware
> 
> The scan would have to take place in the MUA. Firewall scanners would fail,
> as they do now with S/MIME or encrypted PGP.

Endpoint scans are often not nearly as effective.

>>       + Changing the private key can mean loss of access to email
>> 	encrypted under the old key.
> 
> Only if you throw away old keys. Doctor, Doctor, it hurts when I do this.
> - So Do not do that :-)

The mocking tone is entirely out of place.  Not all MUAs support multiple recipient
keys.

>>       + Signatures stop verifying when the signature key expires,
>> 	even though they were valid at the the email was received.
> 
> Again, do not throw away the old keys. An MUA should not allow a user to throw away
> any key needed for any message still in the store. Yep - complex.

Should not is not the same as do not.  My point is and remains that E2E encryption
of email is not usable with today's MUAs, progress on some of the issues is both
difficult and unlikely.

-- 
	Viktor.