[ On Monday, July 28, 2003 at 14:23:02 (+0200), Alistair Crooks wrote: ]
> Subject: Re: problem with download-vulnerability-list
>
> Yes, I agree that they should not be maintained manually.

I'd be even happier to see some out-of-band mechanism used to distribute
the "check sum" or "signature" (whatever that may be).

Having a second tiny file on the same server does help one detect
transmission errors in the main data file, and possibly increases the
effort an attacker in the middle has to put out to spoof the data.  So,
ideally this signature would be published from a different host, and
perhaps with a different application protocol as well (assuming
anonymous access continues to be granted and that the basic transport
protocol continues to be plain TCP/IP).  The important part though is
that there be no permanently established trust relationship between the
two information sources.  Obviously the actual generation of the "check
sum" or "signature" or whatever should be somewhat automated.

This does mean the maintainer has to authenticate to two separate
servers to publish the information and its signature, but it hopefully
almost doubles the amount of work an attacker has to go through to spoof
the list either at the point of publication or during transport.

> It is problematic to include an sha1 digest and timestamp in the
> vulnerabilities file itself, although it could be done (we do that for
> the patches/* files right now), but this adds complexity to what is
> now a simple process:

The complexity of including a signature in the same file it signs is the
least of the issues, at least from the point of view of anyone wishing
to establish how well the information contained within the file (or
rather the data stream it was retrieved from) can be trusted.

It's one thing to trust the word of the NetBSD security officer in
stating that the servers the data and its signature are retrieved from
have no inherent trust relationship that an attacker could utilize to
modify both without easy detection.  It's quite another to trust a
"signature" distributed within the very same data stream, especially
when that data stream is transported over a single plain old TCP/IP
connection.

I do fully realize that separately publishing file signatures is more
work, not just initially but on an ongoing basis.  However in the
general case I think it might be done without a huge amount more effort
if one or more of the mirrors switches from being an automated mirror
into being a point of original publication.  This uses existing
resources, but in a slightly different way.  It would mean that all
publishing of files requiring some degree of trust would require at
minimum two separate authentications and two separate pushes of at least
their signatures by the publisher, but it lets the user decide whether
to pull the signatures from a different site (and perhaps using a
different application, e.g. http for files vs. https for signatures) and
it allows a sub-set of the mirrors to retrieve their copies from a
different trusted source (i.e. this second trust relationship can also
be distributed out to us users, e.g. through identifying each mirror by
which of the two root sites its data originated from by having one
top-level file with unique contents on each root site).

-- 
						Greg A. Woods

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