security projects thoughts

[Jeff Johnson]

On Apr 18, 2011, at 2:16 PM, Daniel J. Luke wrote:

> On Apr 18, 2011, at 2:01 PM, Jeff Johnson wrote:
>> 
>> Differentiating a 3rd party package that originated outside of
>> The One True Build System needs either a trusted time stamp
> 
> how does a trusted time stamp tell you that the origin wasn't from the one true build system?
> 

Because a trusted time stamp comes from a CA that is required
to maintain a record in context of the time stamp.

You can of course set up RFC 3161 access through https with all the
usual certification rituals. But the CA records where the request
came from and is mostly unforgeable if correctly used.

And it just instn't that hard to set up a build system with RW access
dolely from the build system, and RO access publically.

>> (which has persistent trackable history) or a pubkey registry.
>> 
>> The issue hare so far hasn't been about 3rd party distributed build systems
>> and how origin authentication might apply to those other, non-existent,
>> systems. Heck The MacPorts "package build service" is so far
>> just a gleem in Jordan's eye ...
> 
> I thought that the problem this was supposed to fix was to prevent installation of rogue packages (but maybe I misunderstood)?
> 

No origin authentication means it came from The One True Build System and
nothing more. If the TOTBS is delivering malicious packages, the non-repudiable
signature is useful forensics even if not useful for end-users.

>>> My question was, how does the client know it's talking to a legitimate keyserver when it's validating the public key from the package.
>> 
>> The usual means of securing pubkey retrieval for validation is to use a different
>> retrieval channel, with other means of securing the pubkey retrieval that is different
>> from the actual package signature.
> 
> Anyone who is going to the trouble to impersonate the package server (route mangling, DNS hijacking, whatever) can also redirect flows meant for pubkey validation. I don't see what the signature buys if it can't be reliably verified.
> 

Noone I know, and certainly not me.

All I'm trying to establish here is "origin authentication" (however that
is implemented) is a mostly solvable problem while discussions of whether
sudo is tampered with (or not) are different (and largely unsolvable) issues.

Implementing "origin authentication" is much narrower in scope, and reduces
the fare more complex issue of a sound security framework to
	How does one protect TOTBS?
which is a much easier problem to solve imho.

> I don't necessarily have an answer for the problem either (I suppose the official clients could have some auth token they could use to validate the pubkey registration server).
> 
>> By all means, set up all the usual security rituals if you wish.
> 
> I don't :)
> 
>> My point is solely
>> that binary package distribution needs "origin authentication", not all the rest
>> of the creepy-toe security ritual fetishism. And "origin authentication" is a mostly
>> solvable problem with "robo-signing" if resources are short.
> 
> It sounds good to me. I'm just trying to wrap my head around it.
> 

Yah mon, creepy-toe makes everyone's head hurt and its very hard to Get It Right!

Again "origin authentication" is all that binary package distribution needs.

Just like FedEx needs a signature on delivery and it really doesn't
matter (to lawyers and lusers alike) whether the "package" contains methamphetamine
or child p0rn. The origin is trackable through FedEx delivery.

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110418/2e7d7a62/attachment-0001.bin>