@Nick I don't understand the supposed attack vector concerning the file digests being of no value and the WoT being essential.
- Dennis ANALYSIS So long as the digest value is obtained from a reliable read-only source, it doesn't matter where the file comes from, the digest can be verified. This will protect against and help detect a poisoned mirror site or a third-party redistribution that substitutes an inauthentic artifact. That is, in fact, a very big deal and it defends against exploits that happen too regularly. If the reliable read-only source is compromised, that means an adversary has managed to (1) replace the file in Apache custody, and (2) replace the digest that applies to that artifact. (Or just replace the digest and make the authentic file look bogus and the poisoned downloads look authentic.) If substitution of the file-digest pair is achievable, providing a different external signature can't be much harder, although the exploit might achieve the intended purpose without that. Introducing a verifiable external signature that finds a counterfeit public-key certificate on a key service may extend the ruse a little longer. The exploit continues until some Apache folk or security-proficient external party detect (1) the substitution or (2) a counterfeit external signature or (3) confirms that the external signature is not verifiable on the substituted file and digest pair. I don't see the WoT as much of a factor if this exploit occurs. It comes down to how quickly the exploit is detected, the damage detected, and a mitigation put in place. I assume that infrastructure defense-in-depth measures have to expose the fact of an exploit, even if an insider is involved. At the worst, it might be necessary to recall a release. This assumes that the exploit is by exploit against the read-only distribution material in Apache custody. If the exploit is by tampering with a release prior to its approval, that is an entirely different problem, since it means the digital artifacts have been approved as authentic. Even so, I think it is the trustworthiness committers, release managers, and PMC approval that matters here, not the WoT, and that is bolstered by the Apache Trust Chain. The WoT does not protect against someone subsequently being revealed to have committed a bad act. (The revocation of trust and how it is noticed is an aspect of WoT that I have not investigated.) -----Original Message----- From: Nick Kew [mailto:[email protected]] Sent: Thursday, October 11, 2012 06:46 To: [email protected] Subject: Re: key signing On 11 Oct 2012, at 09:57, Noah Slater wrote: > On Thu, Oct 11, 2012 at 9:01 AM, Nick Kew <[email protected]> wrote: > >> >> You have to extend that assumption not only to our infrastructure but to >> every proxy that might come between us and a user, and that might >> substitute a trojan along with the trojan's own SHA1. >> > > The same reasoning holds for the .asc file. Only if there are no WOT paths to improve confidence in it. And only if noone ever detects the imposter, which is a lot less likely with a trojan PGP key (someone in particular is being impersonated) than a checksum (owned by noone). -- Nick Kew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
