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

[Dzonatas Sol <[e-mail]>]

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