1 |
On Tue, 2019-02-19 at 19:47 +0000, Robin H. Johnson wrote: |
2 |
> On Mon, Feb 18, 2019 at 02:22:56PM +0100, Michał Górny wrote: |
3 |
> > > It could also be a bad actor, though that comes with other concerns. |
4 |
> > > The CAFF method is the standard way of handling signatures, switching to |
5 |
> > > ldap also switches our trust store to be based on ldap, not developer |
6 |
> > > keys (anything can be in ldap). |
7 |
> > > |
8 |
> > |
9 |
> > As Kristian named it, could you please explain to me what specific |
10 |
> > threat model does this address? |
11 |
> > |
12 |
> > AFAIU the main purpose of the caff model is to verify that the person |
13 |
> > whose key you are signing can access the particular e-mail address. |
14 |
> > Which certainly makes sense when you are signing an arbitrary key. |
15 |
> > However, I don't really see how that's relevant here, and I'd rather |
16 |
> > not add needless complexity based on cargo cult imitation of caff. |
17 |
> > |
18 |
> > In our case, the key fingerprint comes from LDAP, and is directly bound |
19 |
> > to the particular username, therefore mailbox. I don't really see it |
20 |
> > a likely case that someone would be able to edit developer's LDAP |
21 |
> > attributes but at the same time be unable to access his mailbox. |
22 |
> > |
23 |
> > In other words, as I see it, the caff model can help if: |
24 |
> |
25 |
> Thanks for expounding on the list of issues. I think this covers |
26 |
> all/most of the cases I had in my head. |
27 |
> |
28 |
> > 1) someone manages to compromise LDAP without compromising e-mail |
29 |
> > service, |
30 |
> |
31 |
> - Compromising email has a couple of routes: |
32 |
> 1. Getting into dev.gentoo.org (SSH creds). |
33 |
> Either lets you see mail directly there, or edit the forward. |
34 |
|
35 |
Also note that this would also happen if one of infra members' |
36 |
credentials + sudo password leaked. |
37 |
|
38 |
> OR |
39 |
> 2. If a dev has their mail forwarded, you can also compromise |
40 |
> somewhere else in the forwarding chain. |
41 |
> - Compromising LDAP requires: |
42 |
> 1. A shell in a larger set of machines (need SSH creds to any user on hosts that are LDAP clients) |
43 |
> AND |
44 |
> 2. A LDAP password with suitable power (note that the SSH creds and |
45 |
> LDAP password could be from different compromised users), which means |
46 |
> either the target, or the LDAP password of somebody in |
47 |
> comrel/recruiters/infra. |
48 |
> |
49 |
> > 2) a developer accidentally puts the wrong fingerprint in LDAP, |
50 |
> |
51 |
> This has happened before; esp w/ devs putting subkeys into LDAP. If not |
52 |
> in-band with this proposal (e.g. CAFF), can we see some other validation |
53 |
> for the keys? |
54 |
|
55 |
I think the simplest verification would be to verify that |
56 |
the corresponding key has appropriate @gentoo.org UID. If it doesn't, |
57 |
there will be no UID to sign anyway, so it wouldn't harm the process. |
58 |
|
59 |
> > 3) a developer has broken e-mail setup, |
60 |
> > |
61 |
> > 4) a developer is inactive. |
62 |
> > |
63 |
> > I think cases 1)-3) are rather unlikely, and 2)-3) belong to |
64 |
> > the 'wrong place to solve the problem' category. 4) practically relies |
65 |
> > on making an assumption that we don't want users to trust developers who |
66 |
> > aren't active enough to add this signature. |
67 |
> |
68 |
> 3) would be good to detect on the less-active devs, and gives good |
69 |
> life-signs to undertakers. |
70 |
|
71 |
Maybe. However, we're practically talking about one-time check here. |
72 |
Once the key is initially signed (and if the developer ignores GLEP 63 |
73 |
expiration suggestions), there will be no reason to mail him again. |
74 |
|
75 |
> > The other side of this is added complexity on the scripting side, for |
76 |
> > a start. We need to store to whom we sent signatures to avoid resending |
77 |
> > them over and over again. Then, we need to able to force resending if |
78 |
> > the developer lost the mail for some reason. |
79 |
> |
80 |
> Save the signature to a file, email the file, retain the file for |
81 |
> record-keeping, resend the file until they do something about it. I |
82 |
> think the CAFF codebase does already support this variant to not |
83 |
> regenerate pending signatures. |
84 |
> |
85 |
> > Finally, there will be at least a few developers who won't be covered by |
86 |
> > this because they won't care enough to add the signature to their key. |
87 |
> > |
88 |
> > My original goal was to cover all active developers because users might |
89 |
> > have their reasons to contact any of the developers, and I don't see any |
90 |
> > reason to exclude anyone from this. It's not equivalent to giving |
91 |
> > people access to any system, privileges to perform any specific action. |
92 |
> |
93 |
> Users sending mail to an unverified key seems like a concern to me. |
94 |
|
95 |
Gentoo developer would argue that a key is unverified if they make |
96 |
commits with it. Maybe we could use that as some kind of implicit |
97 |
metric. |
98 |
|
99 |
> |
100 |
> > It's mostly about confirming which OpenPGP key should be used to send |
101 |
> > mail to a particular e-mail address. The same as if you went to |
102 |
> > the developer listing and checked key IDs there, except more automated |
103 |
> > and using a single authority key rather than PKI for verification |
104 |
> > (though at least initially the authority key would itself be verified |
105 |
> > against PKI). |
106 |
> |
107 |
> Related codepath not discussed yet: |
108 |
> - detect keys REMOVED from ldap and generate revoke of signature on those. |
109 |
> |
110 |
|
111 |
Actually, I had thought of that and the demo implementation [1] supports |
112 |
that already. Basically, it compares list of fpr+uid from LDAP with |
113 |
UIDs trusted on locally known keys (provided that new keys and updates |
114 |
are fetched but old keys aren't removed). If new fpr+uid is added to |
115 |
LDAP, the diff causes it to be signed. If fpr+uid disappears from LDAP, |
116 |
the diff causes signature to be revoked. |
117 |
|
118 |
This has a corner case/bug that if we revoke a signature, gpg normally |
119 |
doesn't let us sign the same uid again. However, this is rather rare |
120 |
(would happen either for returning devs or because of script bugs) |
121 |
and we can circumvent it manually by removing the old signature (then |
122 |
gpg lets us sign again, and the new signature works fine afterwards). |
123 |
|
124 |
[1]:https://github.com/mgorny/gentoo-authority-key |
125 |
|
126 |
-- |
127 |
Best regards, |
128 |
Michał Górny |