Re: [vwrap] "Trust Domains", conditioners and refineries

[Dzonatas Sol <[e-mail]>]

I almost forgot I did provide a way for "trust" to be actual trust and 
not some exploitable digital copy or exploitable encryption. The ability 
takes advantage of ray-casters/ray-tracers to view analog based virtual 
worlds, yet I purposely haven't gone in much detail other than to note 
flow and support here:

http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Interface

At this time, LL has made no comment or proposed fix for few very 
exploitable client/server implementations other than "trust" in 
firewalls. I'll avoid details and assume a few others on the list are aware.

That's where I last left off... so not much has change (in icesphere and 
here) since then. (Oh yeah, I posted exemplified advanced 12D simulation 
with quantum computers at tiny and macro scale, which went over people's 
heads... "spoke too soon").

Dzonatas Sol wrote:
> That still is some debate over mechanisms that only serve as an 
> example or use-case, not further topology of such network, capability, 
> and content path.
>
> We could argue such straw men, yet I'm not in the mood. Anyways... can 
> we stay on track of terminology and asset services. Thanks.
>
> Morgaine wrote:
>> On Fri, Apr 1, 2011 at 6:20 PM, Dzonatas Sol <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>     I guess your reply is purely April 1st themed, as there are surely
>>     protocols in use now on the Internet, yet you make it sound like
>>     nobody trusts the Internet...
>>
>>
>> A lot of people trust the Internet at face value.  Our innocent, 
>> well-intentioned but technically uninformed families are among them.  
>> That is why organized crime has such an easy ride online.
>>
>> In this group we are better informed than that though, and 
>> (hopefully) we understand that trust of an unknown remote 3rd party 
>> means absolutely nothing because "trust" and "unknown remote" is a 
>> contradiction in terms, even if they possess a cryptographically 
>> signed certificate.
>>
>> An X.509 credential means nothing except that the endpoint is 
>> recognizable for the session.  It says nothing about participant 
>> trust, it says nothing about information security, it does not 
>> protect against contrary intentions, and most importantly, it 
>> provides no technical mechanism for achieving the goal of "domain 
>> protection" that some people here think it supports.  Thinking that 
>> X.509 offers anything beyond network endpoint identification is a 
>> misunderstanding of the technology and of security.  It is not a 
>> wall.  It is just a lock on the wall, and everything beyond the lock 
>> is unsecured.
>>
>> And it gets even worse than that.  I have had the misfortune of being 
>> assigned the duty of interfacing with a leading certificate provider 
>> over several years, and can attest that certificates are granted 
>> without any kind of strong care and assurance.  The process is 
>> effectively non-scalable, because as the population of certificate 
>> holders increases, the controls become ever less strong, and the 
>> meaning of holding a certificate reduces to virtually nothing.  It 
>> certainly affords no trust.
>>
>> Having faith in empty delusions is rather common in humanity, but we 
>> don't need to enshrine them in an IETF protocol.  We already have 
>> enough concrete work with goals that are verifiable on our plate.  
>> Adding unverifiable delusions to the protocol does not gain us 
>> anything beyond a warm feeling stemming from incompetence about 
>> security.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>> =========================
>>
>>
>> On Fri, Apr 1, 2011 at 6:20 PM, Dzonatas Sol <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>     I guess your reply is purely April 1st themed, as there are surely
>>     protocols in use now on the Internet, yet you make it sound like
>>     nobody trusts the Internet... again
>>
>>     Morgaine wrote:
>>
>>         I hope you realize that "trust domains" don't actually exist
>>         outside of some people's passion for buzzwords.
>>
>>         Having worked in defense security and looked beyond buzzwords
>>         into what really happens with information protection and
>>         leakage, the concept of technically-secured trust in an open
>>         client-server system lies somewhere between delusion and
>>         comedy.� No, just no.
>>
>>         Information is secure only when it is not released and not
>>         accessible.� In our VW architecture, all visible content is
>>         sent to all participants in the simulation by architectural
>>         design, and its non-distribution beyond that set of
>>         participants is not assurable.� Indeed, it is objectively
>>         impossible to assure, because there is no control over public
>>         outbound information channels in our architecture, and even
>>         less control over covert channels.
>>
>>         That makes all talk about "trust domains" here an exercise in
>>         futility, some kind of reliance on "faith" and wishful thinking.
>>
>>         The merits of comedy aside, I suggest that we stick to
>>         concepts that we can underpin with concrete technology and
>>         implement in protocols.� Trust is not one of them and just
>>         wastes time, despite the cuteness of the term "trust domain".
>>
>>         If you want to keep information secure, don't send it to
>>         somewhere that is insecure such as a remote client.� That's
>>         the technical solution, stripped of wishful thinking.
>>
>>         Whatever one may think of the defense industry, at least they
>>         analyze issues to avoid self-delusion.� We may not have a
>>         defense budget here, but that's not a reason for promoting
>>         concepts that simply don't work.
>>
>>
>>         Morgaine.
>>
>>
>>
>>
>>         ======================
>>
>>         On Fri, Apr 1, 2011 at 4:11 PM, Dzonatas Sol
>>         <[e-mail] <mailto:[e-mail]>
>>         <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>
>>            Of replies received and to forward this further, the ideal
>>         "trust
>>            domains" are established in file by X.509 (and more recent
>>         claims)
>>            or by login credentials/authentication. This flexibility of
>>         these
>>            two alone to establish such domain already defeats the
>>         purpose to
>>            use client/server terminology except at the transfer-level.
>>            Consider that LLIDL & REST is above the transfer-level (from
>>            source-level perspective), there is not much need to use
>>            client/server terminology (except if you want pedantic
>>         buzzwords).
>>
>>            Please let me know if there is some other case.
>>
>>
>>            Dzonatas Sol wrote:
>>
>>                Added "trust domains" to the subject line to hopefully
>>         narrow
>>                this thread before it goes into some random debate.
>>
>>
>>
>>
>>            --     --- https://twitter.com/Dzonatas_Sol ---
>>            Web Development, Software Engineering, Virtual Reality,
>>         Consultant
>>
>>            _______________________________________________
>>            vwrap mailing list
>>            [e-mail] <mailto:[e-mail]>
>>         <mailto:[e-mail] <mailto:[e-mail]>>
>>
>>            https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>         
>> ------------------------------------------------------------------------
>>
>>
>>
>>         _______________________________________________
>>         vwrap mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/vwrap
>>         
>>
>>
>>     --     --- https://twitter.com/Dzonatas_Sol ---
>>     Web Development, Software Engineering, Virtual Reality, Consultant
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>   
>
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant