Subject: Re: [therightkey] Will the real RPF please stand up?

From: "Kyle Hamilton" <[email-masked]>
Date: Thu, 9 Feb 2012 23:02:42 -0800 (Pacific Standard Time)

On Wed, Feb 8, 2012 at 9:06 AM, Stephen Kent <[email-masked]> wrote:
> So, I don't agree that the distinction between the user and a machine
> operated by a user is really significant, in the end.  (Yes, I am ware of
> the many security problems that arise because the user doesn't really know
> what the code is doing, but nothing is perfect.)

I believe that there's a very good reason to separate them.  We're going to need to move to a system where we have effectively a separate UID per application, within the overarching user's UID.  This is the only effective way to isolate the damage which one application can cause, and the only effective way to audit precisely which application did what damage.

This is a recasting of Android's model, where the "user ID" is "the device's controller", and the applications themselves are assigned Linux UIDs so they can't interfere with each other.

> I agree that credential portability is essential. [...]

Credential portability is overrated.  The real problem is credential equivalence.

>> S/MIME with a private key shared to fifteen devices no longer looks
>> very secure to me.

S/MIME with a private key stored on a daemon system and unique private keys on each of fourteen accessing clients, on the other hand...

> Crednetial portability does not necessarily imply a private key kept in SW
> in  every device.

Credential portability does, however, imply a private key or other authenticator must be handled in SW in every device.  Intermittent security is harder than complete security in a sufficiently complex system.

-Kyle H

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Feb 2012 18:11:58 -0500

At 11:02 PM -0800 2/9/12, Kyle Hamilton wrote:
>I believe that there's a very good reason to separate them.  We're 
>going to need to move to a system where we have effectively a 
>separate UID per application, within the overarching user's UID. 
>This is the only effective way to isolate the damage which one 
>application can cause, and the only effective way to audit precisely 
>which application did what damage.

I appreciate the potential benefit for per-app IDs vs. user/machine 
IDs, but given the sorry state of OS secruity, it's not clear that a 
per-app ID is really meaningful.

>This is a recasting of Android's model, where the "user ID" is "the 
>device's controller", and the applications themselves are assigned 
>Linux UIDs so they can't interfere with each other.
>

PHB pointed out why credential portability is critical for encrypted 
e-mail. For many other apps, it is not so critical. I am not sure 
that equivalence is a good alternative, as mapping among multiple 
credentials creates an opportunity for additional secruity problems.

>S/MIME with a private key stored on a daemon system and unique 
>private keys on each of fourteen accessing clients, on the other 
>hand...

is not e-2-e secure and this less desirable.

>Credential portability does, however, imply a private key or other 
>authenticator must be handled in SW in every device.  Intermittent 
>security is harder than complete security in a sufficiently complex 
>system.

not true. many folks carry devices that could be used to store 
private keys that are used briefly, to unwrap keys.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Feb 2012 18:29:38 -0500

Credential equivalence is not for every application. In particular
there are cases where you want a user to have exactly one physical
credential and that is a part of the security scheme.

But I still think that the rule of 'private keys never move outside
the device once they are in' is a good one and one we could stick
to.There are some use cases for which generating the keys on the
device is not practical but I still think a different key per device
and no movement of the key from one device to another is a good plan.

So in this approach Alice would have

Alice S/MIME private key corresponding to public key in cert (located at server)

Alice 1 (desktop)
Alice 2 (cell phone)
...
Alice n (whatev)

If Alice is going to read an encrypted email on a given device it asks
the server to decrypt the session key and reencrypt it under the
device key.

Now people can say this is not true end to end, but have we really
increased the number of possible points of vulnerability? So the
server can be compromised, but so what? The endpoint can be
compromised much more easily.

On Thu, Feb 16, 2012 at 6:11 PM, Stephen Kent <[email-masked]> wrote:
>> I believe that there's a very good reason to separate them.  We're going
>> to need to move to a system where we have effectively a separate UID per
>> application, within the overarching user's UID. This is the only effective
>> way to isolate the damage which one application can cause, and the only
>> effective way to audit precisely which application did what damage.
>
>
> I appreciate the potential benefit for per-app IDs vs. user/machine IDs, but
> given the sorry state of OS secruity, it's not clear that a per-app ID is
> really meaningful.
>
>
>> device's controller", and the applications themselves are assigned Linux
>> UIDs so they can't interfere with each other.
>>
> PHB pointed out why credential portability is critical for encrypted e-mail.
> For many other apps, it is not so critical. I am not sure that equivalence
> is a good alternative, as mapping among multiple credentials creates an
> opportunity for additional secruity problems.
>
>
>>
>> S/MIME with a private key stored on a daemon system and unique private
>> keys on each of fourteen accessing clients, on the other hand...
>
>
>> authenticator must be handled in SW in every device.  Intermittent security
>> is harder than complete security in a sufficiently complex system.
>
>
> not true. many folks carry devices that could be used to store private keys
> that are used briefly, to unwrap keys.
>
> Steve

-- 
Website: http://hallambaker.com/