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 645B2138334 for ; Sun, 10 Mar 2019 18:17:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0D941E0977; Sun, 10 Mar 2019 18:17:02 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 B6CE8E0970 for ; Sun, 10 Mar 2019 18:17:01 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id B9CD2335D03; Sun, 10 Mar 2019 18:16:59 +0000 (UTC) Message-ID: <9205fa5a998ed6689db4f0893b84be44ff8bb83e.camel@gentoo.org> Subject: Re: [gentoo-project] [pre-GLEP RFC] New GLEP: Gentoo OpenPGP Authority Keys From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project@lists.gentoo.org Date: Sun, 10 Mar 2019 19:16:55 +0100 In-Reply-To: <9082869f-c172-35d9-0b46-5c2f963ed8f7@gentoo.org> References: <20190224141356.7707-1-mgorny@gentoo.org> <9082869f-c172-35d9-0b46-5c2f963ed8f7@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-TJ72Xc5X3cJaDeSQkY8s" User-Agent: Evolution 3.30.5 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 X-Archives-Salt: 0bd44e9b-b917-4cb5-b82e-3fc2a9d25235 X-Archives-Hash: 063728c77d725ff4c51bdd83dfbe1d86 --=-TJ72Xc5X3cJaDeSQkY8s Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2019-03-10 at 17:53 +0100, Thomas Deutschmann wrote: > Hi, >=20 > I know I am late but... >=20 > 1) I still don't understand the motivation for this. What will > change/improve/be possible in future vs. status quo? The motivation is that it will let people easily verify keys used by Gentoo developers (mentioning 'people actually committing to the Gentoo systems'). The status quo is that users need to jump through hoops to verify key used by a developer, e.g. by either meeting him or finding his fingerprint via api.g.o. > 2) This sounds like a blackbox only a few people know/understand: >=20 > > +The single L1 Authority Key is used only to (manually) certify the L2 > > +Keys, and is kept securely offline following the Infrastructure polici= es > > +on protecting primary keys. >=20 > However, the L1 key is critical, especially if all devs will sign that > key. E.g. this will allow people with access to L1 to establish a new > tree without the knowledge of everyone who signed the key but the new > tree will be able to issue new signatures and everyone will accept them > because L1 is trusted. Unacceptable. Process must be clear for > _everyone_. No blackbox. I don't understand what you mean here. It is inevitable that person having access to L1 key will be able to divert the trust. Ergo, we want to protect the key just like we protect service keys. If you mean that every developer should have access to L1 key, then you're introducing over 150 attack vectors. Not to mention the majority of developers doesn't understand much of OpenPGP, nor cares to, so any attacker could trivially find a developer who doesn't protect his copy (or access) to the key. There doesn't exist any solution that doesn't involve having at least one person who could abuse the key. We can't do anything without putting trust in *someone*, and in this particular case Infra makes sense because they need to be trusted for a dozen other reasons. > > +The fingerprint of this key is published > > +on the Gentoo website and users are requested to sign this key to enab= le > > +key validity via Authority Keys. >=20 > This is problematic. Nobody should ever sign something because it was > published somewhere. I know this will be a hard challenge but I believe > the L1 key can only be created if infra people will meet in person: >=20 > - This will guarantee that nobody will take a copy of the L1 key, > assuming we trust these people (maybe do this during a Gentoo conference > so other people can watch the ceremony). >=20 > - We will sign L1 only because it was signed by infra person X which we > met in person. E.g. nobody should sign L1 key who hasn't met anyone who > already signed that key. Because mgorny and antarus for example never > met somone else according to current WoT graph, trust anchor will > probably be robbat2 -> k_f -> ... for most people. But signing something > because you were asked to do so without *any* trust anchor should be a > no go. This will render it impossible for a huge majority of users to use this system. Effectively, it will render the proposal useless. Then, people would still end up jumping through hoops to mark individual keys trusted to be able to send encrypted mail or anything, and your 'craving' for security is effectively reducing the actual security of user systems. > My main criticisms, however, is that this system will create a false > sense of security (authenticity to be precise): >=20 > Let's say Gentoo has a developer named Bob. >=20 > Bob's local system will get compromised. Attacker will gain access to > Bob's SSH key and will also find Bob's Gentoo LDAP password. >=20 > With the SSH key, the attacker will be able to connect to > dev.gentoo.org. The LDAP password will allow the attacker to add or > replace Bob's GPG fingerprint. >=20 > Thanks to the new system, an automatic process will sign that new GPG key= . >=20 > The attacker is now able to manipulate an ebuild for example and push > that change. If no one happens to review the commit for some reason and > notice the malicious change, attack will be successful, because the > commit has a valid signature. >=20 > That's basically status quo (see #1). Exactly. Signing doesn't make any difference here. Once the attacker adds new fingerprint to LDAP, the system will accept his commits. Both rsync and git distribution will sign the resulting repository, and all users will happily use it. > Once we detect the compromise, we would disable Bob's access and revoke > all signatures. But this doesn't matter anymore. >=20 > Also keep in mind that currently we only validate last commit. If > another developer will add his/her commit on top of the attacker's > change, the attacker's key doesn't matter anymore. Yes, this is also true but still completely irrelevant to the proposal. > My point is, you cannot automate trust. Yes, if someone has to change > his/her key it will be a pain for everyone... but that's part of the > game. The difference would be that nobody would sign that new key the > attacker added to LDAP because it wasn't signed by Bob's previous key > everyone trusted. So everyone would ping Bob asking what's going on. If > this would be a legitimate key change, Bob would explain that (and > probably sign that new key with the old key or he would have to > establish a new WoT). If this wasn't a legitimate key change, we would > notice... >=20 > I am basically back at #1. Why do we need GLEP 79? It doesn't improve > anything for real aside adding a lot of complexity. Wrong? >=20 Yes, you are. You've basically described everything that's completely irrelevant to this GLEP, and now you dismiss it because it doesn't fix problem that wasn't addressed here in the first place. The point is that it adds some well-described way of determining which keys are currently used by apparent Gentoo developers. It's not perfect but it's better than not having any reasonably accessible way at all.=20 The GLEP describes the terms, and you are free not to use this key if you don't agree with them. Yes, if Gentoo systems suffer a heavy compromise then this system can be abused. However, it also provides a clear way of revoking the involved signatures and/or keys. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-TJ72Xc5X3cJaDeSQkY8s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAlyFVJhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQqLrQ//UTzPuJWw1OkJTDlGf37XpLDaEfVY5FrMccK2ZD6tDishm+eZ0ZNNTdVd jgVr1RCIkFcL5zU/sLRfspcEQEa5GCuewuZmxDmvmqi31W8Lb+OmcHW85hB6b5vi OXhZwTwT9rxUoZx1vzJ/0WBxk5eVzj6+x9b9e0nolTLAVmEmaiugH5mOVPS814Dy zeNeLRxPqqeCT0+hVij8hDL/dHvLeR6Q7/NKbHXDbcT7XqTl0yOt0LM0MYAJIvgE Z8LglS3IQhsbaOQcyhtvluwqId9WFojDOhtum9fR+Txsw2EOjtayGH8YemWr1N+D PmUA5YJeUeYdL9qXwr+X896kZB2C0bKjvFomoAnmosMCm3m2EutabKk6uAKpk0iU 6u6BZiz5nqqv7zT6PXN3p2XY9vZDW/3mgFUCw5cZfMalQGPrqO5P28weQnhFQITr 82VLR2ZNkLWNDEeXKHOvoTsSvlrXcT1f/tsRS8/k8S8p7NvYgi4zQQ4O1a2qFtha AzVOcht5iq3K/+uYc8kur+BWIg4oKR2bOkat5wHGsn7JLgPVgSU9ejn4inperPsp VHazJyXctirU0l93FFMK/r/K+rPwA88lu2eQX5rAuFxTjh5G/bYdEQxeYc6H1zlD M0STUsJ+YvOF2GnnmZzfNqjCY44Z5wAThfgL4L98GQBkxHKTaBg= =KRBA -----END PGP SIGNATURE----- --=-TJ72Xc5X3cJaDeSQkY8s--