From nobody Fri Jan 1 20:06:24 2016 Return-Path: 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 C466B1B2A5B for ; Fri, 1 Jan 2016 20:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Gt4P4MSaLUob for ; Fri, 1 Jan 2016 20:06:21 -0800 (PST) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id AD9071B2A59 for ; Fri, 1 Jan 2016 20:06:21 -0800 (PST) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 6A0B211C17FC; Sat, 2 Jan 2016 15:06:20 +1100 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0_81kyM-QWLm; Sat, 2 Jan 2016 15:06:15 +1100 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 77BDE11C15F9; Sat, 2 Jan 2016 15:06:14 +1100 (EST) To: "Neal H. Walfield" , Derek Atkins References: <87io5j764u.wl-neal@walfield.org> <87h9l36tf1.wl-neal@walfield.org> From: Ben McGinnes Openpgp: id=DB4724E6FA4286C92B4E55C4321E4E2373590E5D; url=http://www.adversary.org/ben-key.asc Message-ID: <56874CB5.7060806@adversary.org> Date: Sat, 2 Jan 2016 15:06:13 +1100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <87h9l36tf1.wl-neal@walfield.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fxtDVsUR6oJ2ax4xjmSn4TICqqPK36PmF" Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Reducing the meta-data leak X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2016 04:06:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fxtDVsUR6oJ2ax4xjmSn4TICqqPK36PmF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/11/2015 1:37 am, Neal H. Walfield wrote: >=20 > Bryan Ford proposed getting rid of all unencrypted meta-data. In > particular, he wanted to get rid of the recipients / number of > recipients. >=20 > There are some practical difficulties with this approach, > which I mentioned above. >=20 > My proposal is a blue sky idea to avoid having to try to decrypt a > message with every secret key while (hopefully) making it more > difficult to get at the list of recipients. While I don't doubt the good intentions, I fail to see how this has any real value. Specifically because of the significantly larger amounts of meta-data which already leaks from every SMTP exchange ever. That's the real threat and that inevitably leads to this question: * In what scenario has someone gone to the effort of disguising all their SMTP traffic (remailers, tor, whatever), but not selected an alias on the OpenPGP key they're using? Regards, Ben --fxtDVsUR6oJ2ax4xjmSn4TICqqPK36PmF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJWh0y1AAoJEH/y03E1x1U8k0IL/1cN0sgt4/5zIx70BBzWQpUK b81i6Gy/kxdhibaQanL8LsocQRRDp0nNgjq262oEB3AFQ9mjT8qmloclz9gh6bQn +IMpcXw/RxGLbLN7du67ytd8fwMmNG2jHDGpO+tFmQrJM91PtTK6HAIyN42jdyKL ZTw6v/SrNF8BGfoAwXuADNlqBnncUKQGViQofIJee1A9leXLX6HTxevvtycyEbDN sOETWldtdPsF/8DE2J8HPqP6EB9DNQfZVvI6r9CQcYJCox/aQiM4HoC/LBQnxEUW jesTTTs0UZb5LvEIztZSgLHdFjN3nY65G8UJmnWvDsLZGpBmXD8RFDsOTymtwqSU ZLgvJQI+IaOvb/XjQ9VTiMPtEFfk9RwXR5776xvGK6WDx9VXFkbQh86Ptgo7Fijh XEa9/aT1GEQZZBl/VJ+eIXE1XkdFgW5hJ3zornCGPtxWBbjSEOBxsJUyGsNaFSIT aEbyCuZ3suaF2Hfj0Sv3j1Rlm4jdEW/cAna3myLnsg== =tE4A -----END PGP SIGNATURE----- --fxtDVsUR6oJ2ax4xjmSn4TICqqPK36PmF-- From nobody Mon Jan 4 03:50:16 2016 Return-Path: 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 27DF51A0354 for ; Mon, 4 Jan 2016 03:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 64wHR3_tuG-7 for ; Mon, 4 Jan 2016 03:50:11 -0800 (PST) Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (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 F121D1A033A for ; Mon, 4 Jan 2016 03:50:10 -0800 (PST) Received: from dovecot03.posteo.de (dovecot03.posteo.de [172.16.0.13]) by mout01.posteo.de (Postfix) with ESMTPS id E02DB2081F for ; Mon, 4 Jan 2016 12:50:07 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3pYwHf5z8Cz5vMr; Mon, 4 Jan 2016 12:50:06 +0100 (CET) References: <20151230115130.GA17604@localhost.localdomain> <5683D5BA.8050208@googlemail.com> From: Forler X-Enigmail-Draft-Status: N1110 To: openpgp@ietf.org, guilhem@fripost.org Message-ID: <568A5C6D.7090301@posteo.de> Date: Mon, 4 Jan 2016 12:50:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <5683D5BA.8050208@googlemail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qLaMX398EQ8JDg6k6AAi5DkB8X0feEXt0" Archived-At: Subject: Re: [openpgp] Chunked OpenPGP streams X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 11:50:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qLaMX398EQ8JDg6k6AAi5DkB8X0feEXt0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 30.12.2015 at 14:01 Nils Durner wrote: > Hi, > > > I wonder if chunked streams could make their way to RFC4880bis instea= d. > > The verification mechanism (MDC or data signature) would be added to > > each chunk using the intermediate hash value, > > I think this goes in the same direction that OAED or online > authenticating cipher modes are being considered for - see the recordin= g > of the last IETF meeting at > http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF94_OPEN= PGP&chapter=3Dchapter_1 > > Regarding the potential use of online authenticating cipher modes, it > was discussed during that meeting that there is *some* research on mode= s > that *might* be usable with PGP. If anyone can share papers (or > references), I would appreciate it. Disclaimer: I am a co-author of the POET submission, and therefore my suggestions might be biased. :) As far as I know, the PGP community want to verify the integrity of individual ciphertext chunks. This goal can be achieved by OAEAD schemes that support intermediate tags such as * - ELmDv2 (*http://competitions.cr.yp.to/round2/elmdv20.pdf) or - POETv2.01=20 (https://www.uni-weimar.de/fileadmin/user/fak/medien/professuren/Mediensi= cherheit/Research/Publications/poet_v2.01.pdf). Best regards, Christian =20 --qLaMX398EQ8JDg6k6AAi5DkB8X0feEXt0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWilxtAAoJEE/G1DAGIfi3zTEH/3Ig4qADfZ8y52FrfKGinoPi v7/IEHsmWglHEL2XTyUIsKISK+Tyuv1BI5nF0glRebkD3vjNSrzA724IA9kJ92K+ lKnLtN9YcEdBgg+AjO9V6ryL/dKkf1bY5OVODzqgkl8VCQrugK7hxp5MplgWQvbv X3X7kkU73kPgs+2nFspX7r/kUuTo4w77aA6GrgNMZ59Ac/5ZaI5ydTCmagL544H7 J2cVW3HAd/OTMfy7mZlwp8d4FZcpbpUih0l2dRBeK+Jks3YA376aKxkvO68QEF8S XORHiWrjlTn0Jem0MaQO6GqOsZQqqnnw9/tL5rVyeJ8ykEVCgZkERAzEMPeb+3s= =QHxg -----END PGP SIGNATURE----- --qLaMX398EQ8JDg6k6AAi5DkB8X0feEXt0-- From nobody Mon Jan 4 16:43:47 2016 Return-Path: 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 9FE771ACDC4 for ; Mon, 4 Jan 2016 16:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham 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 gV_QCnSUAo0M for ; Mon, 4 Jan 2016 16:43:44 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C42071ACDC2 for ; Mon, 4 Jan 2016 16:43:43 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 27649F984; Mon, 4 Jan 2016 19:43:36 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 4CF6B201EF; Mon, 4 Jan 2016 19:43:35 -0500 (EST) From: Daniel Kahn Gillmor To: Ben McGinnes , "Neal H. Walfield" , Derek Atkins In-Reply-To: <56874CB5.7060806@adversary.org> References: <87io5j764u.wl-neal@walfield.org> <87h9l36tf1.wl-neal@walfield.org> <56874CB5.7060806@adversary.org> User-Agent: Notmuch/0.21+39~gd2ae295 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 04 Jan 2016 19:43:35 -0500 Message-ID: <87d1tgzwi0.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Reducing the meta-data leak X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 00:43:45 -0000 On Fri 2016-01-01 23:06:13 -0500, Ben McGinnes wrote: > On 4/11/2015 1:37 am, Neal H. Walfield wrote: >> >> Bryan Ford proposed getting rid of all unencrypted meta-data. In >> particular, he wanted to get rid of the recipients / number of >> recipients. >> >> There are some practical difficulties with this approach, >> which I mentioned above. >> >> My proposal is a blue sky idea to avoid having to try to decrypt a >> message with every secret key while (hopefully) making it more >> difficult to get at the list of recipients. > > While I don't doubt the good intentions, I fail to see how this has > any real value. Specifically because of the significantly larger > amounts of meta-data which already leaks from every SMTP exchange > ever. That's the real threat and that inevitably leads to this > question: > > * In what scenario has someone gone to the effort of disguising all > their SMTP traffic (remailers, tor, whatever), but not selected an > alias on the OpenPGP key they're using? fwiw, there is effort going into protecting some of the SMTP/RFC822 metadata (see the discussions in shutup@ietf.org), which would make this kind of work within OpenPGP more valuable than it currently is in the full-metadata-wrapped OpenPGP e-mail use case. It's worth thinking about this problem from the point of view of a single message encrypted to a single recipient. We already have the mechanisms to deal with multi-recipient messages: A sender who wants to craft a single message to N people without indicating the number of people should probably re-build the message N times, with a single PK-ESK on each. If they really cares that an observer can't tell that each recipient is getting the same message, they should presumably choose a separate SK for each version, and pad each message to different sizes as well. We can do all of the above except padding in OpenPGP as it stands, and padding can often be done in whatever format is being wrapped by OpenPGP (e.g. a text/plain MIME part consisting of all whitespace). Incidentally, the single-pkesk-per-message approach addresses the smartcard UI/UX concern, and mitigates the multiple-secret-key UI/UX concern somewhat (the multiple-secret-key UI/UX concern can be further mitigated by configuration recipient-side). Implementation work or guidance on avoiding creation of multi-recipient messages would be good. With regards to the bloom filter proposal here, i think Tom's concerns about its viability are worth heeding. In a single-recipient message, the bloom filter is effectively just a smaller hash of the key. The current PKESK itself already doesn't provide an unambiguous answer to who a message is encrypted to, since it provides only 64 bits of the fingerprint, and we know that there are pairs of keys that share their lower 64 bits of fingerprint. We could simply reduce the size of that further to get more ambiguity (the distribution should already be uniform) but the ambiguity is already on the edge of being a problem for UI (it's not clear whether a UI should announce "this message claims to be for key XXXXX, which we have, but cannot be decrypted with it" or "this message claims to be for keyid XX, and while we have key XXXXX which can't decrypt it, the sender might have meant some other key"). Yuck. Removing the metadata of who a message is for seems likely to require either: a) trial decryption on the recipient side (problematic for smartcard and multiple-secret-key setups, as Neal and Werner pointed out), or b) some sort of racheted shared state between sender and recipient (e.g. a briar- or axolotl-style esk, which might provide other nice features, like "deletable" ("forward-secret") messages) While (b) is out of scope for us here until we get 4880bis sorted, if someone wanted to experiment with that and report back, i'm sure it would be interesting to several people on the list. Or maybe there's a (c) option? --dkg From nobody Mon Jan 4 17:24:16 2016 Return-Path: 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 247C41ACE23 for ; Mon, 4 Jan 2016 17:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3PtHe6LtD9la for ; Mon, 4 Jan 2016 17:24:13 -0800 (PST) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5219A1ACE22 for ; Mon, 4 Jan 2016 17:24:13 -0800 (PST) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id ED53811C178C; Tue, 5 Jan 2016 12:24:11 +1100 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wx_aQWkoRx92; Tue, 5 Jan 2016 12:24:05 +1100 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id AC31A11C015D; Tue, 5 Jan 2016 12:24:04 +1100 (EST) To: Daniel Kahn Gillmor , "Neal H. Walfield" , Derek Atkins References: <87io5j764u.wl-neal@walfield.org> <87h9l36tf1.wl-neal@walfield.org> <56874CB5.7060806@adversary.org> <87d1tgzwi0.fsf@alice.fifthhorseman.net> From: Ben McGinnes Openpgp: id=DB4724E6FA4286C92B4E55C4321E4E2373590E5D; url=http://www.adversary.org/ben-key.asc Message-ID: <568B1B25.7020202@adversary.org> Date: Tue, 5 Jan 2016 12:23:49 +1100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <87d1tgzwi0.fsf@alice.fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sDbRT7VtE1AUB4h7PeBaLBtLFC8elUEQV" Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Reducing the meta-data leak X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 01:24:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sDbRT7VtE1AUB4h7PeBaLBtLFC8elUEQV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/01/2016 11:43 am, Daniel Kahn Gillmor wrote: >=20 > fwiw, there is effort going into protecting some of the SMTP/RFC822 > metadata (see the discussions in shutup@ietf.org), which would make > this kind of work within OpenPGP more valuable than it currently is > in the full-metadata-wrapped OpenPGP e-mail use case. With a list name like that I'm just going to have to check it out. > Removing the metadata of who a message is for seems likely to require > either: >=20 > a) trial decryption on the recipient side (problematic for smartcard > and multiple-secret-key setups, as Neal and Werner pointed out), or= >=20 > b) some sort of racheted shared state between sender and recipient > (e.g. a briar- or axolotl-style esk, which might provide other nice= > features, like "deletable" ("forward-secret") messages) >=20 > While (b) is out of scope for us here until we get 4880bis sorted, if > someone wanted to experiment with that and report back, i'm sure it > would be interesting to several people on the list. >=20 > Or maybe there's a (c) option? There is, but I can't recall if I've mentioned it on this list or not, but I know it's been mentioned on gnupg-users because that's how I found out about it: http://www.confidantmail.org/ An attempt at side-stepping SMTP entirely and replacing the transport method with one of the methods used by BitTorrent. It relies on GPG for the message encryption and everything is contained within the encrypted zip. The only addressing metadata is the key UID which is of the format of: any-damn-thing-you-like@somehost-including-tor-hidden-sites-and-i2p-it-do= esn't-care It even includes a clever means of achieving forward secrecy, but arguably it could benefit from hiding the OpenPGP metadata a little better. Regards, Ben --sDbRT7VtE1AUB4h7PeBaLBtLFC8elUEQV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJWixsmAAoJEH/y03E1x1U8JscL/i5V70ZNtd1PIC+BOgQs+py7 uIF2GkCZJAgrtPI6LCaoIqWdasW+gSjwl9mFLteyM9FvCTkrng5vjwID5Y/seS08 TA9UU/XE0R6eXErZUMRZwy5IEtwrMRQxz0bReQ/I7L9qbRgDEiEdZHXziyw4L68U uHZiU6HcSJNqcqWWgxaEoc9QiIwQu8g2bnEeZdoDn7B7uSneEih/srWMqFLZCLEV 54AlwExOTVG2SKZV86VW1FyeCVFYPmVAiajLYsyMdbfep02GXToY4jmEtdDjoY1t JcQgFIHGcuw2ybc7wP08WBmkatFG8TrA2VRzw6qwSjdvvay7+VCDNZziHDqAGMB9 3e+Lzivn6tKzB91uXipZTJWj8L0VpRO/Y+/RTwCo+KPt8FnCRpbWDIpA8q7OOfsT x8ueEy57oB1Vq8ZdfNnlsPPN4GK8a3XqdZUZdmlIAKSAIzYIKgdXTYbizKSRXrig BWKltK86uCXbmmbB309/hFqW8OdJQJGxSXSUMYYWqQ== =ODre -----END PGP SIGNATURE----- --sDbRT7VtE1AUB4h7PeBaLBtLFC8elUEQV-- From nobody Mon Jan 4 19:15:44 2016 Return-Path: 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 46D3E1ACEDF for ; Mon, 4 Jan 2016 19:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ztryHL50I_A8 for ; Mon, 4 Jan 2016 19:15:41 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id BD7A91ACEDD for ; Mon, 4 Jan 2016 19:15:41 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 42242F989; Mon, 4 Jan 2016 22:15:38 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 947C620041; Mon, 4 Jan 2016 22:15:38 -0500 (EST) From: Daniel Kahn Gillmor To: Ben McGinnes , "Neal H. Walfield" , Derek Atkins In-Reply-To: <568B1B25.7020202@adversary.org> References: <87io5j764u.wl-neal@walfield.org> <87h9l36tf1.wl-neal@walfield.org> <56874CB5.7060806@adversary.org> <87d1tgzwi0.fsf@alice.fifthhorseman.net> <568B1B25.7020202@adversary.org> User-Agent: Notmuch/0.21+39~gd2ae295 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 04 Jan 2016 22:15:38 -0500 Message-ID: <87twmsyaw5.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Reducing the meta-data leak X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 03:15:43 -0000 On Mon 2016-01-04 20:23:49 -0500, Ben McGinnes wrote: >> Removing the metadata of who a message is for seems likely to require >> either: >> >> a) trial decryption on the recipient side (problematic for smartcard >> and multiple-secret-key setups, as Neal and Werner pointed out), or >> >> b) some sort of racheted shared state between sender and recipient >> (e.g. a briar- or axolotl-style esk, which might provide other nice >> features, like "deletable" ("forward-secret") messages) >> >> While (b) is out of scope for us here until we get 4880bis sorted, if >> someone wanted to experiment with that and report back, i'm sure it >> would be interesting to several people on the list. >> >> Or maybe there's a (c) option? > > There is, but I can't recall if I've mentioned it on this list or not, > but I know it's been mentioned on gnupg-users because that's how I > found out about it: > > http://www.confidantmail.org/ > > An attempt at side-stepping SMTP entirely and replacing the transport > method with one of the methods used by BitTorrent. It relies on GPG > for the message encryption and everything is contained within the > encrypted zip. The only addressing metadata is the key UID which is > of the format of: > > any-damn-thing-you-like@somehost-including-tor-hidden-sites-and-i2p-it-doesn't-care > > It even includes a clever means of achieving forward secrecy, but > arguably it could benefit from hiding the OpenPGP metadata a little > better. This sounds like an effort to hide the SMTP metadata, but doesn't involve hiding the metadata in the OpenPGP format itself. While i think this is a neat idea, i'm not convinced it's addressing the same problems that (a) and (b) are addressing. --dkg From nobody Tue Jan 5 11:50:30 2016 Return-Path: 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 4759C1B2D51 for ; Tue, 5 Jan 2016 11:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.076 X-Spam-Level: X-Spam-Status: No, score=-0.076 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 fKOBPviyRFWk for ; Tue, 5 Jan 2016 11:50:26 -0800 (PST) Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) (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 219001B2D4E for ; Tue, 5 Jan 2016 11:50:26 -0800 (PST) Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id 6F73F2020F for ; Tue, 5 Jan 2016 19:50:25 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=e+ytzcYiNs7XkVZLljGbSct0NLL9VPV1sQcyE9bMw/U=; b=Nqd03qSnFZCi+dVFe5JFJPurh7SquUpq8LVlus5e5yu/UJSpFdrr7PiSiaswRDBEr1pziprziezgWXJHyExslb6aZrBz5Zl6NAfM/dgOWdl7GYezpJSuFB22lwTGXONgYqZKmFDtZMe2RwZ7jTO2gRTof8UYf8Xku55ZD9WW65oq09RVX5iyoxesgNMSs5mGct55oz6EmSG9Pycwv47VUdTg0JyI76MZh/0g6KhZjZakzxKJV9G+ZzLajo7BDWfcqgWTl2zWYUBw1yp/GrTkSLZa4mgxaOYzx+4Fr3hRBdB7aQtC2LlykFMwaQcUex/kUklHsie8UDPvFRw1/4gmKQ== Received: from smtp.hushmail.com (w1.hushmail.com [65.39.178.83]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS; Tue, 5 Jan 2016 19:50:24 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id D3CC2200D0; Tue, 5 Jan 2016 19:50:24 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 05 Jan 2016 14:50:24 -0500 To: "Daniel Kahn Gillmor" , "Ben McGinnes" , "Neal H. Walfield" , "Derek Atkins" From: vedaal@nym.hush.com In-Reply-To: <87d1tgzwi0.fsf@alice.fifthhorseman.net> References: <87io5j764u.wl-neal@walfield.org> <87h9l36tf1.wl-neal@walfield.org> <56874CB5.7060806@adversary.org> <87d1tgzwi0.fsf@alice.fifthhorseman.net> Content-Type: multipart/alternative; boundary="=_79a28b169609dbce07cd0ef4b867a6c1" Message-Id: <20160105195024.D3CC2200D0@smtp.hushmail.com> Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Reducing the meta-data leak X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 19:50:27 -0000 --=_79a28b169609dbce07cd0ef4b867a6c1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" On 1/4/2016 at 7:43 PM, "Daniel Kahn Gillmor" wrote: Removing the metadata of who a message is for seems likely to require either: a) trial decryption on the recipient side (problematic for smartcard and multiple-secret-key setups, as Neal and Werner pointed out), or b) some sort of racheted shared state between sender and recipient (e.g. a briar- or axolotl-style esk, which might provide other nice features, like "deletable" ("forward-secret") messages) While (b) is out of scope for us here until we get 4880bis sorted, if someone wanted to experiment with that and report back, i'm sure it would be interesting to several people on the list. Or maybe there's a (c) option? ===== Maybe a (c) option that combines aspects of (a) and (b): [1] Suggesting that users of multiple secret keys have 1 unique e-mail address for key. (e.g. Hushmail allows for unlimited nym e-mail aliases which all go to the same hushmail account under the primary [non-nym] e-mail account.) A user can generate multiple keypairs, assigning a different nym alias to each of them). [2] The users should not upload the keys to keyservers, but rather exchange public keys with whomever they wish to communicate. [3] They then use the --throw-keyid option, but the receiver knows exactly which key it is, by seeing to which nym e-mail address it is sent. [4] No interceptor knows who the 'true' recipient is, except for e-mail client, which could be set up to do this without tracking, (i.e. (a) register for the e-mail client under a false name with a pre-paid no-name credit card (b) use an e-mail client that allows multiple nym aliases ) -- just a possible avenue of exploration as to how it might be done ... vedaal --=_79a28b169609dbce07cd0ef4b867a6c1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

