Re: [openpgp] Mailing lists
"Neal H. Walfield" <neal@walfield.org> Sat, 25 July 2015 11:11 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 680851A219B for <openpgp@ietfa.amsl.com>; Sat, 25 Jul 2015 04:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 H4XxXyUCAP5N for <openpgp@ietfa.amsl.com>; Sat, 25 Jul 2015 04:11:12 -0700 (PDT)
Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 756B71A014E for <openpgp@ietf.org>; Sat, 25 Jul 2015 04:11:12 -0700 (PDT)
Received: from p50813e87.dip0.t-ipconnect.de ([80.129.62.135] 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 1ZIxM8-0007sL-07; Sat, 25 Jul 2015 11:11:04 +0000
Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <neal@walfield.org>) id 1ZIxM5-0000MB-42; Sat, 25 Jul 2015 13:11:04 +0200
Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from <neal@walfield.org>) id 1ZIxM4-00081p-2n; Sat, 25 Jul 2015 13:11:00 +0200
Date: Sat, 25 Jul 2015 13:10:58 +0200
Message-ID: <87k2too5kt.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
In-Reply-To: <87twsxjdgj.fsf@alice.fifthhorseman.net>
References: <87bnfdldo3.wl-neal@walfield.org> <r422Ps-1075i-661367269E98480C97B5ED5AFD0A7627@Williams-MacBook-Pro.local> <874ml1krev.wl-neal@walfield.org> <CAMm+LwgsBLZY9R0_A=fSqL7U6g2wpc-Fa3qnJD2CJUL6qr1c0Q@mail.gmail.com> <871tg3kuyl.wl-neal@walfield.org> <87twsxjdgj.fsf@alice.fifthhorseman.net>
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.4 (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.20.253
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/7BHoDFtsGhKuLcKaUAVoWdqB-6c>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, Bill Frantz <frantz@pwpconsult.com>, IETF OpenPGP <openpgp@ietf.org>
Subject: Re: [openpgp] Mailing lists
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: Sat, 25 Jul 2015 11:11:14 -0000
Hi Daniel, Thanks for your comments! At Wed, 22 Jul 2015 01:30:36 +0200, Daniel Kahn Gillmor wrote: > > On Mon 2015-07-20 12:02:42 +0200, Neal H. Walfield wrote: > > There are two possibilities here. > > > > First, the mailing list software reencrypts the message. This means > > that the plaintext is handled on the server and that either the > > private key material is directly on the server or it is on a smartcard > > permanently attached to the server. In the former case, the key > > material can be stolen and in the later case, an attacker can send out > > fake messages until the break-in is discovered. This implies absolute > > trust in the provider. These issues limit the applicability of this > > solution. > > I think the goal of an attacker in most scenarios isn't key recovery, > but cleartext recovery. an attack on the remailer service doesn't need > access to the key even if it's on a smartcard, they just want to > compromise the server enough to read the messages after the server > decrypts and before it encrypts. I wonder if key recovery is as unimportant as you suggest. If I were an attacker, I wanted to spy on a mailing list, and I got local access to the box doing the reencryption, I'd rather get the private key and get out than maintain a presence on the box. This would seem to reduce the chance that I was discovered. But, perhaps I'm misunderstanding something. > This approach is clunky, and i agree that your approach is superior to > it for key management. however, both of these approaches also leak the > size of the subscriber list (as well as historical join and leave dates) > in the public keyring. Good point. This can be mitigated by adding cover traffic. Concretely: we update the subscriber list with a fixed frequency (e.g., everyday at midnight) and we add / remove a number of subscribers drawn from an exponential distribution (or vice versa). If there aren't enough real new subscribers, then we add some dummy subscribers. Of course, an adversary can more or less figure out the subscriber list by watching the SMTP traffic. My understanding is that although it is possible to encrypt SMTP traffic, no one actually verifies the keys, which makes the whole thing susceptible to MITM attacks. Of course, a MITM attack requires significantly more resources than simply analyzing data that is explicitly stored in a public database. > if they're re-using their normal > encryption-capable subkeys (or if they have User IDs attached) then > anyone who has access to the list's OpenPGP certificate is going to know > who all of the subscribers are. I think what you are saying is that all posters know who all of the subscribers are (rather than just the list admin). I'm not sure this is really a problem in practice. It's normal that subscribers know more or less who the posters are. > I haven't seen anyone re-tread this idea to use more modern crypto, but > i think it might work. > > The idea is (roughly, from memory) that you're using some sort of > discrete-log-based encryption key (e.g. el gamal, encryption-capable > ECC), and the list has a public key. All correspondence to the list is > encrypted to the list's public key. Thanks for pointing this out. I wasn't aware of this work. > Of course, none of this avoids the problem of a large "private" list > actually having the security of the weakest link in the group :/ True. But that is a people problem and there is nothing we can do about that at the OpenPGP level. I spent some time reviewing the PLES paper that you linked to and I see major security and usability problems with it. The first problem is a security problem. - Since the user has a new private key for each mailing list, it is not practical to store all the keys on a smart card. Thus, the keys will probably be stored on the user's hard drive. This significantly lowers the practical upper bound of the security of the system. The rest of the problems are usability problems. - When the user subscribes to a mailing list, the list manager sends the subscriber the private key. The subscriber needs to import this. I don't think current MUAs make this easy. - If the user wants to use the key from multiple machines, she needs to import it on all of them. It is currently not easy to securly move one private key from one machine to another. Moving many keys would be a serious pain. - It encourages a bad mind set: we tell users that private keys should never be exported and yet here is a counter example. You identified two weaknesses with my proposed approach: - It exposes the subscriber list to subscribers (including historical join / leave times). - It exposes the size of the subscriber list to the world. I think these weaknesses are genuine, but not severe. Regarding the first issue, in practice, subscribers know who the other subscribers are (or, at least the posters). With respect to the second issue, this can be mitigated using cover traffic (although this would place a large burden on the keyservers). Nevertheless, there is no way to stop a well funded adversary who can monitor SMTP traffic, which is a problem for both systems. Do you still think we should drop my proposal? Thanks, Neal
- Re: [openpgp] Mailing lists Bill Frantz
- [openpgp] Mailing lists Neal H. Walfield
- Re: [openpgp] Mailing lists Neal H. Walfield
- Re: [openpgp] Mailing lists Phillip Hallam-Baker
- Re: [openpgp] Mailing lists Bill Frantz
- Re: [openpgp] Mailing lists Phillip Hallam-Baker
- Re: [openpgp] Mailing lists Neal H. Walfield
- Re: [openpgp] Mailing lists Neal H. Walfield
- Re: [openpgp] Mailing lists Neal H. Walfield
- Re: [openpgp] Mailing lists Daniel Kahn Gillmor
- Re: [openpgp] Mailing lists Phillip Hallam-Baker
- Re: [openpgp] Mailing lists Neal H. Walfield
- Re: [openpgp] Mailing lists Florian Weimer