Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4CAB06F7.60407@zeus.net.au>
Date: Tue, 05 Oct 2010 21:07:35 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Towards Internet Jini Services (trust)
References: <4C9DB5BF.8090307@zeus.net.au> <4CAAF9C6.70709@qcg.nl>
 <201010051226.52424.michal.kleczek@xpro.biz>
 <201010051249.59529.michal.kleczek@xpro.biz>
In-Reply-To: <201010051249.59529.michal.kleczek@xpro.biz>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Yes I think Sim is talking about making trust decisions and Michal and I 
are talking about the handshake, we need both, I don't think we're 
having an issue of agreement, just understanding.

I'd like to see some kind of feedback service, where you give a good 
rating when you get a good service and a bad one when you don't.  I'd 
also like to see a security advisory service, for handling discovered 
vulnerabilities.  These things might be useful in making trust decisions.

I'd also like some trust levels defined, with a wider range of 
permissions as trust increases.  But I'd only like to grant the 
intersection of the trust level Set of Permissions and the Set requested.

I'd like to see the level of trust others are granting to a service via 
feedback services, if a service misbehaves and it's caught out, the 
level of trust will diminish.

Then we can go with the crowd, safety in numbers, like a school of fish, 
just don't get caught in a bait ball.

Cheers,

Peter.

Michal Kleczek wrote:
> Of course - I am not talking about the problem of deciding whether I should 
> trust a particular service - this is a completely different subject and I am 
> not really sure if we should even try to solve it since I don't think it is 
> possible to do without human intervention. In the end - choosing to trust and 
> use gmail versus yahoo is not something that can be done automatically.
>
> But checking whether an object (code + data) comes from the service I trust is 
> something that can be done and is a prerequisite to the above anyway.
>
> Michal
>
> On Tuesday 05 of October 2010 12:26:52 Michal Kleczek wrote:
>   
>> Don't know if we agree or not :) . So to make it simple I'd say that the
>> way proxy verification is done in Jini is IMHO fine - except that it is
>> done too late (after deserialization which requires running yet untrusted
>> code). Once we have it fixed - we're basically ready for the Internet (
>> sure there other issues to solve but IMHO this is the most basic).
>>
>> Michal
>>
>> On Tuesday 05 of October 2010 12:11:18 Sim IJskes - QCG wrote:
>>     
>>> On 10/04/2010 06:43 PM, Michal Kleczek wrote:
>>>       
>>>> Let me explain my position better:
>>>>
>>>> IMHO the problem to solve is: how to securely exchange information
>>>> between two parties without trusting third parties that u use to
>>>> send/receive it?
>>>>         
>>> By using cryptography.
>>>
>>>       
>>>> Your example with JPEG is actually excellent to illustrate my point.
>>>> The only way to make sure you got your images from a trusted party is
>>>> to _always_ use TLS - no web caches/proxies or anything like that.
>>>> Once you have those - you're out in the dark.
>>>>         
>>> Even when your HTTPS session goes through a proxy, it is still
>>> end-to-end. (unless you are victim of a MITM attack).
>>>
>>>       
>>>> It is no different than exchanging objects using untrusted
>>>> ServiceRegistrars or code using untrusted code servers. It is actually
>>>> no different than downloading a web page from your bank site - the
>>>> bytes you actually download come from an untrusted router somewhere in
>>>> the net anyway.
>>>>         
>>> But the mere fact that this router is untrusted does not reduce the
>>> level of security.
>>>
>>>       
>>>> Also - relying on trusted third parties to download code gives you
>>>> false sense of security - users of Android or iPhone that download
>>>> apps from (trusted) app stores should already know that.
>>>>         
>>> I'm not sure this creates a false sense of security. I've never thought
>>> is was secure. Did you? I much rather have my third party to be open
>>> about its practices than not.
>>>
>>>       
>>>> The solution is not to reject using proxies or any third parties. It is
>>>> to 1. introduce a way for you to make sure the data you've just
>>>> downloaded comes from the right source - no matter what means you used
>>>> to download it. 2. restrict downloaded code as much as possible
>>>>         
>>> The solution that is brewing does not reject proxies or third parties.
>>> It is more about accepting them, and remembering the trust choices we
>>> have made, and means to change this trust.
>>>
>>>       
>>>> Jini is almost there - we have Java security to restrict downloaded
>>>> code and we have a way to verify if an object came from a trusted
>>>> source. The only problem is that to do that we have to run some yet
>>>> untrusted code. Let's just try to solve this problem :)
>>>>         
>>> I'm still not sure if we agree or differ in opinion. Are you?
>>>
>>> Gr. Sim
>>>       
>
>