On 1/4/2016 at= 7:43 PM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote:
Removing the metadata of who a message is for seems likely to requir= e
either:

a) trial decryption on the recipient side (problematic= for smartcard
and multiple-secret-key setups, as Neal and Werner po= inted out), or

b) some sort of racheted shared state between sender= and recipient
(e.g. a briar- or axolotl-style esk, which might prov= ide other nice
features, like "deletable" ("forward-secret") message= s)

While (b) is out of scope for us here until we get 4880bis sorted= , if
someone wanted to experiment with that and report back, i'm sure it=
would be interesting to several people on the list.

Or maybe the= re's a (c) option?


=3D=3D=3D=3D=3D

Maybe a (c) opt= ion that combines  aspects of (a) and (b):

[1] Suggesting that = users of multiple secret keys have 1 unique e-mail address for key.
(e.g= .  Hushmail allows for unlimited nym e-mail aliases which all go to th= e same hushmail account under the primary [non-nym] e-mail account.)
A u= ser can generate multiple keypairs, assigning a different nym alias to each= of them).

[2] The users should not upload the keys to keyservers, b= ut rather exchange public keys with whomever they wish to communicate.
<= br>[3] They then use the --throw-keyid option, but the receiver knows exact= ly which key it is, by seeing to which nym e-mail address it is sent.
[4] No interceptor knows who the 'true' recipient is, except for e-mail c= lient, which could be set up to do this without tracking,
(i.e. &nb= sp;
(a) register for the e-mail client under a false name with a pre-pa= id no-name credit card
(b) use an e-mail client that allows multiple nym= aliases  )


