[libre-riscv-dev] web-of-trust for code reviews to manage trusting dependencies

[Jacob Lifshay]

On Tue, Aug 27, 2019, 02:47 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Tue, Aug 27, 2019 at 10:05 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > crev has a separate proof repo for each key owner. the idea is the person
> > signing the proofs is the one who owns the repo.
>
> that's even worse than i thought it would be.  that leaves no
> possibility of independent auditing (you're saying that a *single*
> person is now the point of failure), and almost certainly leaves it
> vulnerable to a 2-stage compromise attack.
>
> compare this to debian's procedures: the web-of-trust is itself a
> package that is itself submitted via the same inviolate procedures
> that all other packages go through.
>

the idea is more that each individual developer would verify through the
people they directly trust. every developer ends up with their own web of
trust.

>
>
>
> > > the mistake that the morons behind Mozilla's B2G (failed, thank god)
> > > effort made was to go "i have a great idea!  let's make SSL the way to
> > > do repo distribution!  let's use SSL certificates so that people can
> > > trust them!  let's host the SSL certificates on servers!"
> > >
> > > which now makes the servers - and the certificates on them - a
> > > high-value hacking target.
> > >
> >
> > for crev, the signing keys are only on the developer's computer (or other
> > device used for signing), not the git server.
>
> how are the signing keys independently audited as trustable?
>
> *are* the signing keys independently audited as trustable?
>

not sure.

>
>
> > > debian's process - which has nothing to do with debian itself - has
> > > gone to a *lot* of trouble to ensure that there are no single-person
> > > or single-resource targets, *particuarly* networked single-resource
> > > targets.
> > >
> > > where it is absolutely essential that an individual be trusted, then
> > > instead they use "social engineering" to ensure that the person's
> > > identity is inviolately known to as many other individuals as
> > > possible.
> > >
> >
> > crev associates your identity with the git server and signing keys, which
> > is very similar to how Debian does that.
>
> that now makes the git server a resource failure.  take down the git
> server, and you just caused the entire network to fail.
>
> debian does *NOT* do this.  there is absolutely *NO* dependence on
> even the *existence* of network traffic.  or server names.
>
> yet another serious design flaw.
>
> are you starting to see how complex this really is?
>
> > crev also has a negative trust level, where someone can distrust someone
> > else -- I don't think PGP has that, though I could be wrong.
>
> GPG has key-signature revocation.  here is the procedure:
> https://security.ias.edu/how-revoke-gnupgpgp-signature-key


revocation is not the same as negative trust. revocation is where one
person says they no longer trust someone (with the trust level reverting to
no association). negative trust is where one person says that someone is
not to be trusted, and that is transitive. so, for example, if i saw fred
(made up person) do something untrustworthy, I could sign a negative trust
record, where if you trusted me, then you would transitively distrust fred.

