Re: (ITS#5639) Digital (PGP-)signature for downloadable sources

[Kurt@OpenLDAP.org]

On Aug 3, 2008, at 11:38 AM, michael@stroeder.com wrote:

> Full_Name: Michael Ströder
> Version: HEAD
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.163.112.78)
>
>
> Source files downloadable fomr http://www.openldap.org should be  
> digitally
> 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.