security projects thoughts

[Arno Hautala]

On Mon, Apr 18, 2011 at 12:36, Jeff Johnson <n3npq at mac.com> wrote:
>
> On Apr 18, 2011, at 12:04 PM, Arno Hautala wrote:
>
>> On Mon, Apr 18, 2011 at 11:34, Jeff Johnson <n3npq at mac.com> wrote:
>>>
>>> You asked what other systems are in use. I replied. If you
>>> don't like what is implemented, all I can say is
>>>        Patches cheerfully accepted.
>>
>> I asked what systems are in use in order to investigate options for MacPorts.
>> I'm pointing out an issue that I see with this example.
>
> And I replied and your objections were both read and noted.

And now I've replied to that.
It seemed to me that you were dismissing my response as if to say you
were just responding to my request for what other systems did and
weren't interested in a discussion of their merits.

>>> What is the connection between a "web server" and "package management"?
>>> There are serious differences in the implementations and usage cases
>>> and risk factors involved. You cannot just reason that all "content delivery"
>>> is the same.
>>
>> You mentioned non-repudiable signing as used by RedHat to be similar
>> to "self-signed host certs". I assumed this to be an analogy to web
>> servers. So I offered a critique of that analogy.
>
> I described a non-repudiable signature scheme in use by RPM, not
> by Red Hat, which is in fact more interested in "branding"
> as represented by an "official" signing key.

Sorry for the conflation of RedHat and RPM. My bad.

> There are no XSS threats in most cases for "package management"
> because the delivery is usually from static content on mirrors,
> not from some dynamic store. Even if "packages" are delivered from
> a "web server" the attack is against the server, not the
> sausages delivered by the server. The sausages (in the scheme I described)
> WILL continue to have a public key and a signature that can be verified
> no matter what other exploits there are. So I'm not sure the analogy
> to a "web server" is meaningful or useful to "package management".

I didn't bring XSS or anything else in to the picture.
You mentioned "self-signed host certs" as an analogy for the RPM
signing method. I took, and still take, this as an analogy to self
signed certificates as used by SSL for a web server. I was pointing
out that single use key pairs were less useful than a self signed web
cert because at least the web cert would be reused from day to day and
convey some sense of identity between visits.

If the RPM single use key pairs are actually signed by another
authority, that analogy breaks down.

Did you have something else in mind in mentioning "self-signed host
certs" that I'm still misunderstanding?

>>> Not even close to the point if you think more bits in a hash
>>> is more "secure".
>>
>> It's at least part of the goal (re: larger hash space, lower chance of
>> collision).
>
> I do not read your thoughts. Say what you mean as precisely as possible.

I mean that a longer hash probably isn't longer just for the sake of
being harder to type.
It's using more bits in order to increase the range of hash values. If
the hash is implemented correctly, this means accidental collisions
are less likely than they are in a shorter hash.

In other words, an 8 bit hash can securely verify the alphabet, but
will start running into collisions when you start hashing phone
numbers. MD5 should be fine for either, but starts to break down when
you use it for documents.

>>> A trusted 3rd party registrar for pubkeys as well as including the pubkey
>>> in signed content (to avoid DoS attacks preventing pubkey retrieval) is
>>> the basis for the "trust".
>>
>> I fail to see how trust is achieved from using single use key pairs.
>> Also, you hadn't previously mention anything about a 3rd party
>> registrar. If the single use keys are also signed by that 3rd party,
>> you're back to the issue of who to trust.
>
> I'm not responsible for your, or anyone else's, opinion of
> how trust is achieved. I have described a mechansim only.
> Don't do that if you don't "trust" what is implemented in RPM.

I never asked you to be responsible for my opinion. And no one ever
asked you to be the one to implement the features that are being
discussed here. This isn't a place where you're expected to implement
or shut up.
You offered an example of what RPM does. I can see some merit to what
they do, but there are also some decisions that are questionable or of
dubious benefit. I'm discussing those.
And I don't need you to defend RPM, I understand that it's just one
system, with one set of goals, and one set of decisions. It might not
be perfect for MacPorts, or it may just not be perfect for me. Either
way, it's an interesting case to look at and has contributed to the
discussion.

>> These are critiques of the system as presented to be in use by RedHat
>> and how that might direct MacPorts.
>
> Again, I have _NOT_ been associated with Red Hat for years, and I
> described what is implemented in RPM, not what Red Hat does:
>        Pay more for increased security.
> based on faith is one of you available "trust" choices always.

That was meant to be a disclaimer to reiterate that I was discussing
the system as presented. I was stating that I understood that the
person who presented the system didn't necessarily need to defend it.

>> Personally, for trusting the build system, I'm leaning towards
>> supporting a system that robo-signs packages as they're built.
>
> What do you think I just described if not a system that "rob-signs"
> packages as they are built, exactly what Jordan has said.

It's what you might call "conceding the point".
I still have reservations about how RPM is doing things:
What's the point of using a single-use key pair over a hash?
Why bother with a 3rd party notarizer? (If they are doing so.)

Overall, robo-signing is probably the best solution.

I also don't think it's what Jordan was describing. That seems to be
regarding controlling package impact within a chroot. You don't
necessarily have to trust the source of the package if the contents
can't do anything to your system.

Robo-signing says you can trust the generation and content of the
package. The function of the contents still might not be safe if the
original source has been compromised, but you at least know that a few
more legs in the process are secure.

A side note here is that packages could be additionally signed by
developers who HAVE performed the code auditing. If you trust those
developers you may have a bit more trust in the content of the
package.

>> It might be nice to track ports back to their submitters with key
>> signing, but it's probably more trouble than it's worth right now. And
>> there's still the VCS history and Trac.
>
> Binary "package management" (and by inference projects
> like MacPorts) cannot be responsible for all possible exploits.
> That simply isn't feasible.

I never said it was. That doesn't mean they shouldn't try to handle
the exploits that are within their reach.

>> A leaked robo-key can always be revoked and nothing in effective
>> security is ever ideal.
>
> And a generated keypair with the private key discarded and
> the public key registered with time stamp differs ... how?

Why should I trust a single use key pair? I'd have to verify the
identify of every single key independently. Unless it is also signed
by a parent key that has greater longevity and can be individually
verified? At which point, why bother with the single use key in the
first place? You could just use the one parent key and nothing has
been lost.

>> Even PGP key signing could be improved by tracing DNA back to most
>> recent common ancestor.
>
> Improved how? [...]

It was a joke.

-- 
arno  s  hautala    /-|   arno at alum.wpi.edu

pgp b2c9d448