>
>
> > > ... *and the end-user can still verify it*.   all without needing any
> > > kind of network resource.  they can start from a SHA256 checksum and
> > > go from there.
> > >
> >
> > I think crev does support a offline mode, it just removes the proof-repo
> > location verification and keeps the signature verification, so the
> security
> > goes back down to GPG's level.
>
> which is simply not good enough.  another serious design flaw has been
> identified.
>
> what you're saying in effect is: all that an attacker need do is
> arrange a DDOS attack against a server (or to hijack its DNS records)
> or anything else that takes users into "offline" mode, and crev "falls
> back" to a completely brain-dead and fundamentally broken "security"
> mode?
>
> > > is the crev "trust" repo distributed as a secured package?
> > >
> >
> > I think there might be a problem in the current implementation where a
> new
> > identity key isn't required to be signed by an old identity key,
>
> so that's another serious design flaw (and, also, the idea that an
> identity key is signed by an old identity - only - is itself a
> security design flaw).
>
> > though
> > that may not be a problem if each key propagates trust independently.
> will
> > have to check.
>
> the design flaw that you missed was that by putting the "trust" repo
> through the "system" as a secured package is: there are *independent*
> checks - by *other people* - hard-coded into the chain.
>
> you - the "signer" of the repo - are *NOT* the sole exclusive single
> point of "trust".
>
> the more that you're telling me about crev, the more alarmed i am becoming.
>
> > there isn't a centralized trust repo. each owner has their own repo which
> > (I think) is only allowed to contain items they signed. so, potentially,
> a
> > repo owner could add a key with their identity but let someone else sign
> > stuff with it, but Debian's system has the same problem of someone
> creating
> > a gpg signing subkey but letting someone else have it, allowing
> > impersonation.
>
> if any debian developer is caught doing that, they'll be expelled.
> worse than that, the fact that they did so would be published widely
> on the internet, resulting in the total destruction of their
> reputation and career.
>
> as it would be extremely high-profile, no employer would let them near
> their systems ever again.  they would no longer be trusted - ever -
> for the rest of their lives.
>
> when an employer asked their peers for an endorsement, their peers
> would refer them to the incident and to the key-revocation records.
>
> doing something as stupid as letting other people have access to a
> private key, when that person *specifically* went to the trouble of
> showing GOVERNMENT ID, not just once but multiple times, is... i mean,
> the thought of someone being happy with the consequences of sharing
> their private key after going through such an identity-proof
> procedure, they would actually have to be seriously mentally ill.
>
>
> > from what I can tell, the proofs repo is a layer built on top of the
> > already secure gpg-clone signing system, so it just adds additional
> > security.
>
> not good enough.  that's a really dangerous assumption.  that just
> means that the gpg-clone signing system needs a full audit as well.
>
> > > *when* they've done the research, and carried out a proper
> > > comprehensive formal side-by-side evaluation of *all* package
> > > distribution systems out there (the good ones, the mediocre ones with
> > > flaws such as archlinux, and the downright dangerous and stupid such
> > > as npm and Mozilla's B2G), and *when* they can tell people like me why
> > > ubuntu has flaws that debian does not (even though they use the exact
> > > same code and the exact same process), *then* i'll have the confidence
> > > that they know what they're doing.
> > >
> >
> > yeah.
>
> design of security procedures is unnnbelievably hard.  i *know* that
> you're an intelligent, smart person, and yet you're making *basic*
> fundamental security and security design assumptions!
>
>
> > do note that even if crev turns out to be flawed, it's still waaay better
> > than npm is right now
>
> not really.  all that a flawed system does is deceive people.  this is
> a recognised phenomenon in the Intelligence Community.
>
> the intelligence community's worst nightmare is not that something is
> insecure or secure, it's *not knowing* if something is secure or
> insecure.
>
> if they *know* that something is insecure, that at least allows them
> to put mitigation procedures in place, and to deploy risk-value-threat
> assessment processes.
>
> if they *don't know* if something is secure or insecure then they have
> to assume the absolute worst-case scenario.
>
> this is *NOT* something that the average person can get their head
> round.  the average person goes, "um, it might happen to me, but it
> might not.  it's not happened to me, therefore it can't happen to me,
> therefore i'm okay and can safely ignore the threat".
>
> this is fine for when we were wandering through jungles and bashing
> things on the head for food: it's where, from an evolutionary
> perspective, our brains became hard-wired for a "lightning fast
> reaction time" risk/threat assessment.
>
> it's the complete opposite that's required for the kinds of scenarios
> that global networked communication presents us with.
>
>
> > (though I think they're finally supporting gpg
> > signature checking soon).
>
> that's a stopgap measure.  it'll do for now.
>
> when people start talking about making it mandatory, the problems with
> "just gpg signatures" will start to show up.
>

so, I guess the conclusion is that crev has some good ideas, but needs some
serious protocol overhaul (which they might be willing to do, it's still in
alpha releases, I think).

Jacob