Re: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5970 bytes --]

On Tue, 2019-02-19 at 19:47 +0000, Robin H. Johnson wrote:
> On Mon, Feb 18, 2019 at 02:22:56PM +0100, Michał Górny 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).
> > > 
> > 
> > As Kristian named it, could you please explain to me what specific
> > threat model does this address?
> > 
> > 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. 
> > Which certainly makes sense when you are signing an arbitrary key. 
> > 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.
> > 
> > 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.
> > 
> > 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: 
>   1. Getting into dev.gentoo.org (SSH creds). 
>      Either lets you see mail directly there, or edit the forward. 

Also note that this would also happen if one of infra members'
credentials + sudo password leaked.

>   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 hosts that are LDAP clients)
>   AND 
>   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?

I think the simplest verification would be to verify that
the corresponding key has appropriate @gentoo.org UID.  If it doesn't,
there will be no UID to sign anyway, so it wouldn't harm the process.

> > 3) a developer has broken e-mail setup,
> > 
> > 4) a developer is inactive.
> > 
> > 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.

Maybe.  However, we're practically talking about one-time check here. 
Once the key is initially signed (and if the developer ignores GLEP 63
expiration suggestions), there will be no reason to mail him again.

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

Gentoo developer would argue that a key is unverified if they make
commits with it.  Maybe we could use that as some kind of implicit
metric.

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

Actually, I had thought of that and the demo implementation [1] supports
that already.  Basically, it compares list of fpr+uid from LDAP with
UIDs trusted on locally known keys (provided that new keys and updates
are fetched but old keys aren't removed).  If new fpr+uid is added to
LDAP, the diff causes it to be signed.  If fpr+uid disappears from LDAP,
the diff causes signature to be revoked.

This has a corner case/bug that if we revoke a signature, gpg normally
doesn't let us sign the same uid again.  However, this is rather rare
(would happen either for returning devs or because of script bugs)
and we can circumvent it manually by removing the old signature (then
gpg lets us sign again, and the new signature works fine afterwards).

[1]:https://github.com/mgorny/gentoo-authority-key

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]