Subject: Re: [vwrap] Conditioners and refineries

From: Dzonatas Sol <[email-masked]>
Date: Fri, 01 Apr 2011 07:48:22 -0700

Much of the discussion is actually implemented, already (somehow). What 
"you" want, however, seems to be to have some LL-employee/OpenSim-dev to 
rewrite, reauthorize, reinvent, and bloat the monolithic client or add 
redundant capabilities on the simulators as some means to state what is 
official in VWRAP. None of that needs to happen, and please don't give 
the appearance that "we" need to beg any of them for implementation 
(especially, to tally some vote). Remember that the 
user-end/front-end/graphics-client is the one doing the real work. The 
simulator still exists as a router due to legacy reasons, so there is 
really no need to rely on LL sims or Opensim to implement any of this. 
(I'm sure backwards compatible is ideal.) The only exception is "domains".

No need to leverage the weight of storage over implementation. The ideal 
word is "cohesion" of various implementations...  not rewrite. Any 
rewrite or customization of implementations in any company is that 
company's business, not ours. Your assumption of what is in our "grasp" 
is in error because you assumed it in only part of LL or such 
reverse-engineered simulator, and there is no need for this sympathy 
here unless you're tried to win points with them somehow.

Win points here... not there...

Morgaine wrote:
 > That is incorrect.  IETF drafts are not promoted to Internet 
standards unless they have implementations --- again, the Mission 
Statement is worth reading.  "*Rough consensus and running code*" is a 
cardinal principle highlighted in BCP 95.  Since we do not have the 
power to test our ideas within Second Life, but only within open source 
frameworks like Opensim, SL compatibility is beyond our reach until such 
a time as Linden Lab provides the required test implementation.  In the 
absence of that, only Opensim and/or realXtend compatibility is within 
our grasp because we can add the "running code" there ourselves.

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

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 01 Apr 2011 08:11:59 -0700

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.
>
>

--

---

From: Morgaine <[email-masked]>
Date: Fri, 1 Apr 2011 18:08:55 +0100

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 <[email-masked]> 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).
>
>> Added "trust domains" to the subject line to hopefully narrow this thread
>> before it goes into some random debate.
>>
>>
>>
>
> --
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 01 Apr 2011 10:20:16 -0700

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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).
>
>         Added "trust domains" to the subject line to hopefully narrow
>         this thread before it goes into some random debate.
>
>
>
>
>     -- 
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

--

---

From: Morgaine <[email-masked]>
Date: Fri, 1 Apr 2011 19:39:02 +0100

On Fri, Apr 1, 2011 at 6:20 PM, Dzonatas Sol <[email-masked]> wrote:

> 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 <[email-masked]> wrote:

>> I hope you realize that "trust domains" don't actually exist outside of
>> some people's passion for buzzwords.
>>
>> between delusion and comedy.� No, just no.
>>
>> Information is secure only when it is not released and not accessible.� In
>> of participants is not assurable.� Indeed, it is objectively impossible to
>> 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".
>>
>> insecure such as a remote client.� That's the technical solution, stripped
>> of wishful thinking.
>>
>> 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 <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>    --     --- https://twitter.com/Dzonatas_Sol ---

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 01 Apr 2011 17:24:57 -0700

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 <[email-masked] 
>     protocols in use now on the Internet, yet you make it sound like
>     nobody trusts the Internet...
>
>
> 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.
>
> 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 <[email-masked] 
>     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.
>
>         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.
>
>         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
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 02 Apr 2011 09:03:28 -0700

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.
>
>> 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 
>> 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.
>>

--