-- just a possible avenue of exploration as to = how it might be done ...


vedaal
 

--=_79a28b169609dbce07cd0ef4b867a6c1-- From nobody Tue Jan 5 11:54:56 2016 Return-Path: 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 39E4B1B2D57 for ; Tue, 5 Jan 2016 11:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 hHuHpgWHmkXj for ; Tue, 5 Jan 2016 11:54:54 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E5CD01B2D52 for ; Tue, 5 Jan 2016 11:54:53 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 095CFF984; Tue, 5 Jan 2016 14:54:47 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id DB29E200D1; Tue, 5 Jan 2016 14:54:46 -0500 (EST) From: Daniel Kahn Gillmor To: vedaal@nym.hush.com, Ben McGinnes , "Neal H. Walfield" , Derek Atkins In-Reply-To: <20160105195024.D3CC2200D0@smtp.hushmail.com> References: <87io5j764u.wl-neal@walfield.org> <87h9l36tf1.wl-neal@walfield.org> <56874CB5.7060806@adversary.org> <87d1tgzwi0.fsf@alice.fifthhorseman.net> <20160105195024.D3CC2200D0@smtp.hushmail.com> User-Agent: Notmuch/0.21+39~gd2ae295 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 05 Jan 2016 14:54:46 -0500 Message-ID: <87si2bvm2h.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Reducing the meta-data leak X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 19:54:55 -0000 On Tue 2016-01-05 14:50:24 -0500, vedaal@nym.hush.com wrote: > Maybe a (c) option that combines aspects of (a) and (b): > > [1] Suggesting that users of multiple secret keys have 1 unique e-mail > address for key. > (e.g. Hushmail allows for unlimited nym e-mail aliases which all go > to the same hushmail account under the primary [non-nym] e-mail > account.) > A user can generate multiple keypairs, assigning a different nym alias > to each of them). > > [2] The users should not upload the keys to keyservers, but rather > exchange public keys with whomever they wish to communicate. this seems like it might be handwaving away a very difficult question... > [3] They then use the --throw-keyid option, but the receiver knows > exactly which key it is, by seeing to which nym e-mail address it is > sent. if the receiver can see it, then the metadata is present, right? so this proposal just moves the metadata out of the OpenPGP block and into the surrounding RFC822 message. I don't think that solves the problem. or am i misunderstanding your proposal? --dkg From nobody Sun Jan 10 13:34:08 2016 Return-Path: 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 ; Sun, 10 Jan 2016 13:34:06 -0800 (PST) X-Quarantine-ID: 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 ; 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 ; 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 ) 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 ) 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 ) 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" To: openpgp@ietf.org to: Matthew Green User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Mon Jan 11 03:01:52 2016 Return-Path: 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 EA60F1A88FD for ; Mon, 11 Jan 2016 03:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 MeRY9dPII2sz for ; Mon, 11 Jan 2016 03:01:49 -0800 (PST) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6951A87D4 for ; Mon, 11 Jan 2016 03:01:49 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id 4b1l1s00d10HQrX01b1n9v; Mon, 11 Jan 2016 12:01:47 +0100 Message-ID: <56938B98.7000707@openfortress.nl> Date: Mon, 11 Jan 2016 12:01:44 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Neal H. Walfield" References: <87ziwd3yrn.wl-neal@walfield.org> In-Reply-To: <87ziwd3yrn.wl-neal@walfield.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: openpgp@ietf.org, Matthew Green Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 11:01:52 -0000 Hello Neal, You are getting into a topic that has my interest. To me, a mailing list is just an example of encryption things to a group. I read your proposal of back-then, but it is not wholly clear to me: * You want to protect the list of subscribers you say; are these the email addresses or key identities that you wish to protect? * You say that you don't like re-encryption; is this for reasons of efficiency, or for reasons of passing the plaintext through the control of the list owner (who is likely to subscribe and therefore receive the text anyway)? Since mailing lists are sort-of a hack in the mail system, you might consider doing it entirely differently. For instance, downloading list mail over IMAP, which gives subscribers the initiative so they don't need to present an email address. Sending might be done over SMTP or even over IMAP. Being searchable, this also makes for a great document repository :) As for re-encryption efficiency, you could decide to re-package the session key to (only authorized) public keys; one way you could find those is from STARTTLS with an OpenPGP credential, but that would impose restrictions on the mail client, or require it go through a SOCKS proxy or such. Towards the latter, we are working on a TLS Pool that could make it straightforward to build such a proxy, http://tlspool.arpa2.net and which implements OpenPGP over TLS. -Rick From nobody Mon Jan 11 14:46:24 2016 Return-Path: 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 B84B91AC400 for ; Mon, 11 Jan 2016 14:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 srdiIqb-fPCK for ; Mon, 11 Jan 2016 14:46:20 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 2A89F1AC3FD for ; Mon, 11 Jan 2016 14:46:19 -0800 (PST) Received: from p5ddfb0fc.dip0.t-ipconnect.de ([93.223.176.252] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1aIlE5-0003D1-Bo; Mon, 11 Jan 2016 22:46:13 +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 ) id 1aIlE1-00007x-Ax; Mon, 11 Jan 2016 23:46:13 +0100 Received: from localhost ([::1] helo=chu.huenfield.org.walfield.org) by chu.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1aIlDx-0002mb-Q2; Mon, 11 Jan 2016 23:46:05 +0100 Date: Mon, 11 Jan 2016 23:46:05 +0100 Message-ID: <87r3hn4tw2.wl-neal@walfield.org> From: "Neal H. Walfield" To: Rick van Rein In-Reply-To: <56938B98.7000707@openfortress.nl> References: <87ziwd3yrn.wl-neal@walfield.org> <56938B98.7000707@openfortress.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) 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=BIG5 Content-Transfer-Encoding: base64 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: Cc: openpgp@ietf.org, Matthew Green Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 22:46:22 -0000 SGkgUmljaywNCg0KVGhhbmtzIGZvciB5b3VyIHRob3VnaHRmdWwgcmVzcG9uc2UhDQoNCkF0IE1v biwgMTEgSmFuIDIwMTYgMTI6MDE6NDQgKzAxMDAsDQpSaWNrIHZhbiBSZWluIHdyb3RlOg0KPiBZ b3UgYXJlIGdldHRpbmcgaW50byBhIHRvcGljIHRoYXQgaGFzIG15IGludGVyZXN0LiAgVG8gbWUs IGEgbWFpbGluZw0KPiBsaXN0IGlzIGp1c3QgYW4gZXhhbXBsZSBvZiBlbmNyeXB0aW9uIHRoaW5n cyB0byBhIGdyb3VwLg0KPiANCj4gSSByZWFkIHlvdXIgcHJvcG9zYWwgb2YgYmFjay10aGVuLCBi dXQgaXQgaXMgbm90IHdob2xseSBjbGVhciB0byBtZToNCj4gICogWW91IHdhbnQgdG8gcHJvdGVj dCB0aGUgbGlzdCBvZiBzdWJzY3JpYmVycyB5b3Ugc2F5OyBhcmUgdGhlc2UgdGhlDQo+IGVtYWls IGFkZHJlc3NlcyBvciBrZXkgaWRlbnRpdGllcyB0aGF0IHlvdSB3aXNoIHRvIHByb3RlY3Q/DQoN ClVzaW5nIFNNVFAsIGl0IGlzIGNsZWFybHkgZWZmZWN0aXZlbHkgaW1wb3NzaWJsZSB0byBwcm90 ZWN0IHRoZSBlbWFpbA0KYWRkcmVzc2VzIFsxXS4gIEJ1dCwgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biB0aGUgcmVzb3VyY2VzIHJlcXVpcmVkIHRvDQpkb3duZ3JhZGUgVExTIGNvbm5lY3Rpb25zIGFu ZCBwYXNzaXZlbHkgb2JzZXJ2ZSBTTVRQIHRyYWZmaWMgYW5kIHRoZQ0KcmVzb3VyY2VzIHRvIGNh c3VhbGx5IHRyYXZlcnNlIHNvbWUgcHVibGljYWxseSBhbmQgcGVybWFuZW50bHkgc3RvcmVkDQpk YXRhIGRlY2FkZXMgbGF0ZXIgaXMgaHVnZS4gIFRodXMsIGV2ZW4gdGhvdWdoIEkgcmVhbGl6ZSBp dCBpcyBub3QNCnBvc3NpYmxlIHRvIGNvbXBsZXRlbHkgcHJvdGVjdCB0aGUgZW1haWwgYWRkcmVz c2VzLCBJIGRvbid0IHdhbnQgdG8NCm1ha2UgaXQgdG9vIGVhc3kgdG8gZ2V0IHRoZW0uDQoNCiAg WzFdICJOZWl0aGVyIFNub3cgTm9yIFJhaW4gTm9yIE1JVE0uLi4gIEFuIEVtcGlyaWNhbCBBbmFs eXNpcyBvZg0KICBFbWFpbCBEZWxpdmVyeSBTZWN1cml0eSIgYnkgWmFraXIgRHVydW1lcmljLCBE YXZpZCBBZHJpYW4sIEFyaWFuYQ0KICBNaXJpYW4sIEphbWVzIEthc3RlbiwgRWxpZSBCdXJzenRl aW4sIE5pY29sYXMgTGlkemJvcnNraSwgS3VydA0KICBUaG9tYXMsIFZpamF5IEVyYW50aSwgTWlj aGFlbCBCYWlsZXksIGFuZCBKLiBBbGV4IEhhbGRlcm1hbi4NCiAgSU1DoaYxNSwgT2N0b2JlciAy OKFWMzAsIDIwMTUuDQoNCiAgaHR0cDovL2NvbmZlcmVuY2VzMi5zaWdjb21tLm9yZy9pbWMvMjAx NS9wYXBlcnMvcDI3LnBkZg0KDQpMaWtld2lzZSwgSSB3YW50IHRvIG1ha2UgaXQgcG9zc2libGUg dG8gcHJvdGVjdCB0aGUga2V5IGlkcyBhcyBtdWNoIGFzDQpwb3NzaWJsZSwgd2hpY2ggY2FuIGJl IGRvbmUgdXNpbmcgaGlkZGVuIHJlY2lwaWVudHMgKGkuZS4sIHVzaW5nIDB4MA0KZm9yIHRoZSBr ZXkgaWQgaW4gdGhlIFBLLUVTSyBwYWNrZXQpLg0KDQo+ICAqIFlvdSBzYXkgdGhhdCB5b3UgZG9u J3QgbGlrZSByZS1lbmNyeXB0aW9uOyBpcyB0aGlzIGZvciByZWFzb25zIG9mDQo+IGVmZmljaWVu Y3ksIG9yIGZvciByZWFzb25zIG9mIHBhc3NpbmcgdGhlIHBsYWludGV4dCB0aHJvdWdoIHRoZSBj b250cm9sDQo+IG9mIHRoZSBsaXN0IG93bmVyICh3aG8gaXMgbGlrZWx5IHRvIHN1YnNjcmliZSBh bmQgdGhlcmVmb3JlIHJlY2VpdmUgdGhlDQo+IHRleHQgYW55d2F5KT8NCg0KVGhlcmUgYXJlIHR3 byB0eXBlcyBvZiByZS1lbmNyeXB0aW9uIHRoYXQgSSB0aGluayBhcmUgaW5hcHByb3ByaWF0ZToN Cg0KICAtIHdoZW4gdGhlIG1haWxpbmcgbGlzdCBzb2Z0d2FyZSBkZWNyeXB0cyBhbmQgcmVlbmNy eXB0cyBlYWNoDQogICAgbWVzc2FnZSBiZWZvcmUgZm9yd2FyZGluZyBpdCBvbiB0byB0aGUgbGlz dCBvZiBzdWJzY3JpYmVyLCBhbmQsDQoNCiAgLSB1c2luZyBjcnlwdG9ncmFwaGljIHJlZW5jcnlw dGlvbiAoYWxhIFNFTFMgWzJdLCBpLmUuLCB0aGUgbWFpbGluZyBsaXN0DQogICAgb3duZXIgaGFz IGEgc2VjcmV0IGtleSwgZWFjaCBzdWJzY3JpYmVyIGhhcyBhIHNlY3JldCBrZXkgdGhhdCBpcw0K ICAgIGFuIG9mZnNldCBvZiB0aGF0IHNlY3JldCBrZXksIGFuZCB0aGUgbWFpbGluZyBsaXN0IHNv ZnR3YXJlDQogICAgYWRqdXN0cyBlbmNyeXB0ZWQgbWVzc2FnZXMgYnkgZWFjaCByZWNpcGllbnQn cyBvZmZzZXQgdG8NCiAgICByZS1lbmNyeXB0IGl0KS4NCg0KICBbMl0gaHR0cDovL3NlbHMubmNz YS5pbGxpbm9pcy5lZHUvDQoNClRoZSBwcm9ibGVtIHdpdGggdGhlIG1haWxpbmcgbGlzdCBzb2Z0 d2FyZSBoYXZpbmcgYWNjZXNzIHRvIHRoZQ0KY2xlYXJ0ZXh0IGlzIHRoYXQgdGhlIG1haWxpbmcg bGlzdCBzZXJ2ZXIgYmVjb21lcyBwYXJ0IG9mIHRoZSB0cnVzdGVkDQpjb21wdXRpbmcgYmFzZSAo VENCKSwgd2hpY2ggaXMgb2Z0ZW4gdW5kZXNpcmFibGUsIGJlY2F1c2Ugd2UnZCBsaWtlIHRvDQpo YXZlIHNvbWUgdW50cnVzdGVkIHBhcnR5IHByb3ZpZGUgYW5kIG1hbmFnZSBvdXIgaW5mcmFzdHJ1 Y3R1cmUuDQpOb3RlOiB0aGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIGxpc3Qgb3duZXIs IHdobywgSSBhc3N1bWUsIGlzDQpwYXJ0IG9mIHRoZSBUQ0IuDQoNClRoZSBwcm9ibGVtIHdpdGgg cmVlbmNyeXB0aW9uIGFsZ29yaXRobXMgaXMgdGhhdCBhIHN1YnNjcmliZXIgY2FuJ3QNCnJldXNl IGhlciBvd24gc2VjcmV0IGtleS4gIEluc3RlYWQsIHNoZSBnZXRzIGEgbmV3IHNlY3JldCBrZXkg KHNlbnQNCnZpYSBlbWFpbCwgd2hpY2ggc2hlIGhhcyB0byBpbXBvcnQpIGZvciBlYWNoIG1haWxp bmcgbGlzdA0Kc3Vic2NyaXB0aW9uLiAgVGhpcyBtZWFucyBzaGUgY2FuJ3QgZWFzaWx5IHVzZSBh IHNtYXJ0Y2FyZDsgaXQgbWFrZXMNCml0IGhhcmRlciB0byByZWFkIHRoZSBtYWlsIG9uIG11bHRp cGxlIGRldmljZXM7IGFuZCwgaXQgZW5jb3VyYWdlcw0Kd2hhdCBhcmUsIElNSE8sIGJhZCBzZWN1 cml0eSBwcmFjdGljZXMgKGl0IG5vcm1hbGl6ZXMgdXNpbmcgYSBzZWNyZXQNCmtleSBwcm92aWRl ZCBieSBhIHRoaXJkIHBhcnR5KS4gIEZpbmFsbHksIGl0IGlzIHBvc3NpYmxlIHRvIHJlY292ZXIN CnRoZSBtYWlsaW5nIGxpc3QncyBzZWNyZXQga2V5IGlmIHRoZSBtYWlsaW5nIGxpc3Qgc29mdHdh cmUgYW5kIGENCnN1YnNjcmliZXIgY29sbHVkZS4NCg0KPiBTaW5jZSBtYWlsaW5nIGxpc3RzIGFy ZSBzb3J0LW9mIGEgaGFjayBpbiB0aGUgbWFpbCBzeXN0ZW0sIHlvdSBtaWdodA0KPiBjb25zaWRl ciBkb2luZyBpdCBlbnRpcmVseSBkaWZmZXJlbnRseS4gIEZvciBpbnN0YW5jZSwgZG93bmxvYWRp bmcgbGlzdA0KPiBtYWlsIG92ZXIgSU1BUCwgd2hpY2ggZ2l2ZXMgc3Vic2NyaWJlcnMgdGhlIGlu aXRpYXRpdmUgc28gdGhleSBkb24ndA0KPiBuZWVkIHRvIHByZXNlbnQgYW4gZW1haWwgYWRkcmVz cy4gIFNlbmRpbmcgbWlnaHQgYmUgZG9uZSBvdmVyIFNNVFAgb3INCj4gZXZlbiBvdmVyIElNQVAu ICBCZWluZyBzZWFyY2hhYmxlLCB0aGlzIGFsc28gbWFrZXMgZm9yIGEgZ3JlYXQgZG9jdW1lbnQN Cj4gcmVwb3NpdG9yeSA6KQ0KPiANCj4gQXMgZm9yIHJlLWVuY3J5cHRpb24gZWZmaWNpZW5jeSwg eW91IGNvdWxkIGRlY2lkZSB0byByZS1wYWNrYWdlIHRoZQ0KPiBzZXNzaW9uIGtleSB0byAob25s eSBhdXRob3JpemVkKSBwdWJsaWMga2V5czsgb25lIHdheSB5b3UgY291bGQgZmluZA0KPiB0aG9z ZSBpcyBmcm9tIFNUQVJUVExTIHdpdGggYW4gT3BlblBHUCBjcmVkZW50aWFsLCBidXQgdGhhdCB3 b3VsZCBpbXBvc2UNCj4gcmVzdHJpY3Rpb25zIG9uIHRoZSBtYWlsIGNsaWVudCwgb3IgcmVxdWly ZSBpdCBnbyB0aHJvdWdoIGEgU09DS1MgcHJveHkNCj4gb3Igc3VjaC4gIFRvd2FyZHMgdGhlIGxh dHRlciwgd2UgYXJlIHdvcmtpbmcgb24gYSBUTFMgUG9vbCB0aGF0IGNvdWxkDQo+IG1ha2UgaXQg c3RyYWlnaHRmb3J3YXJkIHRvIGJ1aWxkIHN1Y2ggYSBwcm94eSwgaHR0cDovL3Rsc3Bvb2wuYXJw YTIubmV0DQo+IGFuZCB3aGljaCBpbXBsZW1lbnRzIE9wZW5QR1Agb3ZlciBUTFMuDQoNCihJJ20g bm90IGNsZWFyIG9uIHdoYXQgeW91IG1lYW4gYnkgcmVwYWNrYWdpbmcgdGhlIHNlc3Npb24ga2V5 LiAgRG8NCnlvdSBoYXZlIHNvbWUgcG9pbnRlcnM/KQ0KDQpUaGVzZSBhcmUgZ29vZCBzdWdnZXN0 aW9ucyBhbmQgSSBhcHByZWNpYXRlIHRoZSB0aXBzISAgWW91J3JlIHByb2JhYmx5DQpyaWdodCB0 aGF0IGEgZ29vZCBzb2x1dGlvbiBjYW4gbW9yZSBlYXNpbHkgYmUgZm91bmQgYnkgZGlzcmVnYXJk aW5nDQpiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4gIEJ1dCwgaW4gdGhpcyBwcm9qZWN0LCBJJ20g dHJ5aW5nIHRvDQpkZXRlcm1pbmUgdGhlIGJlc3QgbWVjaGFuaXNtIHRoYXQgZG9lc24ndCByZXF1 aXJlIHVzZXJzIHRvIGNoYW5nZQ0KdGhlaXIgaGFiaXRzIG9yIHVwZ3JhZGUgdGhlaXIgc29mdHdh cmUgKG90aGVyIHRoYW4gdGhlaXIgT3BlblBHUA0KaW1wbGVtZW50YXRpb24gYW5kIHRoZW4sIG9u bHkgZm9yIHBvc3RlcnMsIG5vdCBsaXN0IHN1YnNjcmliZXJzKS4NCg0KDQpJIGhvcGUgbXkgcmVz cG9uc2UgZG9lc24ndCBzb3VuZCB0b28gZGVzdHJ1Y3RpdmU7IGl0IHdhcyBub3QgdGhlDQppbnRl bnQuICBJIHJlYWxseSBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMgYW5kIHRoZSBvcHBvcnR1bml0 eSB0bw0KZm9ybXVsYXRlIHNvbWUgcHJldmlvdXNseSBpbXBsaWNpdCBhcmd1bWVudHMuDQoNClRo YW5rcyENCg0KOikgTmVhbA0KDQo= From nobody Mon Jan 11 15:24:15 2016 Return-Path: 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 393461AC427 for ; Mon, 11 Jan 2016 15:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 SHEROpOJhZoF for ; Mon, 11 Jan 2016 15:24:12 -0800 (PST) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C001AC42F for ; Mon, 11 Jan 2016 15:24:12 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id 4nQ81s00d10HQrX01nQ9Zx; Tue, 12 Jan 2016 00:24:09 +0100 Message-ID: <56943997.1000001@openfortress.nl> Date: Tue, 12 Jan 2016 00:24:07 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Neal H. Walfield" References: <87ziwd3yrn.wl-neal@walfield.org> <56938B98.7000707@openfortress.nl> <87r3hn4tw2.wl-neal@walfield.org> In-Reply-To: <87r3hn4tw2.wl-neal@walfield.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: openpgp@ietf.org, Matthew Green Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 23:24:15 -0000 Hello Neal, > Thus, even though I realize it is not > possible to completely protect the email addresses, I don't want to > make it too easy to get them. OK, so your target is to protect from passive observers. That is clear enough. > Likewise, I want to make it possible to protect the key ids as much as > possible, which can be done using hidden recipients (i.e., using 0x0 > for the key id in the PK-ESK packet). I think that makes a lot of sense, the key ID being very similar to the email address. On a side-note though :- it is trivial to use your existing key and construct another ID for it; you can use the same key material and make a self-signature with another timestamp. The result is a different fingerprint and so another key ID. That might be helpful with your obfuscation plans (blinding all but the last two bytes of the key ID). Note that it should also possible to take the subkey and hang it under another public signing key. You said you lack experience in RFC authoring; if you want to take that route you probably don't want to overload a given key ID field with other meaning but instead want to define a new one which simply has two bytes only or which has a variable size, perhaps prefixed with up to 8 bits "0" and 1 bit "1" to mark the start of a variable-sized ending of the key ID. > There are two types of re-encryption that I think are inappropriate: > > - when the mailing list software decrypts and reencrypts each > message before forwarding it on to the list of subscriber, and, You specified below that this is because you consider the system running your mailing list to be part of the passive observation infrastructure. > - using cryptographic reencryption (ala SELS [2], i.e., the mailing list > owner has a secret key, each subscriber has a secret key that is > an offset of that secret key, and the mailing list software > adjusts encrypted messages by each recipient's offset to > re-encrypt it). This approach can work really nicely if the crypto is designed well. It is possible to combine (EC)DH keys in very clever ways to achieve such effects. Unfortunately, OpenPGP is not interactive enough (it is a message format spec, after all) to make use of DH for encryption. > The problem with the mailing list software having access to the > cleartext is that the mailing list server becomes part of the trusted > computing base (TCB), which is often undesirable, because we'd like to > have some untrusted party provide and manage our infrastructure. > Note: this has nothing to do with the list owner, who, I assume, is > part of the TCB. OK, you are mistrusting the hosting provider. This will be virtually impossible to do really well, but if it is possible then crypto is the answer. A non-technical answer to that is "pay them enough so they will want to behave". Another might be to spread the power over a number of partial providers. And this quickly brings you to a distributed scheme, such as a p2p network. Emails are identified by a Message-ID, for which mid: URIs have been specified; similarly, attachments can have a cid: URI defined on them. No OS resolves those URIs yet, AFAIK, but the long codes they hold might do nicely as a p2p lookup key (perhaps after hashing). This defends from directed attacks, but still not from casual glancing over your email, which still requires the cryptographic path. > The problem with reencryption algorithms is that a subscriber can't > reuse her own secret key. Instead, she gets a new secret key (sent > via email, which she has to import) for each mailing list > subscription. If you know your crypto algorithms well enough, you might be able to cook up something different... RSA, DH, ECDH are all more potent than their everyday applications make you believe. > (I'm not clear on what you mean by repackaging the session key. Do > you have some pointers?) It's security-wise equivalent to decrypting and encrypting the email, but more efficient; you use the receiving-end public key to retrieve the session key from packet type 1, and then produce another packet type 1 holding the session key encrypted to subscribers' public keys. Plaintext doesn't pass through the list host, but the power to decrypt (namely the session key) does. > These are good suggestions and I appreciate the tips! You're probably > right that a good solution can more easily be found by disregarding > backwards compatibility. But, in this project, I'm trying to > determine the best mechanism that doesn't require users to change > their habits or upgrade their software (other than their OpenPGP > implementation and then, only for posters, not list subscribers). I think you are targeting an audience that, if it is to wisely use the list and not leak to "interested extra subscribers" by letting them in on the list (had you thought of the signup procedure yet? key management is always the culprit) will be quite able to change habits. Good luck with it! -Rick From nobody Mon Jan 11 23:22:03 2016 Return-Path: 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 6F27F1A00E4 for ; Mon, 11 Jan 2016 23:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham 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 RD4_ESylr3sT for ; Mon, 11 Jan 2016 23:22:00 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021CE1A01D8 for ; Mon, 11 Jan 2016 23:21:58 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aItHA-0002S1-K7 for ; Tue, 12 Jan 2016 08:21:56 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aItF8-0006aC-H0; Tue, 12 Jan 2016 08:19:50 +0100 From: Werner Koch To: "Neal H. Walfield" References: <87ziwd3yrn.wl-neal@walfield.org> <56938B98.7000707@openfortress.nl> <87r3hn4tw2.wl-neal@walfield.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: "Neal H. Walfield" , Rick van Rein , openpgp@ietf.org, Matthew Green Date: Tue, 12 Jan 2016 08:19:50 +0100 In-Reply-To: <87r3hn4tw2.wl-neal@walfield.org> (Neal H. Walfield's message of "Mon, 11 Jan 2016 23:46:05 +0100") Message-ID: <87twmje02x.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Rick van Rein , Matthew Green , openpgp@ietf.org Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 07:22:02 -0000 On Mon, 11 Jan 2016 23:46, neal@walfield.org said: > There are two types of re-encryption that I think are inappropriate: > > - when the mailing list software decrypts and reencrypts each > message before forwarding it on to the list of subscriber, and, As soon as you are in the need for a mailing list you have severe opsec problems which I consider not solvable: You not only need to fully trust all participants but also need to make sure that _all_ their boxes are properly secured against attacks. Adding another box to reencrypt the messages does not change the picture much more than adding another subscriber. I heard that Schleuder (schleuder.nadir.org or apt-get install schleuder) is a matured tool for encrypted group communication. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Jan 13 07:30:26 2016 Return-Path: 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 7CF8D1A90C6 for ; Wed, 13 Jan 2016 07:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 2qp6d4XDD0pV for ; Wed, 13 Jan 2016 07:30:23 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 53BEF1A902D for ; Wed, 13 Jan 2016 07:30:23 -0800 (PST) Received: from p5ddf94f7.dip0.t-ipconnect.de ([93.223.148.247] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1aJNNJ-0007vm-7P; Wed, 13 Jan 2016 15:30:17 +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 ) id 1aJNNF-0002p3-Kn; Wed, 13 Jan 2016 16:30:17 +0100 Received: from localhost ([::1] helo=chu.huenfield.org.walfield.org) by chu.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1aJNNC-0005Im-4h; Wed, 13 Jan 2016 16:30:10 +0100 Date: Wed, 13 Jan 2016 16:30:10 +0100 Message-ID: <87pox54hvh.wl-neal@walfield.org> From: "Neal H. Walfield" To: Rick van Rein In-Reply-To: <56943997.1000001@openfortress.nl> References: <87ziwd3yrn.wl-neal@walfield.org> <56938B98.7000707@openfortress.nl> <87r3hn4tw2.wl-neal@walfield.org> <56943997.1000001@openfortress.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) 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: Cc: openpgp@ietf.org, Matthew Green Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:30:25 -0000 At Tue, 12 Jan 2016 00:24:07 +0100, Rick van Rein wrote: > > Thus, even though I realize it is not > > possible to completely protect the email addresses, I don't want to > > make it too easy to get them. > OK, so your target is to protect from passive observers. That is clear > enough. I want to protect the subscriber list from passive observers, but the message contents from active attackers (i.e., the same assurances that OpenPGP can provide). > > Likewise, I want to make it possible to protect the key ids as much as > > possible, which can be done using hidden recipients (i.e., using 0x0 > > for the key id in the PK-ESK packet). > I think that makes a lot of sense, the key ID being very similar to the > email address. > > On a side-note though :- it is trivial to use your existing key and > construct another ID for it; you can use the same key material and make > a self-signature with another timestamp. The result is a different > fingerprint and so another key ID. That might be helpful with your > obfuscation plans (blinding all but the last two bytes of the key > ID). I'm not sure how this helps. AIUI, the key id is used in the PK-ESK packet so that the OpenPGP implementation doesn't need to try to decrypt all PK-ESK packets with all available secret keys. This is not only potentially slow, but also annoying if the user has multiple passphrase-protected secret keys or secret keys on smartcards. In other words, including the key id in the PK-ESK packet improves usability for the *message recipient*. If the message recipient wants to hide the key id, then the message recipient can use your trick locally; there is no need to add this to a standard or the mailing list software implementation. > Note that it should also possible to take the subkey and hang it under > another public signing key. That was one of my concrete proposals for saving the subscribers in my mail from a few days ago: http://mailarchive.ietf.org/arch/msg/openpgp/UuWVSrMu8LEdChEBQgEpBtQR3-Y > You said you lack experience in RFC authoring; if you want to take that > route you probably don't want to overload a given key ID field with > other meaning but instead want to define a new one which simply has two > bytes only or which has a variable size, perhaps prefixed with up to 8 > bits "0" and 1 bit "1" to mark the start of a variable-sized ending of > the key ID. Again, a driving concern is backwards compatibility and, if I understand your suggestion correctly, you are suggesting a non-backwards compatible change. Perhaps this extension is useful to consider for 4880bis. > > There are two types of re-encryption that I think are inappropriate: > > > > - when the mailing list software decrypts and reencrypts each > > message before forwarding it on to the list of subscriber, and, > > You specified below that this is because you consider the system running > your mailing list to be part of the passive observation infrastructure. If I did, then I misstated my position. I consider the system running the mailing list software to be a potentially active adversary. > > The problem with the mailing list software having access to the > > cleartext is that the mailing list server becomes part of the trusted > > computing base (TCB), which is often undesirable, because we'd like to > > have some untrusted party provide and manage our infrastructure. > > Note: this has nothing to do with the list owner, who, I assume, is > > part of the TCB. > > OK, you are mistrusting the hosting provider. This will be virtually > impossible to do really well, but if it is possible then crypto is the > answer. A non-technical answer to that is "pay them enough so they will > want to behave". Another might be to spread the power over a number of > partial providers. And this quickly brings you to a distributed scheme, > such as a p2p network. For the purposes of this exercise, I want to trust the mail server as much as a normal OpenPGP user trusts an SMTP server. Namely, an OpenPGP user reveals the list of recipients to the SMTP server and relies on the server to forward the encrypted message. I realize that there are other approaches that reveal less meta-data, but insofar as they exist today, they are not widely adopted. I don't want to say that those fights are not worth fighting, but I am looking for a short-term solution that provides similar security guarantees that OpenPGP provides for normal encrypted email. > > The problem with reencryption algorithms is that a subscriber can't > > reuse her own secret key. Instead, she gets a new secret key (sent > > via email, which she has to import) for each mailing list > > subscription. > > If you know your crypto algorithms well enough, you might be able to > cook up something different... RSA, DH, ECDH are all more potent than > their everyday applications make you believe. Unfortunately, I'm not that good of a cryptographer. But if you have some concrete suggestions of things to look at or keywords to search for, I'd appreciate it. > > These are good suggestions and I appreciate the tips! You're probably > > right that a good solution can more easily be found by disregarding > > backwards compatibility. But, in this project, I'm trying to > > determine the best mechanism that doesn't require users to change > > their habits or upgrade their software (other than their OpenPGP > > implementation and then, only for posters, not list subscribers). > I think you are targeting an audience that, if it is to wisely use the > list and not leak to "interested extra subscribers" by letting them in > on the list (had you thought of the signup procedure yet? key management > is always the culprit) will be quite able to change habits. I'm trying to target all OpenPGP users. I'm not just interested in helping those who the subject of a targeted attack, but also those who are unsophisticated, but are interested in inhibiting mass surveillance. Thanks, :) Neal From nobody Wed Jan 13 07:50:40 2016 Return-Path: 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 22E2F1A8A94 for ; Wed, 13 Jan 2016 07:50:40 -0800 (PST) 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 LErQ0iFNWqRG for ; Wed, 13 Jan 2016 07:50:39 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF591A8A8B for ; Wed, 13 Jan 2016 07:50:39 -0800 (PST) Received: from p5ddf94f7.dip0.t-ipconnect.de ([93.223.148.247] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1aJNgv-00084c-3L; Wed, 13 Jan 2016 15:50:33 +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 ) id 1aJNgs-0002qq-5b; Wed, 13 Jan 2016 16:50:32 +0100 Received: from localhost ([::1] helo=chu.huenfield.org.walfield.org) by chu.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1aJNgo-0005Mx-Im; Wed, 13 Jan 2016 16:50:26 +0100 Date: Wed, 13 Jan 2016 16:50:26 +0100 Message-ID: <87oacp4gxp.wl-neal@walfield.org> From: "Neal H. Walfield" To: "Neal H. Walfield" , Rick van Rein , openpgp@ietf.org, Matthew Green In-Reply-To: <87twmje02x.fsf@vigenere.g10code.de> References: <87ziwd3yrn.wl-neal@walfield.org> <56938B98.7000707@openfortress.nl> <87r3hn4tw2.wl-neal@walfield.org> <87twmje02x.fsf@vigenere.g10code.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) 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: Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:50:40 -0000 Hi Werner, At Tue, 12 Jan 2016 08:19:50 +0100, Werner Koch wrote: > On Mon, 11 Jan 2016 23:46, neal@walfield.org said: > > There are two types of re-encryption that I think are inappropriate: > > > > - when the mailing list software decrypts and reencrypts each > > message before forwarding it on to the list of subscriber, and, > > As soon as you are in the need for a mailing list you have severe opsec > problems which I consider not solvable: You not only need to fully trust > all participants but also need to make sure that _all_ their boxes are > properly secured against attacks. As we discussed recently offline, I respectfully disagree and I find this position difficult to resolve with your stated position of trying to bring GnuPG and encrypt in general to a wider audience. This is also why I'm working on this project in my free time and not on the clock. Even if people aren't sufficiently careful, ready-to-use encrypted mailing listings can hinder mass surveillance (similar to the way OpenPGP can, I think). Further, for those who do have the opsec background and need this protection, a solution that is easier to use than GnuPG groups + manually updating the subscriber list, is probably safer. > Adding another box to reencrypt the messages does not change the picture > much more than adding another subscriber. I disagree with this as well. Someone who hosts many mailing lists (e.g., google or sf) could abuse their position in a much more substantive way than a single user. Thanks, :) Neal From nobody Wed Jan 13 15:01:16 2016 Return-Path: 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 66C161A8833 for ; Wed, 13 Jan 2016 15:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham 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 crsPt-1im4TF for ; Wed, 13 Jan 2016 15:01:13 -0800 (PST) Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.200]) (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 56E081A8831 for ; Wed, 13 Jan 2016 15:01:13 -0800 (PST) Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 9EF49E0259 for ; Wed, 13 Jan 2016 23:01:12 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=6XgkaSE+VKQzfQGnlSejhcr4Q+hjY5HTssHT8EGBD+U=; b=w9rExdlDjXNv3NKxoH+A+HKZWzcsSa0dxAkFDJVVejLMId40zCqnmkxc8IGC2Kb+Vdro9C/Bm3wiacbaNExUZWwmCIObxytRqZS6sbJEbXT0taJYjbZtQCW5f0vDKePGbN1oIbBjk3AU8mzx3AdhR5v2jtiZ3eU/i/wUDAvri1qHOC7RrEXiOwhCn3xnOMVD8FmGG8SDnMLxzaLh3Ck2k+B4YH0wm+3eLmzRqvHCXaS7cF5ZucHO1hYMBiQN7nRBnP/f8UePhGAoGV7KbqsLn8dTQxLsE3cm7RkwViShCos86iFDq4GfUCLrk0DSJGQGnRJ4j2G4avhDEpsjrbGtQg== Received: from smtp.hushmail.com (w1.hushmail.com [65.39.178.83]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.hushmail.com (Postfix) with ESMTPS; Wed, 13 Jan 2016 23:01:12 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 4F73920106; Wed, 13 Jan 2016 23:01:12 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 13 Jan 2016 18:01:12 -0500 To: "Neal H. Walfield" , "Rick van Rein" From: vedaal@nym.hush.com In-Reply-To: <87pox54hvh.wl-neal@walfield.org> References: <87ziwd3yrn.wl-neal@walfield.org> <56938B98.7000707@openfortress.nl> <87r3hn4tw2.wl-neal@walfield.org> <56943997.1000001@openfortress.nl> <87pox54hvh.wl-neal@walfield.org> Content-Type: multipart/alternative; boundary="=_f59a8a78ca9cb5ee3f53458f5000c456" Message-Id: <20160113230112.4F73920106@smtp.hushmail.com> Archived-At: Cc: openpgp@ietf.org, Matthew Green Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 23:01:15 -0000 --=_f59a8a78ca9cb5ee3f53458f5000c456 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" On 1/13/2016 at 10:30 AM, "Neal H. Walfield" wrote:... I want to protect the subscriber list from passive observers, but the message contents from active attackers (i.e., the same assurances that OpenPGP can provide). ... Again, a driving concern is backwards compatibility and, if I understand your suggestion correctly, you are suggesting a non-backwards compatible change. Perhaps this extension is useful to consider for 4880bis. ... If I did, then I misstated my position. I consider the system running the mailing list software to be a potentially active adversary. ... For the purposes of this exercise, I want to trust the mail server as much as a normal OpenPGP user trusts an SMTP server. Namely, an OpenPGP user reveals the list of recipients to the SMTP server and relies on the server to forward the encrypted message. I realize that there are other approaches that reveal less meta-data, but insofar as they exist today, they are not widely adopted. I don't want to say that those fights are not worth fighting, but I am looking for a short-term solution that provides similar security guarantees that OpenPGP provides for normal encrypted email. > > The problem with reencryption algorithms is that a subscriber can't > > reuse her own secret key. Instead, she gets a new secret key (sent > > via email, which she has to import) for each mailing list > > subscription. ===== What you want to accomplish, can be done, (at the expense of backward compatibility), by allowing split-shared keys: [1] You, (or the owner of any list using this), has one signing/certifiying master key with 'n' encryption subkeys, with the ID name of the mailing list. [2] For Encryption, the message is simultaneously encrypted to each of the n encryption subkeys. [3] For Decryption, only one share of any subkey, is needed. [4] Each subscriber of the list is sent one share of one subkey, encrypted to the subscriber's own keypair. [5] If, for whatever reason, you distrust a particular subscriber of 'leaking' a share, you can revoke that subkey, and send a signed notice to all subscribers, and generate a new subkey, signed by your master key. [6] No meta-data of the recipient, is leaked in any of the encrypted messages. [7] For further secrecy, (a) each recipient generates a 'throw-away' web-based e-mail. (b) then generates a keypair with a with a bogus ID, and sends that public key to the list for a share to be sent encrypted to this 'throw-away' e-mail address. (c) the recipient then discards the throw-away e-mail address, and generates a new one (d) then asks to be subscribed to the new one, stating that he/she already has a shared portion of the decryption key to this it, and that no share needs to be sent, just the messages encrypted to the n subkeys. (e) If all the recipients are instructed to wait after they have received their 'share', and send their subscription requests to their new e-mail addresses, all at some pre-arranged time, (e.g. a day later), then their identity of the individual e-mail, is difficult to trace to the specific subscriber. [8] The determination of the 'n' of the 'n' subkeys, is a cryptographic issue to which I don't know the answer. I imagine that there is some minimum size of a 'share' below which it is feasible to brute force the share, but since there is no limit to the subkeys one can generate, it seems do-able to decide on a share of 'safe' size and proceed, (although the encrypted message can get *really* bulky and long, if there are many many subscribers.) [9] It can be made 'backward' compatible, for new subscribers, if 'n' is large enough to simply just send a pre-existing share as subscribers are added. just a possible suggestion ... vedaal --=_f59a8a78ca9cb5ee3f53458f5000c456 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

On 1/13/2016 a= t 10:30 AM, "Neal H. Walfield" <neal@walfield.org> wrote:
..= .

I want to protect the subscriber list from passive observers, but = the
message contents from active attackers (i.e., the same assurances th= at
OpenPGP can provide).

...

Again, a driving concern is b= ackwards compatibility and, if I
understand your suggestion correctly, y= ou are suggesting a
non-backwards compatible change. Perhaps this exten= sion is useful to
consider for 4880bis.
...

If I did, then I m= isstated my position. I consider the system running
the mailing list so= ftware to be a potentially active adversary.
...

For the purposes= of this exercise, I want to trust the mail server as
much as a normal O= penPGP user trusts an SMTP server. Namely, an
OpenPGP user reveals the = list of recipients to the SMTP server and
relies on the server to forwar= d the encrypted message.

I realize that there are other approaches t= hat reveal less meta-data,
but insofar as they exist today, they are not= widely adopted. I don't
want to say that those fights are not worth fi= ghting, but I am looking
for a short-term solution that provides similar= security guarantees
that OpenPGP provides for normal encrypted email.
> > The problem with reencryption algorithms is that a subscrib= er can't
> > reuse her own secret key. Instead, she gets a new se= cret key (sent
> > via email, which she has to import) for each ma= iling list
> > subscription.

=3D=3D=3D=3D=3D

What yo= u want to accomplish, can be done, (at the expense of backward compatibilit= y), by allowing split-shared keys:

[1] You, (or the owner of any lis= t using this),  has one signing/certifiying master key with 'n' encryp= tion subkeys, with the ID name of the mailing list.

[2] For Encrypti= on, the message is simultaneously encrypted to each of the n encryption sub= keys.

[3] For Decryption, only one share of any subkey, is needed.
[4] Each subscriber of the list is sent one share of one subkey, encr= ypted to the subscriber's own keypair.

[5] If, for whatever reason, = you distrust a particular subscriber of 'leaking' a share, you can revoke t= hat subkey, and send a signed notice to all subscribers, and generate a new= subkey, signed by your master key.

[6] No meta-data of the recipien= t, is leaked in any of the encrypted messages.


[7] For further s= ecrecy,

(a) each recipient generates a 'throw-away' web-based e-mai= l.

(b) then generates a keypair with a with a bogus ID, and sends th= at public key to the list for a share to be sent encrypted to this 'throw-a= way' e-mail address.

(c) the recipient then discards the throw-away = e-mail address, and generates a new one

(d) then asks to be subscrib= ed to the new one, stating that he/she already has a shared portion of the = decryption key
 to this it, and that no share needs to be sent, jus= t the messages encrypted to the n subkeys.

(e) If all the recipients= are instructed to wait after they have received their 'share', and send th= eir subscription requests to their new e-mail addresses, all at some pre-ar= ranged time, (e.g. a day later), then their identity of the individual e-ma= il, is difficult to trace to the specific subscriber.

[8] The determ= ination of the 'n' of the 'n' subkeys, is a cryptographic issue to which I = don't know the answer.

I imagine that there is some minimum size of = a 'share' below which it is feasible to brute force the share, but since th= ere is no limit to the subkeys one can generate, it seems do-able to decide= on a share of 'safe' size and proceed, (although the encrypted message can= get *really* bulky and long, if there are many many subscribers.)

[= 9] It can be made 'backward' compatible, for new subscribers, if 'n' is lar= ge enough to simply just send a pre-existing  share as subscribers are= added.


just a possible suggestion ...


vedaal
&nbs= p;


 --=_f59a8a78ca9cb5ee3f53458f5000c456-- From kellerfuchs@hashbang.sh Sun Jan 24 11:38:50 2016 Return-Path: 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 739E91ACEA9 for ; Sun, 24 Jan 2016 11:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-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 cNbLegAmQpTW for ; Sun, 24 Jan 2016 11:38:49 -0800 (PST) Received: from mail.hashbang.sh (mail.hashbang.sh [104.236.230.244]) (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 022251ACEA6 for ; Sun, 24 Jan 2016 11:38:48 -0800 (PST) Received: from to1.hashbang.sh (to1.hashbang.sh [104.245.37.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hashbang.sh (Postfix) with ESMTPS id B449337C39 for ; Sun, 24 Jan 2016 19:38:47 +0000 (UTC) Received: by to1.hashbang.sh (Postfix, from userid 3412) id 0D9F5E13B3; Sun, 24 Jan 2016 19:39:02 +0000 (UTC) Date: Sun, 24 Jan 2016 19:39:01 +0000 From: kellerfuchs To: openpgp@ietf.org Message-ID: <20160124193901.GA28994@hashbang.sh> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [openpgp] Supporting services beyond email as uid X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 19:50:35 -0000 Hello, I couldn't help but notice a usecase that is gaining interest fast, yet seems to have been conspicuously absent from the WG's discussions: tying not an email address, but another kind of account (typically, so-called “social media”) to the OpenPGP key. I believe this is relevant for two main reasons: - enabling authenticated/encrypted communication over those services; this is the most immediate use, but perhaps not the most relevant; - enabling people to establish secure communication channels with other users of such service; in that case, the identity they want to link to a key is not a (name, email) pair but a (username, service) pair. A popular implementation of this is keybase.io, which make users publish a signed, parseable claim of ownership of the account in some location where only the account holder (and the service provider) can publish. Unfortunately, keybase.io does so by acting as a central database[0] where users can publish URLs to the proofs of ownership. However, I believe it should be possible to support that usecase without relying on a third-party database, by extending the notion of uid beyond mail addresses. I would feel natural to use URIs there (or a subset thereof), as they work for designating a variety of things a user might wish to associate with their identity. This makes verifying the ownership of an uid harder: in the case of email, it is done safely (by tools such as `caff`) by sending the signature as an encrypted email. In our case, the 'acct' scheme is only an abstract identifier, and does not specify how to interact with the service. It would be possible to specify the use of a given protocol, such as Web Finger [RFC 7033], to obtain the proof of ownership for the account. On the other hand, that solution would require active cooperation from the service, whereas the current, adhoc solution does not. Moreover, certain services have strong size limitations, which would not allow publishing complete signed proofs of ownership (assuming we do not require the service to implement Web Finger or somesuch). That can be handled by storing only a hash of the proof on the service, and either storing the proof as a key packet or storing a URL where the proof can be fetched. In both cases, I do not believe it can be done for the current OpenPGP spec. I hope this mail was readable, I'm afraid it has quite a bit of content. Please take it as a request to discuss whether broadening the notion of uids would be relevant, what would be the “right” thing to use as a uid and how to actually check the validity of an uid. Best regards, Keller Fuchs [0]: I am aware that keybase now publishes their database in the Bitcoin blockchain. keybase still acts as the single publisher for it, so this doesn't address the issues raised here.