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

[Alec Warner]

I will probably end up repeating a lot of what mgorny has said later, but
I'll try to be concise ;)

I want to start with a premise, which is that most users don't have a trust
web, and so saying things like "we should build a web this way" or "users
should use a web" is self-defeating, our target userbase doesn't have one.

On Sun, Mar 10, 2019 at 12:53 PM Thomas Deutschmann <whissi@g.o>
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?
>
> 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.
>

Currently infra can make the website do whatever it wants, so anyone
chaining to LE already trusts Infra implicitly. Most users use this method:
they go to the website, look up a fingerprint, import it, verify with it,
etc. They don't use the trustdb to make these decisions.


>
>
> > +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 could do something like generate the L1 key in a nitrokey if you wanted.
It would be somewhat problematic to durably tie it to the hardware like
that, but it seems fairly straightforward and costs 50$. Watching the
'ceremony' at a conference is not sufficient to prevent key ex-filtration;
you have to trust the laptop, the code its running on, etc. As mgorny
notes, trust must be rooted somewhere in this model.

Maybe you could build some kind of weird multi-factor solution where e.g.:

robbat2 brings the laptop.
mgorny brings a USB stick with some OS on it
antarus brings the nitrokey

The likelihood that we can generate a key safely is likely high in that
environment. You still end up trusting all of us to not steal the key
somehow and obviously there are occasions when we need to use the key (e.g.
L2 key rotation) and all the same caveats apply to that use.


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

I don't particularly disagree with this, but I also don't think signing the
L1 is a critical portion of the proposal.


>
> My main criticisms, however, is that this system will create a false
> sense of security (authenticity to be precise):
>

Like mgorny' I'm going to mostly ignore everything below, because its
unrelated to the proposal. I will assert there is one snag here:

1) I'm an existing Gentoo user.
2) I have a web of trust.
3) I verify the tip of tree with my web[0]

If I then participate in this proposal:
1) I would go to api.g.o and get the L1 FP
2) I'd import it into my web and trust it.
3) Suddenly I potentially trust a bunch more keys because I'm trusting the
L1 key.
4) Its plausible for a commit to be marked-bad with my pre-L1 web, but OK
in my L1 web, and I don't think there is a way to tell the difference.

The second outcome is bad for users who use their web to verify a tree and
its likely those users should *not* trust the L1 key[1].

[0] Since many committers are not in the web, I'm already skeptical, but
lets assume its possible.
[1] Now we get into more confusing situations where we have subwebs and
various trust-levels and I'm just not sure how that works out, or how the
software acts when there is a conflict. In theory I'd want two keyrings
here right, one is my "real web" that I trust more than the "L1 web" and if
the real one says its bad, and the L1 says its good, I should trust the
real one and ignore the L1. But since its challenging to validate all
commits with just the real web, I potentially need both webs to verify all
commits and the L1 is a simple way to say "hey all of these keys are Gentoo
keys."


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

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


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

The assertion is that most users don't use a web (and don't want to) and
for those users its a net improvement to trust the L1 key. If you already
use a web then the value in this proposal is diminished due to the extra
risk the L1 key poses for your trust db.

-A


>
>
> --
> Regards,
> Thomas Deutschmann / Gentoo Linux Developer
> C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
>
>