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

Jonathan McDowell <noodles@earth.li> Fri, 05 April 2019 09:13 UTC

Return-Path: <noodles@earth.li>
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 6B2151200DF for <openpgp@ietfa.amsl.com>; Fri, 5 Apr 2019 02:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earth.li
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 5hBv-GZZNekB for <openpgp@ietfa.amsl.com>; Fri, 5 Apr 2019 02:13:23 -0700 (PDT)
Received: from the.earth.li (the.earth.li [IPv6:2001:41c8:10:b1f:c0ff:ee:15:900d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD1D120398 for <openpgp@ietf.org>; Fri, 5 Apr 2019 02:13:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=earth.li; s=the; 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=Gqpoe8zzAnJ4wbAmUpRZKpo7YuMToa+Y1oJevEOmnoY=; b=I2RnbpwErvw0FBOCn3ZPGagZsY muy+LmrtQeSO+GltHdY1o7D5r3kxu1uXj3Dgyz88xJ8AZZixqsTxkC7OQ/ytv/+p78xa2AJJLnUzn EloxYN2canTjv4sb2AZJdiZR/yQAZtvRTdwVJWGDViUVVPRC75E2ZB6VeFQxOBv2pLwzslGPhmS7k xLs4CY9h9lFmnQkxyc6NkArUPVc74m8rqcXVTqIDMrM6YtwRlGL4iSdFdTWQ9Sn/T0YBb10C9a2cC APSzOh2DrQDrE5CyFIZmNH5ov9UMRZLPzzgBtl2Y2Kl2vS46vUUKafZwC5XLQ6yCWC/fWk17Nr0zC PBEH8BsA==;
Received: from noodles by the.earth.li with local (Exim 4.89) (envelope-from <noodles@earth.li>) id 1hCKuX-0002xx-4W for openpgp@ietf.org; Fri, 05 Apr 2019 10:13:21 +0100
Date: Fri, 05 Apr 2019 10:13:20 +0100
From: Jonathan McDowell <noodles@earth.li>
To: openpgp@ietf.org
Message-ID: <20190405091320.mnkbjvsrn5jm46z5@earth.li>
References: <87v9zt2y2d.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="qlhq5vucaniduhvm"
Content-Disposition: inline
In-Reply-To: <87v9zt2y2d.fsf@fifthhorseman.net>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/jHBDfNc_bOR1jQ_o66k59M4EaQs>
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: Fri, 05 Apr 2019 09:13:26 -0000

On Thu, Apr 04, 2019 at 06:41:14PM -0400, Daniel Kahn Gillmor wrote:
> As you may or may not have heard, the venerable OpenPGP keyserver
> network is dying.  This has implications for key discovery, revocation,
> subkey rollover, expiration update, etc. across the ecosystem of tools
> that use OpenPGP.
> 
> The keyserver network dying because of several reasons, some of which
> are discussed in a thread over at [0] -- but one main
> issue is that the SKS keyserver network allows anyone to attach
> arbitrary data to any OpenPGP certificate, bloating that certificate to
> the point of being impossible to effectively retrieve.  SKS isn't the
> only keyserver that is vulnerable to this kind of attack either [1].

I like the suggestions you've made so far (though I think do think that
various people seem to find image UATs useful, so limiting the packet
size to 8383 is overly limiting).

One additional thought I've had in the past is that if the keyserver is
capable of cryptographic verification it could only accept new keys that
are signed by an existing key. This would prevent a random flood of
unconnected keys (such as Evil32), and mean that in the event of such a
set of keys being uploaded it would be easy to trace which signature was
the link (and potentially blacklist that key).

J.

-- 
... I'm dangerous when I know what I'm doing.