Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver

Phil Pennock <ietf-phil-openpgp@spodhuis.org> Mon, 08 April 2019 23:15 UTC

Return-Path: <ietf-phil-openpgp@spodhuis.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C45120125 for <openpgp@ietfa.amsl.com>; Mon, 8 Apr 2019 16:15:36 -0700 (PDT)
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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=spodhuis.org header.b=UppMrXlq; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=spodhuis.org header.b=51RrltTP
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 htj9e3da5JgN for <openpgp@ietfa.amsl.com>; Mon, 8 Apr 2019 16:15:33 -0700 (PDT)
Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (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 E61C4120123 for <openpgp@ietf.org>; Mon, 8 Apr 2019 16:15:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201902; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=rqZuf3kMi2WDa6OprTdbL4qiCWC4rSTwil//boUg+ro=; b=UppMrXlqfxpmnWsPp/AojYvF4i eHEy3feooYmbsE5yPKhMzxpsYDfFSNiLKzjznVNb3sGwI1qNc2ETHbZ0pkhTfS1mzKBp6otQlbhVw kgFJcxdLSqjia/CQOFE+zjcI3OMJRk2mFxKoxu9O0JUaTpq3AHQBzPwXzkIq56c7xDQ4HBBile8bk SgtZR5qMZZFZvS260ARAu4PtCf31cNphzE0tcGtHTVBLH0Kx1oCmI1ziKum48v9IgOAaSzP3iHNRz +JukheQ05Mnk1oFkpv0SvuvWPKhHaolJhnDqkQVwcDV4XRHYKps/3tUFwr5udtiPsJPkjnQ/4+WbF CyF8RqTw==;
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201902e2; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rqZuf3kMi2WDa6OprTdbL4qiCWC4rSTwil//boUg+ro=; b=51RrltTPXyZ9X/Dgs5ySk7xQA Pgc4h4NmnFhqP2hCL8kqAQT1rmvil/vmn2+msTpT4KGiiWSGmg93b3jvvFCCw==;
Received: from authenticated user by smtp.spodhuis.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1hDcic-0007tG-V8; Mon, 08 Apr 2019 22:26:23 +0000
Date: Mon, 08 Apr 2019 18:26:20 -0400
From: Phil Pennock <ietf-phil-openpgp@spodhuis.org>
To: openpgp@ietf.org, SKS development list <sks-devel@nongnu.org>
Message-ID: <20190408222619.GA81055@osmium.pennocktech.home.arpa>
Mail-Followup-To: openpgp@ietf.org, SKS development list <sks-devel@nongnu.org>
References: <87v9zt2y2d.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87v9zt2y2d.fsf@fifthhorseman.net>
OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/ctxWC9BglBemPi1GauScvFwUses>
Subject: Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2019 23:15:37 -0000

On 2019-04-04 at 18:41 -0400, Daniel Kahn Gillmor wrote:
> I've documented some thoughts on how to resist this abuse in a new
> Internet Draft:
> 
>    https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-keystore/

Hey, this is good stuff.  Thanks.

The references section uses my name in the SKS reference.  While I
certainly wrote much of (a vast majority of?) the SKS operational
documentation, I did not write SKS and am no longer at all involved in
it.  Another person's name should probably go there.

The rest of this mail is on just one topic; otherwise it'll get too long.

Others are suggesting blockchain approaches.  This makes the reason that
I stopped volunteering my time and resources to host an SKS instance, and
helping others to do so, relevant: people create spamming tools which
make it easier for non-technical users to abuse the append-only trust
stores; history has shown that this ease-of-abuse barrier-lowering does
directly lead to more abuse, including attempts to just spoil the entire
keyserver system.

In my jurisdiction (and under my own ethical code) the big concern was
child porn: not because it's a sane means of distribution, but because
of the spoiling effect.  Even without graphical-representation attribute
packets, there is speech which causes trouble in some parts of the
world.  Eg, in Europe, folks can insist upon having their own data be
removed.  This happened, a decade ago, leading Peter Palfrader to shut
down his keyserver after receiving a legal demand to delete a key from
the keyservers.

So locking down towards a "blockchain" approach (with whichever subset
of functionality the speaker intends that to mean, usually just a merkle
tree), trendy as it might be, risks creating a system where the
operators don't dare host the data sets.  Financial blockchain systems
might be able to bear the risk because once there's money involved,
there will be pushback against censorship, but a OpenPGP key blockchain
would not have that politically powerful vested interest protection.

An append-only system where the operator of a keyserver has no ability
to filter what makes it onto local storage would not entice this former
keyserver operator back into the fold.

It turns out that "ability to resist censorship by governments with
global reach" is not directly the biggest threat model and trying to
protect against it will hinder protections against the actual abuse
observed.  As long as OpenPGP client implementations don't get tied into
only one keyserver interaction method, and instead keep WKD and other
approaches, there are plenty of ways to get keys out there; preferred
keyserver annotations help too.  Folks who need to bypass extreme
censorship will likely need to use private keyserver setups, eg run
along SecureDrop by friendly organisations.

-Phil