[openpgp] mailing list: managing the subscriber list
"Neal H. Walfield" <neal@walfield.org> Sun, 10 January 2016 21:34 UTC
Return-Path: <neal@walfield.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CAF1A00D7 for <openpgp@ietfa.amsl.com>; Sun, 10 Jan 2016 13:34:06 -0800 (PST)
X-Quarantine-ID: <D75da057jAhb>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "To"
X-Spam-Flag: NO
X-Spam-Score: 1.149
X-Spam-Level: *
X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, SPF_HELO_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 D75da057jAhb for <openpgp@ietfa.amsl.com>; Sun, 10 Jan 2016 13:34:04 -0800 (PST)
Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id CEAE11A00B1 for <openpgp@ietf.org>; Sun, 10 Jan 2016 13:34:03 -0800 (PST)
Received: from p5ddf9601.dip0.t-ipconnect.de ([93.223.150.1] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from <neal@walfield.org>) id 1aINca-0003Vk-So; Sun, 10 Jan 2016 21:33:57 +0000
Received: from [192.168.54.11] (helo=chu.huenfield.org) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <neal@walfield.org>) id 1aINcW-0006qn-Cx; Sun, 10 Jan 2016 22:33:56 +0100
Received: from localhost ([::1] helo=chu.huenfield.org.walfield.org) by chu.huenfield.org with esmtp (Exim 4.84) (envelope-from <neal@walfield.org>) id 1aINcS-0000tX-S8; Sun, 10 Jan 2016 22:33:48 +0100
Date: Sun, 10 Jan 2016 22:33:48 +0100
Message-ID: <87ziwd3yrn.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: openpgp@ietf.org
to: Matthew Green <matthewdgreen@gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-SA-Exim-Connect-IP: 192.168.54.11
X-SA-Exim-Mail-From: neal@walfield.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000)
X-SA-Exim-Scanned: Yes (on mail.huenfield.org)
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/UuWVSrMu8LEdChEBQgEpBtQR3-Y>
Subject: [openpgp] mailing list: managing the subscriber list
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 10 Jan 2016 21:34:06 -0000
Hi, Back in July, I made a small, informal proposal about adding support for encrypted mailing lists to OpenPGP: http://mailarchive.ietf.org/arch/msg/openpgp/GAIKx4Ud8CcB-D9uPodeGdQgoGc I now have a bit of free time and have begun fleshing out the design and adding support for it to GnuPG. The thrust of the proposal was to add the list of subscribers to an OpenPGP key and use the existing key distribution mechanisms to ensure the list is propagated to posters. There are two main issues: how to store the subscriber list and how to deal with updates (i.e., subscribe and unsubscribe events). In my proposal, I suggested storing the subscriber list in a mailing-list specific key block. This immediately addresses the distribution problem: the key servers and the OpenPGP implementations already solve the key distribution problem. I see three possible ways to store the subscriber list. We store the data in a dedicated signature subpacket (my original suggestion), in a signature notation, or use a new packet type. Subpackets and notations have the disadvantage that the values are limited to 64k (Sections 5.2.3 & 5.2.3.16). As such they impose an artificial limitation, which is particularly relevant if we were to use them to store the entire subscriber list. The obvious fix would be to increase the allowable length of these data structures in 4880bis. I see two main approaches to dealing with updates. After each update either publish the full, updated list (full update mode); or, just publish the individual events (incremental update mode). Full update mode is relatively straightforward, but has a significant disadvantage: since keyservers don't throw away old data, the key blocks can get big fast. Concretely, if N people subscribe to a new mailing list, this will result in N updates, which consume O(N^2) space. In incremental mode, N updates only consume O(N) space (but the hidden constant is likely much bigger). Incremental update mode's most important weakness is that it can't easily support hidden subscriber lists. To hide the subscriber list, we need to encrypt it so that just authorized posters can read it. Because a new poster can't read the encrypted list of subscribers, we have to reencrypt it. Since the list of subscribers and the list of posters is normally identical, each new subscription requires publishing the full list of subscribers. In other words, incremental update mode is usually approximately equivalent to full update mode when encrypting the subscriber list. Another issue with incremental update mode is that it is possible for an attacker intercepting the user's key server requests to prevent some packets from reaching the user. This attack can be detected by turning the updates into a hash chain. Now, a new poster can detect if there are any missing blocks prior to the most recently received update. That is, if there have been four updates, A, B, C and D, and a requested key block only includes A and C, the user can detect that at least one update is missing between A and C, but has no way to determine that D is missing. In full update mode, C effectively includes B so a missing B is irrelevant. In terms of detecting a missing D, full update mode doesn't help. Another attack that both approaches are susceptible to, at least for public mailing lists, is a denial of service attack that results in enormous key blocks. To execute this attack, an attacker just needs to cause many updates. In practice, this isn't likely to work very well since the list maintainer has to sign each update and thus such attacks are likely to be obvious and easily blocked. Nevertheless, the mitigation is obvious and still useful in practice: delay and batch updates. The delay occurs naturally, because (normally) the list maintainer has to sign each update. Batching updates should also be straightforward since neither approach naturally precludes them. I think a reasonable approach would be to use a subkey packet for each subscriber. The "subkeys" would be bound to the mailing list key in the usual fashion and unsubscribe events could be handled using revocations. Since we only need to save one encryption key per user and each user's preferences, this fits quite well within the existing data structures. A bit of care needs to be taken to ensure that users can unsubscribe and later resubscribe. Unfortunately, this approach doesn't work well with hidden subscriber lists, as far as I can see. To deal with hidden subscriber lists, I think we have to use full update mode. In this case, I think a new packet type is required, which would be an optionally encrypted message consisting of an array of encryption keys and user preferences. To get the best of both worlds, we could support both approaches and allow the mailing list's requirements to guide the selection, but I'm not sure that this added complexity is justified. Alternatively, if we aren't interested in support encrypted mailing lists to foil mass surveillance and we agree that something like a few dozen people is the maximum number of people who can keep a secret, we can just use the existing notation mechanism. If anyone has any additional thoughts, I'd be happy to hear them. Thanks! :) Neal
- [openpgp] mailing list: managing the subscriber l… Neal H. Walfield
- Re: [openpgp] mailing list: managing the subscrib… Rick van Rein
- Re: [openpgp] mailing list: managing the subscrib… Neal H. Walfield
- Re: [openpgp] mailing list: managing the subscrib… Rick van Rein
- Re: [openpgp] mailing list: managing the subscrib… Werner Koch
- Re: [openpgp] mailing list: managing the subscrib… Neal H. Walfield
- Re: [openpgp] mailing list: managing the subscrib… Neal H. Walfield
- Re: [openpgp] mailing list: managing the subscrib… vedaal
- Re: [openpgp] mailing list: managing the subscrib… Phillip Hallam-Baker