[Endymail] Why S/MIME and OpenPGP ecosystems fall short

Tom Ritter <tom@ritter.vg> Wed, 03 June 2015 02:28 UTC

Return-Path: <tom@ritter.vg>
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 5F8F61B32C9 for <endymail@ietfa.amsl.com>; Tue, 2 Jun 2015 19:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.521
X-Spam-Level:
X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 PEgxA1cn4VVT for <endymail@ietfa.amsl.com>; Tue, 2 Jun 2015 19:28:08 -0700 (PDT)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648451B32C8 for <endymail@ietf.org>; Tue, 2 Jun 2015 19:28:08 -0700 (PDT)
Received: by qgep100 with SMTP id p100so4553408qge.3 for <endymail@ietf.org>; Tue, 02 Jun 2015 19:28:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IhrKdjvyedRUIT1/9OHnyGlcgNgiOyiTzblPES3ZYjg=; b=TY7LdVFtE7nK0FYcHrEnLb2ir4ZA4LWd6prWGkBgLDreAfODLcQqWYvb+EQJtk3Q2m I/eVz49bR4bFcksSEfFh3eVssIbJaFFgWBVkp6Gt4bKE/Hzws0FZH2dwrM//NHI9/Avi cy8RIOM9uax/I+9SvudLJx8KdGEZ6K1pxPOpw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IhrKdjvyedRUIT1/9OHnyGlcgNgiOyiTzblPES3ZYjg=; b=hAwxMhLZIlDTb5JvsQI3azq/7SQZchjM3VHrHuRtM/ANnE2Huq9mBSaKzV4FYdDnkJ F2m2J2xXQOJpcMZFsiChQz5GccWmZ8Da3UWYpyjMjjyT2MeoDwEEZ7D99iRJ3ktYmJ+n Tc3L0o3h7j/gE/cnqdr7W263S2yCzirc4fZ3m+jYr/X6otRkrvMOgsJn0DnU4BwjPDq2 E5hGSodx68XUo/piC1UexTD3n0Lt/Gj4UJKLblZHvdHYuMCxyaqjLo8MFPjlmK9LEvuX GA91xnTUwe/mWT1p5Bcw4cnDeSvqCiin8Ei/rpu6+8MCwtXff/iP4hXCngIdoNdnf6lC a/hQ==
X-Gm-Message-State: ALoCoQkYjQWXumRXObhz5sChulPaoRt3a3EYncgSbILWz1cdLSC6yo1JWIDymGqoJRSP0sWfTFYE
MIME-Version: 1.0
X-Received: by 10.55.16.200 with SMTP id 69mr9507507qkq.98.1433298487691; Tue, 02 Jun 2015 19:28:07 -0700 (PDT)
Received: by 10.140.51.103 with HTTP; Tue, 2 Jun 2015 19:28:07 -0700 (PDT)
In-Reply-To: <EBki7WFib38o/GuwWcynetKjdsyFQKqu+TC5JQp412c=.sha-256@antelope.email>
References: <CACsn0c=1RfwZF3-ynoaer=QkRXE56Mzwe1y50QQirW=GMBwvYA@mail.gmail.com> <EBki7WFib38o/GuwWcynetKjdsyFQKqu+TC5JQp412c=.sha-256@antelope.email>
Date: Tue, 02 Jun 2015 21:28:07 -0500
Message-ID: <CA+cU71nmMO+V=JNExULUOxDxMjkoG19bHWC1_Qzf+qV1uV34RA@mail.gmail.com>
From: Tom Ritter <tom@ritter.vg>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="001a113ac574376138051793cf00"
Archived-At: <http://mailarchive.ietf.org/arch/msg/endymail/tb-DVjB6SsecXE5IHzwvAfLD7CE>
Cc: endymail <endymail@ietf.org>
Subject: [Endymail] Why S/MIME and OpenPGP ecosystems fall short
X-BeenThere: endymail@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <endymail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/endymail>, <mailto:endymail-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/endymail/>
List-Post: <mailto:endymail@ietf.org>
List-Help: <mailto:endymail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/endymail>, <mailto:endymail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 02:28:10 -0000

I'm a big fan of TextSecure, but comparing TS and Email ignores many of the
difficult problems TS has been able to dodge that email cannot.

The biggest one I'll put forth is Key Authenticity[0].  I'm not talking
about the fingerprint comparisons (they're about the same there.) In TS, I
ask the central TS server "What's the key for Watson Ladd <1 555 123 4567>"
and it gives me a key that I can reasonably believe is yours. TS is the
central authority.

Email's central authority would obviously be federated at the provider, but
now we're gated on our email providers supporting some sort of Key
Directory. Google and Yahoo are going to do this, but that doesn't solve
the problem for everyone. This was solved for DNSSEC with the DLV - a
central authority everyone agreed was able to provide you with a server's
keys. Who will be the Email Lookaside Vector? Who will everyone agree to
trust?

There are other very difficult problems TS dodges, but an email solution
must confront immediately.  To be honest I'm not entirely certain TS'
current mechanism for resolving some of these, maybe someone more familiar
with TS' implementation can comment?

- Multi-Device. TS is by-and-large single device. I thought at some point
they had support for multi-devices - and I thought that worked by me giving
the central directory multiple keys, and senders encrypted to all of them.
I assume the central directory authenticated the user using the user's
phone number.

When people envision seemless email encryption they usually envision it
detecting that the recipient has a key and either prompting the sender to
encrypt or just encrypting automatically.

- Privacy. TS sends your entire address book to the server and tells you
which contacts have TS. Are we going to do this for email? Or are we going
to do per-email queries? How does it handle the "user is composing offline"
case?  In TS, you can't send a message to someone who doesn't have a key -
that problem doesn't exist.

I'm confident there are others, I half-composed a few more, but I'll leave
them to another time.

On 2 June 2015 at 00:07, Watson Ladd <watsonbladd@gmail.com> wrote:
> It's clear to me that this isn't easily fixable by standards work
> alone

I agree.

> much of the damage is baked in to the functioning of S/MIME and
> PGP.

I'm not sure I agree with this point though.  PGP at least is flexible
enough that you don't care about interoperability, you can select a subset
of functionality and build your system on top of that.  And then if you
reach critical mass, you can make people want to interoperate with *you*.
Which is basically what Google did, Yahoo followed suite, and if they
succeed as much as they wish to - we will in turn follow.

> What needs to happen is that we need to come up with good ideas
> around key management that are actually deployable, and provide the
> semantics people want.

I agree-ish.  I think we need to come up with good implementations and user
experiences of key management - not just ideas.

-tom

[0] I say Authenticity instead of Discovery, because one can reasonably
point to a Keyserver and say "Discovery is solved."  But the on the scale
of Authenticity, keyservers have zero, and a central directory has "some,
but not all".