[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Cryptography] Avoiding PGP
- From: Jerry Leichter <leichter AT lrw.com>
- Subject: Re: [Cryptography] Avoiding PGP
- Date: Wed, 21 Mar 2018 19:44:28 -0400
- Arc-authentication-results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com designates 2001:470:30:84:e276:63ff:fe62:3500 as permitted sender) smtp.mailfrom=cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:cc:list-subscribe :list-help:list-post:list-archive:list-unsubscribe:list-id :precedence:subject:to:references:message-id:date:in-reply-to:from :mime-version:delivered-to:arc-authentication-results; bh=+SYJIXGq7/JkBDKIzc87VAmCu0Gbu6R06eMXmfEwBqo=; b=EI7EleE6j4LLjJOJ9O1ScPoiULWrf2pAGMoV3DHhuALMayHxPWXllbR/eBHw1RF2qu 7kKalCa8pOC/AcK8ML6Io4ht1sgRjEHR2QLcUpc3GO9PrK6hiH9P052fC+onrrkH+5QV P8/gzCWVb69l6r6Kv1gMjdeRjMdS73pb7nPLdFBVA354UgPrbiN7KFphSmd4R6+7m2wK 9HcCAwE5CKYY0uKlCBENjVl9VfWFq9SZfb5RVU57NImOC+o2N6GB+hhOE5A7T1KkqFim sTHsEqECDrezmlOlOCwivrJ8k7cIGSU7WOnPyjYW8/Ctscw0ow1qIc6hmFnuo7uosX2Y qSuQ==
- Arc-seal: i=1; a=rsa-sha256; t=1521678894; cv=none; d=google.com; s=arc-20160816; b=RyFElweGVnJurKWMSRfctwAp4N0w7aXwReSvEg8491o/XJSHegdr0ZvkrejsI1vjue d2jiaKhJUa215Is9thatQ+RgxVEI8AB3PWitEKlmJCndzFyaJ0pZaZRvFt30hwt+sSWR JnMzcyy5eUeBd+lazq6BOag2LA/KoFHtu9GC7DX8aIIcxO054cexsmnzJIL2zS8BCcRe ICeWR446D6NZDgbbzKFyLmvTXphK2yGqJZ2wbFNA+f32ShrO8cow99o5hFw1KKwoNcwP pgoQXg41KXzytgPCfai7iGz+gD9WtyRZYXKUUTQhWSWk2XxrFMXmV7iv9zTRHVg8IIf8 FkGw==
- Cc: cryptography AT metzdowd.com
- List-archive: <http://www.metzdowd.com/pipermail/cryptography/>
- Sender: "cryptography" <cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com>
- To: Ray Dillinger <bear AT sonic.net>
> The problem isn't that the programmers aren't able to make the plugins
> behave the way they should; the problem is that a thousand people who
> assume with no evidence or consideration whatsoever that they know
> exactly how the plugins "should" behave.... I'd be perfectly happy if there were never any confusion of encrypted mail with unencrypted mail - in fact I'd prefer to be using entirely different applications ... [with the "secure" application] simply had no access whatsoever to addresses or contacts or header information pertaining to messages other than the plain-vanilla SMTP
> stuff it knows how to handle.
Hmm. So now you've contributed *your* idea of how this "should" behave. :-)
> Nothing that can be configured to run an executable attachment, or which
> loads assets over the network when someone reads messages (like graphics
> in "html mail"), or which by default launches a browser for clickable
> URLs, should also be handling messages, addresses, or keys intended to
> remain private.
And yet most mail today uses some of those features, so by leaving them all out you're limiting the scope of your "secure mailer" to a rather small set of people. Not that the problem isn't real!
The takeaway from your comment, though: If there's anything you *must* have before you implement a security-relevant piece of code, it's a careful definition of *what security actually means for that piece of code*. And it appears, that for "secure email", we really don't. What we have is essentially "I want it to do everything regular email does - but, you know, securely". The fact that pretty much all the implementations we have out there are plugins or extensions to existing mail programs makes this "security definition" very hard to improve upon.
It's interesting that secure messaging has developed very differently. There are formal definitions of what it means for a messaging application to be secure, and as far as I know all the secure messaging apps were written ab initio - no one tried to graft security on top of existing apps or even existing messaging protocols.
Now, there are multiple real-world reasons for this distinction, ranging from what appears to be a more tractable problem (no long-term storage, no need to support things like search) to history (email standards have been there for decades and there's an immense "open" installed based; previous messaging applications, while they followed some standards, were often proprietary and incompatible, so the notion of a new messaging app that couldn't interact with existing ones didn't bother people much).
But ... the evidence of many years of experience is that a usable, useful, secure (with an acceptable definition) encrypted email system that would be widely adopted is highly unlikely to *ever* emerge.
Well, maybe during The Year of Linux on the Desktop. :-)
The cryptography mailing list
cryptography AT metzdowd.com