[ On Monday, July 28, 2003 at 17:02:12 (-0400), David Maxwell wrote: ]
> Subject: Re: problem with download-vulnerability-list
>
> 
> Previously, I wrote:
> a) Protection from infrastructure errors. (e.g., salo's commit)
> b) Protection from rollback (version numbering)
> c) Protection from unintentional data corruption (hashes)
> d) Protection from editor error (e.g., typos) ('lint')
> e) Integrity as delivered from TNP (signatures)
> f) Integrity as proposed from a developer (signatures)
> f') Integrity from malicious inserts/edits         
> 
> On Mon, Jul 28, 2003 at 04:48:57PM -0400, Greg A. Woods wrote:
> > > Subject: Re: problem with download-vulnerability-list
> > > e requires infrastructure, harware, and keys.
> > > f requires infrastructure and keys.
> > 
> > No, not really, at least not additional infrastucture and hardware,
> > etc. (though I suppose it depends on what you mean by keys).  We have
> > precedent of using various checksums and MD5 signatures and such for
> > other files and I think we'd all agree that at least one of these
> > existing tools is sufficiently secure for verifying the integrity of
> > files published on the web and ftp servers and mirrors.
> 
> That's a response to (c). It does nothing to confirm that you got the
> file that TNP intended (e), or that the developer intended (f/f').

Well, it was intended primarily to be a response to (e) and (f), though
of course it does cover (c) as well.  Besides you need (c) to achieve
(e) and (f).  You also need (e) to achieve (f) and (f') or else you
can't trust TNF in the first place.  Indeed from an end user's point of
view (e) and (f) are identical.

What I'm saying is that you don't need a trusted third party to sign
your existing file digests if you have some secure way of distributing
the latter out-of-band from the original files.

If you assume that two un-related mirror root sites cannot be hacked in
the same way at the same time (not an unreasonable assumption for
relatively low-risk data such as Open Source product) then matching data
(or re-computing and matching simple file digests) copied from two
independent original sources confirms that the data has not been
corrupted at one of the original sources [(e) and (f)] and also confirms
that no corruption has occurred along at least the un-related parts of
the transit path [(c)].

I.e. make a mirror of mirror trees so that every leaf mirror can be used
as either an original bulk data source, or a digest source.  Users can
use a nearby mirror from one tree for their bulk downloads and then a
far-away/heavily-loaded mirror from another tree for integrity checking.

> > If the files and their signatures are both separately and securely
> > published to at least two completely separate mirror roots then users
> 
> That's not especially practical. Currently, mirrors are run on servers
> which NetBSD developers don't have access to, and files are mirrored
> automatically.

I'm only talking about one additional mirror root, not all the mirrors,
and it's one which need only be an existing mirror that's able to
co-operate closely, not one that must be created completely from
scratch.

The whole idea behind my proposal is to limit the impact on everyone to
the bare minimum required.  This proposal also automatically covers all
the other files that are currently signed with simple MD5 digests and
such, assuming they have some secure private origin and that someone
trusted publishes them in a secure manner to the mirror root servers.

Identifying which leaf mirror site has used which root is automatic and
needs no intervention by the mirror operators.  The only intervention
required by all the mirrors is to make sure they don't all source from
the same ultimate root server.  Obviously all the mirrors still have to
be run securely so that we can't be spoofed into thinking that any pair
don't have different roots than they really do.

> I really meant _signatures_ i.e. proving that this content came from an
> entity with intent.

Even if you use a commonly trusted certificate authority to sign the
file signatures themselves you don't end up with anything that indicates
"intent" -- only that the original signature itself hasn't been tampered
with.  I.e. use of a CA only really solves (f), not (f').

I know you, David, already know this, but let me just explain to the
ether why I'm going where I'm going by discussing how it's related to
the use of PKI to verify file integrity.  The use of a third-party CA is
in fact just an optimised mechanism of distributing file signatures
out-of-band.  It works by counter-signing (encrypting) an original file
"signature" (secure file digest, computed with md5 for example).  It
allows you to verify the integrity of a file by re-computing its
"signature" (digest) and then comparing the result with a PK encrypted
copy of the same "signature".  To simplify a little I think we can just
say the encrypted signature is decrypted with the help of a public key
retrieved "out of band" directly from the CA that signed the original
digest, thus the original file "signature" (digest) is verified with an
out-of-band test.  Use of a public key crypto infrastructure and
certificates to sign file digests also allows a one-time (and usually
limited life) certificate to be used to sign multiple digest files
without needing the direct intervention of the root CA and/or the
issuing CA for every signature.  However if we can only trust a
third-party CA that we pay to keep their reputation intact then this
method of out-of-band key distribution costs hard cash.

Clearly the use of a pair of separate mirror trees is simpler and
cheaper (no need to pay a third party certificate authority just so that
you can trust them) provided you're willing to live with the few obvious
limitations (primarily that of trusting at least the mirror roots, as
well as whichever one of the other mirrors you fetch the bulk of your
data from, to all be run and hosted as securely as possible).

On the other hand maybe some existing and widely recognized certificate
authority has a non-profit discount price....  There are, after all,
good reasons for using a certificate authority to optimize the
out-of-band distribution of signature keys, though it still assumes the
end user does due diligence and verifies that each signature hasn't been
revoked.

Maybe the use of the existing PGP web of trust can be leveraged for
free....  but how many people would use it as intended?

In any case is use of any kind of PKI necessary for these purposes?
Aren't simple file digests and multiple, secure, distribution channels
sufficient?

> In the scope of the vulnerabilities file, this would just require
> confirming the statements released by the 3rd parties about announced
> vulnerabilities.

... which would imply they've retrieved the fix as published, then
verified that the signature is valid, and finally confirmed its
viability as a fix.  It also assumes that the original signature would
be immediately revoked if such confirming statements were not received
from the third party in some limited time.  It all gets very complicated
if you don't trust the TNF maintainers to be able to securely publish
their files in the first place.  I think all of this additional
complexity of using a certificate authority to sign the file digests can
be safely avoided if we can put the burden of doing a minimum of two
separate secure publishing tasks on the TNF maintainers and simply
arrange for a minimum of two separate mirror trees.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>