Re: [gentoo-project] [pre-GLEP RFC] New GLEP: Gentoo OpenPGP Authority Keys

[Michał Górny]

On Sun, 2019-03-10 at 17:53 +0100, Thomas Deutschmann wrote:
> Hi,
>
> I know I am late but...
>
> 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:
>
> > +The single L1 Authority Key is used only to (manually) certify the L2
> > +Keys, and is kept securely offline following the Infrastructure policies
> > +on protecting primary keys.
>
> 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 enable
> > +key validity via Authority Keys.
>
> 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:
>
> - 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).
>
> - 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):
>
> Let's say Gentoo has a developer named Bob.
>
> 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.
>
> 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.
>
> Thanks to the new system, an automatic process will sign that new GPG key.
>
> 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.
>
> 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.
>
> 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...
>
> 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?
>

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. 
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.

-- 
Best regards,
Michał Górny