Re: the introduction problem, was Email and reputation (was Re: Service outages planned for April 25)

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 03 May 2022 12:55 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 1A44FC159486 for <ietf@ietfa.amsl.com>; Tue, 3 May 2022 05:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq5Oly1nqD8g for <ietf@ietfa.amsl.com>; Tue, 3 May 2022 05:55:47 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F046C14F748 for <ietf@ietf.org>; Tue, 3 May 2022 05:55:46 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 4B1CDF4311; Tue, 3 May 2022 08:55:45 -0400 (EDT)
Date: Tue, 03 May 2022 08:55:45 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: the introduction problem, was Email and reputation (was Re: Service outages planned for April 25)
Message-ID: <YnEmUWCcyFMu56iE@straasha.imrryr.org>
Reply-To: ietf@ietf.org
References: <dcc27c29-51f8-c2a4-8ce4-ee1a3c6cb017@nostrum.com> <AAE3C51B-0150-483C-8244-3D60BC31B19A@tzi.org> <2c5df733-0f86-d319-b886-81882328caa9@network-heretics.com> <1870005490.14504.1651151102962@appsuite-gw1.open-xchange.com> <t4f3j1$1mpc$1@gal.iecc.com> <626060406.28268.1651487745123@appsuite-gw1.open-xchange.com> <2480fd36-c16a-6d98-ddac-15d02259ffbe@taugh.com> <837df6ce-a771-ff2f-515b-1021cc242c23@network-heretics.com> <2E576046-0532-41C8-AF51-1C2D09BC8BAE@dukhovni.org> <3ccd160a-8f1e-2a43-73b1-504d114b7c70@network-heretics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3ccd160a-8f1e-2a43-73b1-504d114b7c70@network-heretics.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Fwk3IP0OOH80Ain3L6xTZbuSzIs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.34
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: Tue, 03 May 2022 12:55:48 -0000

On Tue, May 03, 2022 at 07:21:26AM -0400, Keith Moore wrote:

> > Until encrypted email is usable (**search**, long-term signature validation,
> > personal private key rollover, ...), all the key distribution tech in the
> > world won't make it worth adopting.
> 
> I wouldn't call such email entirely unusable, but clearly a system is 
> more usable (for some meaning of "usable") if encrypted emails can be 
> searched and signed emails can be verified long after such emails are 
> received.
> 
> I could take a stab at these problem and say that a message can be 
> decrypted and/or its signature verified when read (assuming of course 
> that the message is read a short time after it is sent, when the signing 
> keys and associated certs are still valid), and save their own signature 
> for the message ("message X was verified to be signed by Y by MUA Z on 
> <date>".   That's still nowhere nearly perfect, e.g. it might not hold 
> up in court as evidence that the sender of the message did or did not 
> say something.   But it's probably good enough for the recipient, for 
> most purposes, and still better than the situation we have today where 
> we have no widespread encryption or signing for emails.
> 
> (I think in that case the problem devolves to that of long term key 
> storage for the recipient, which is admittedly a difficult problem by 
> itself.)

I am not claiming that solving the UX problems is profoundly difficult,
indeed a number of design choices can make significant progress, *but*
no MUA I know of presently offers anything remotely close.  More
fundamentally, I don't see any likehood of substantial effort to improve
extant MUAs.  For example, Apple keep chipping away at *removing*
features from Mail.app:

* one can no longer compose S/MIME messages, they can only be read
* one can no longer subscribe to just a subset IMAP folders
* ...

Who's going to do the work?

-- 
    Viktor.