[Date Prev][Date Next]
Re: (ITS#5639) Digital (PGP-)signature for downloadable sources
On Aug 3, 2008, at 11:38 AM, firstname.lastname@example.org wrote:
> Full_Name: Michael Ströder
> Version: HEAD
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (22.214.171.124)
> Source files downloadable fomr http://www.openldap.org should be
> signed. It's common practice to use PGP (GnuPG) for that.
Saying this should be done solely because you claim it is "common
practice" is lame. It would be better to state what attacks you
worry about, and why you think providing digital signatures using a
trustworthy signing key, and what requirements are for this
trustworthy signing key.
But I note the practice is, itself, lame. Often there is no reason to
trust the signing key other than where the link to the signing key was
published. Often the signature itself is not widely published, or
errors in providing it too far common to raise concerns in case the
signature publication fails (by error or attack).
For instance, web_ldap says it provides a signature for a digital
release, but clicking on the link provides a page which says "Not
found". Maybe your releases have been hacked, but most likely its
just publication issue. Most verifiers faced with such such a "Not
found" message will just not perform the verification. Often they
won't even bother to raise an issue to the publisher.
And if an attacker successfully takes over the main website, we have
to realize that they can replace everything. Maybe they will replace
whatever text we have about digital signatures with a statement that
signatures are no longer provided, and then delete them. Or they may
fake publication errors. They could even fake an email to the
announcement list that signatures are temporarily not provided due to
operational reasons, or announce a new signing key.
Fortunately, it is unlikely that such an attack would go unnoticed for
long period of time. I would argue that if takeover was a major
threat (which it might well be), that more time should be spent
detecting a takeover (we have some in place).
I also find it interesting that you suggest signing tarballs and not
announcement messages. I note that an attacker need not modify a
tarball, or cause a new tarball to be distributed, to successfully
mount an attack against the downloader. One could simply point
"stable" to a known problematic release. As the signature for the
problematic release would be valid, it doesn't help the downloader in
detecting they got the wrong release. Of course, even if you sign
release messages, the attacker can still replace the current messages
with prior ones whose signatures would still be valid.
But, as I noted with hashes, the fact that release messages are widely
published may make it more likely that such problems will be detected.
I note as well that properly deploying release signing requires more
than script modification. For instance, one does need to consider
that the host to sign the releases might itself been taken over and
the implications of such a takeover. Also, in signing announcements,
considerable testing would need to take place to ensure produced
signatures were actually verifiable (lots of things muck with email in
ways that invalid email signatures).
Anyways, for this to go anywhere, I think you or others advocating it
need to more precisely state which attacks you concerned about, how
you think digital signatures will help, and detail requirements on
that signing (in particular, requirements on signing key so trust can
be established and maintained).
I note that GNU PGP folks say that verification of a wide published
message digest is sufficient to ensure the integrity of their releases.
Basically, PGP signing here offers little value as an attacker who has
supplanted the other protections (namely widely distributed message
digests) is in position to convince most every downloader than the
current release is not signed, or was signed but that signature is not
currently available, or was signed by some key other than that
previously used by the distributor.
Note that these are human-factor attacks, not attacks based upon any
weakness in the PGP signing standards or implementations.