Re: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

[Phillip Hallam-Baker <[e-mail]>]

When writing a specification, it is always important to decide on what
problems you intend to solve and which you plan to leave for others.

Unauthenticated signatures have real proven value in anti-Virus protection.
As Marcus Rannum argued over a decade ago, looking for badness is a failing
strategy because the badness is infinite. If every copy of Adobe software
is signed with a software key that chains to a self signed cert created by
adobe, that provides a vast amount of leverage for AV systems even without
TTP validation.

That is not a theoretical approach, it is precisely how Comodo Default Deny
Protection (TM) works. If you build databases of signatures of known good
software, spotting the bad or the corrupted software is much easier.

That is why I want all software signed without exception. If you try to
gate software signing on a CA issued key you are making exactly the same
mistake that keeps S/MIME at 0.00001% of email traffic. As I argued in the
SSL cert space since 2000 or so, Web browsers should accept self-signed
certificates without complaint or notification to the user. Just drop the
padlock icon telling them the site is secure.

I don't think that the answer to the problem of validation is to set up a
mickey mouse CA that provides certificates without any validation of
organization existence, accountability, proof of right, etc. giving out
rubbish certs for free. Gresham's law applied to the WebPKI: the bad certs
drive out the good. If you try to make CA issued certs mandatory, someone
will come along and reduce the issue criteria to the point where they have
no value over self-signed.


Yes, I am proposing a callsign registry that could be adapted to code
signing. But to be honest, that is not one of the primary motivations for
it nor is it something I have given a lot of thought to in the design of
callsign.

My rough notion is this: @alice, @bob, @carol work for @threshold As they
are developing code, every build they create is signed under their personal
software developer key bound to their Mesh profile by means of a connection
assertion and thus their callsign. So Alice isn't going to run any
developer build not signed by any of the three of them.

When it comes to the general public trusting the signature, they are not
going to know Alice or Bob or Carol and they probably don't know Threshold
so the call sign alone really isn't enough to convince J. Random User to
install and run it. So @Threshold gets a TTP validation of their key and
that is maybe gated so that two out of the three of them have to sign.



On Fri, Jun 11, 2021 at 7:19 PM Toerless Eckert <[e-mail]> wrote:

> Phil,
>
> a) Let me see if i get your high level point correctly and/or expand
> correctly:
>
>    - We want signatures on all pieces of software/data loaded onto systems.
>      These signatures allow to authenticate who (signer) says what
>      about the signed software/data. Not sure if there is a framework
>      for the "what" there is, but i could think of more "what" than
>      just an implied "authentic" binary flag implied by the presence of
>      the signature.
>    - What to make out of those signatures should be different policy
> decision.
>      As in: just because its signed doesn't mean i trust the software to
> run
>      on my system. Trust policies depend on signatures but would embody
>      additional critera such as specific CA for specific software purposes
>      or the like.
>
> b)  Wrt to CA policy freedom (" Basically, the CA can define their boundary
>     to be anywhere they like, that is purely a matter for them to decide")
>
>     This reminds me a bit of ISO9000 and how uneducated customers are. As
> in:
>     There can be thousands of software companies out there that customers
>     trust to be reliable because the software company is ISO9000 certified,
>     and none of those customers ever looked up what that means.
>
>     As in "Our software company ISO-9000 process: before we start coding,
>     every day, we dance on the tables and drink 3 beers to get into the
> mood.
>     End of ISO-9000 process". The ISO-9000 auditors also got free beers,
>     everyone was happy. Worst part: that process might lead to more
> reliable
>     software than some other ISO-9000 audits i have seen.
>
>     Aka: I don't think you get around having some standards for the
>     security boundary you describe and whoever defines that boundary/audit
>     standard could make nice money from e.g. also getting involved
>     into the software signing.
>
> Cheers
>     Toerless
>
> On Fri, Jun 11, 2021 at 02:39:11PM -0400, Phillip Hallam-Baker wrote:
> > On Fri, Jun 11, 2021 at 2:34 AM Hannes Tschofenig <
> [e-mail]>
> > wrote:
> >
> > > Hi Phil,
> > >
> > >
> > >
> > > a few clarifying questions.
> > >
> > >
> > >
> > >    - What is a ???trustworthy credential??? for you?
> > >    - Who is the ???provider??? here?
> > >    - What do you mean by ???Must identify such machines???? Are you
> saying
> > >    that the software / firmware update must identity the machine it
> applies to?
> > >    - When you say ???Every software distribution MUST be signed without
> > >    exception??? are you trying to distinguish between the signing the
> software
> > >    vs. securing the distribution? With regards to the exception you
> are not
> > >    talking about what happens during manufacturing.
> > >
> > >
> > I am distinguishing between Sign ( Zip (files) , k) and Sign (files, k).
> >
> > Authenticode only signed the software distribution package, most of what
> > has followed has done the same. That is a useful control of course
> because
> > an installer is an executable that runs on the machine. But it is
> necessary
> > but not sufficient: Every executable, every piece of installed data
> should
> > be signed without exception.
> >
> > On the other issues, well it totally depends on your application and your
> > regulator. In the aftermath of Diginotar we had a lot of discussions of
> > what should be subject to audit. My position was that is actually
> something
> > the CA decides. Basically, the CA can define their boundary to be
> anywhere
> > they like, that is purely a matter for them to decide.
> >
> > The catch here is that if you are going to show that your practices meet
> > your policy, then you have to show that all your cert issuing machinery
> is
> > subject to audit. Contrawise, the more of your machinery you stick within
> > the audit boundary, the harder time you are going to have showing it is
> > secure.
> >
> > I would apply the same approach here. The pipeline provider etc. has to
> > show that its operations are secure. I am not going to write a list of
> what
> > they have to pur inside or outside of their security perimeter, I am
> merely
> > saying that they have to define one, they have to show that all the
> > necessary operations are inside it and that everything inside it is
> > sufficiently secure.
> >
> > If we are talking about a pipeline then CABForum EV certs are probably
> > sufficient. For civil nuclear, I would consider that a starting point, I
> > would want all software to be signed under a cert that was individually
> > enumerated and credentialed.
> >
> > It is worth pointing out that the reason colonial pipeline was affected
> so
> > badly was probably that they were sending multiple types of fuel down the
> > same pipe in batches. That game is only going to work if you can
> absolutely
> > guarantee that you aren't going to put the load of tar into a tank full
> of
> > top grade aviation fuel. So their problem probably wasn't on their actual
> > operations side itself, the thing they were looking at. They had not
> > understood that the database of what fuel is where was actually critical
> to
> > operations.
> >
> >
> > On provider, I am being deliberately vague because sometimes the provider
> > is going to be the developer, other times it isn't. A large amount of
> > Ubuntu packages are signed by the people who are putting the packages
> > together who are not the actual developer. This third party work does
> have
> > value in that there is a curation process going on there and it is
> possible
> > to imagine mechanisms whereby detected insertion of malware could be
> > revoked. But we don't have those at this point of course.
>
> > _______________________________________________
> > Suit mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/suit
>
>
> --
> ---
> [e-mail]
>