From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A5BD5138334 for ; Tue, 19 Feb 2019 19:47:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 31302E085B; Tue, 19 Feb 2019 19:47:57 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DB2F5E085A for ; Tue, 19 Feb 2019 19:47:56 +0000 (UTC) Received: from grubbs.orbis-terrarum.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 73AD9335CCD for ; Tue, 19 Feb 2019 19:47:54 +0000 (UTC) Received: (qmail 32281 invoked by uid 10000); 19 Feb 2019 19:47:50 -0000 Date: Tue, 19 Feb 2019 19:47:50 +0000 From: "Robin H. Johnson" To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys Message-ID: References: <1550306421.831.16.camel@gentoo.org> <1550393754.1257.5.camel@gentoo.org> <20190217185416.nbgwm266moyk6j2u@gentoo.org> <1550496176.727.9.camel@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ki/lD0wD+h/eQRK/" Content-Disposition: inline In-Reply-To: <1550496176.727.9.camel@gentoo.org> User-Agent: Mutt/1.11.1 (2018-12-01) X-Archives-Salt: 4213dff0-b1e7-4eee-bfde-96d04e5dc09a X-Archives-Hash: c2da2e83dff7ef48be645de6cdbd9877 --ki/lD0wD+h/eQRK/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 18, 2019 at 02:22:56PM +0100, Micha=C5=82 G=C3=B3rny wrote: > > It could also be a bad actor, though that comes with other concerns. > > The CAFF method is the standard way of handling signatures, switching to > > ldap also switches our trust store to be based on ldap, not developer > > keys (anything can be in ldap). > >=20 >=20 > As Kristian named it, could you please explain to me what specific > threat model does this address? >=20 > AFAIU the main purpose of the caff model is to verify that the person > whose key you are signing can access the particular e-mail address.=20 > Which certainly makes sense when you are signing an arbitrary key.=20 > However, I don't really see how that's relevant here, and I'd rather > not add needless complexity based on cargo cult imitation of caff. >=20 > In our case, the key fingerprint comes from LDAP, and is directly bound > to the particular username, therefore mailbox. I don't really see it > a likely case that someone would be able to edit developer's LDAP > attributes but at the same time be unable to access his mailbox. >=20 > In other words, as I see it, the caff model can help if: Thanks for expounding on the list of issues. I think this covers all/most of the cases I had in my head. > 1) someone manages to compromise LDAP without compromising e-mail > service, - Compromising email has a couple of routes:=20 1. Getting into dev.gentoo.org (SSH creds).=20 Either lets you see mail directly there, or edit the forward.=20 OR 2. If a dev has their mail forwarded, you can also compromise somewhere else in the forwarding chain. - Compromising LDAP requires: 1. A shell in a larger set of machines (need SSH creds to any user on hos= ts that are LDAP clients) AND=20 2. A LDAP password with suitable power (note that the SSH creds and LDAP password could be from different compromised users), which means either the target, or the LDAP password of somebody in comrel/recruiters/infra. > 2) a developer accidentally puts the wrong fingerprint in LDAP, This has happened before; esp w/ devs putting subkeys into LDAP. If not in-band with this proposal (e.g. CAFF), can we see some other validation for the keys? > 3) a developer has broken e-mail setup, >=20 > 4) a developer is inactive. >=20 > I think cases 1)-3) are rather unlikely, and 2)-3) belong to > the 'wrong place to solve the problem' category. 4) practically relies > on making an assumption that we don't want users to trust developers who > aren't active enough to add this signature. 3) would be good to detect on the less-active devs, and gives good life-signs to undertakers. > The other side of this is added complexity on the scripting side, for > a start. We need to store to whom we sent signatures to avoid resending > them over and over again. Then, we need to able to force resending if > the developer lost the mail for some reason. Save the signature to a file, email the file, retain the file for record-keeping, resend the file until they do something about it. I think the CAFF codebase does already support this variant to not regenerate pending signatures. > Finally, there will be at least a few developers who won't be covered by > this because they won't care enough to add the signature to their key. >=20 > My original goal was to cover all active developers because users might > have their reasons to contact any of the developers, and I don't see any > reason to exclude anyone from this. It's not equivalent to giving > people access to any system, privileges to perform any specific action. Users sending mail to an unverified key seems like a concern to me. > It's mostly about confirming which OpenPGP key should be used to send > mail to a particular e-mail address. The same as if you went to > the developer listing and checked key IDs there, except more automated > and using a single authority key rather than PKI for verification > (though at least initially the authority key would itself be verified > against PKI). Related codepath not discussed yet: - detect keys REMOVED from ldap and generate revoke of signature on those. --=20 Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robbat2@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 --ki/lD0wD+h/eQRK/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it. iQKTBAABCgB9FiEEveu2pS8Vb98xaNkRGTlfI8WIJsQFAlxsXWRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJE RUJCNkE1MkYxNTZGREYzMTY4RDkxMTE5Mzk1RjIzQzU4ODI2QzQACgkQGTlfI8WI JsSfmhAAqpEknqIWGL0Cc6LJrYHGxdxaixCSix0ze0Du2JP5AOyKm3GEKR9eKZF+ XlNY2/zPy7qk77islFUNnAnHNKcm0KVLCusZH8RauvqAe5pMbcYjQsxjY3DVCx+7 CKHcSJD7es10YoXkNJrLwyhP3TDpElxjvbmV8t4ExvQznz7Qk2jsejbde16HgwpM CmaU0dxyF2Hjk2GEeqxB4XQhpm6Mmh+KDzAThCwa1jokClR9juZv7d8g9dzQx4ic BZ2mjBALtWdGcz98+4+mWbEnEVdTLI+0t3x91rOMhAJe5ym299e1iZiHyYV4hG1z c5Mpj0lrdT4WMA0HQteefB3zC2gKkJgt4DuiOkl+ekwhhnj06KjnlwfrCA6kCBJR GKnwd0PkoydpQCDoqkBp8IQ1gHC1NeLSkUkxPJAiDm+GcWbA3/946igpm+auk4Ae jJlzwFShpSRJUrGI5RsDmnol2zW4mlb0xGCvEu9mWpJ22DxCapkeGUg9nmrpZZDe QoVauho3uJ1C1862JgxNySrgBtvcpa107bjTu3a+8ts141D6qw63zuBzhQnoFivJ h9i8UvieHzUkMcewLl1ciq69v5Snk8QdcKADLWU5+m1YwCjvnqtwIVUdgPOGePgk 6X8Rpwdso+Hfjx0FwnrY7Iunl9gG3zg2rFnw8c32AeY2GpBL3No= =d5wh -----END PGP SIGNATURE----- --ki/lD0wD+h/eQRK/--