Re: [hybi] CML (really the role of intermediaries)

["Shelby Moore" <[e-mail]>]

> On Mon, Aug 23, 2010 at 11:54 AM, Shelby Moore <[e-mail]>
> wrote:
>
>> 1) What you do inside your LAN is your own business, but there is no
>> justification for forcing that on the standard that is used every where
>> outside your LAN.
>>
>
> I thought you were the one arguing that non-TLS should be an option as
> well?

Correct I am. I have not changed.  We should support both HTTP and TLS.

Tangentially, I am also still praying to geek god of divine intervention,
that somehow this list will see the wisdom of WebSockets over any other
port with recommended STUN tunneling to get through roughly 65% of the
NATs (roughly same success as for HTTP, with both to rise in success as
they gain support and use).  It might just gain momentum and make us all
super proud of our dramatic effect on the world.

>  So why are you objecting to the connection between the frontend and
> backend
> not being in TLS?

I am not objecting technically.  You can do what you want.  Just don't
force a CML bit to accomplish it.

I am only objecting that if I was a user of your services and if you are
going to promise to secure my data and you don't keep it encrypted, then I
am going to call your company a liar, because no company can be sure a
hacker won't get inside.  Google in China is an example.  But I am not
being too hard on you for that, because none of us are employing
end-to-end security yet.  I wish we would.  There are many barriers, such
as the operating systems, etc.  Unfortunately everyone thinks the firewall
is security.  But any way, that is not worth debating here.  Lets stay on
the technical debate about conflation.

See below...


>> 2) I happen to expect you to keep my data encrypted always, even when
>> you
>> store it.  I know computers are perfected yet in that regard, but they
>> need to be:
>>
>
> This isn't about storing it - it is about layering software.  I receive a
> frame that is encapsulated in TLS -- I remove the TLS wrapping (ie,
> decrypt
> it), and pass it to the next layer.  If that next layer happens to be on a
> different machine in a cluster, I don't see why I should have to
> re-encrypt
> it to send it there rather than if that next layer happens to be on the
> same
> machine.


Same reply as above.


>> But regardless of whether the user's expectation of security with TLS is
>> met by your company, nevertheless, TLS is not a routing protocol that we
>> need to conflate into our framing header for WebSockets.  TLS is a way
>> to
>> achieve encryption.  If your particular implementation needs to signal
>> something, then signal it on top of the base protocol, not force the
>> entire world to carry your reserved bit around as unused payload.
>>
>
> I am really at a loss to understand what you are arguing at this point.
> You
> seem to be arguing about a CML bit while discussing TLS, and they aren't
> related in the slightest

I had originally replied to Patrick McManus, who was replying to John
Tamplin, who was arguing that we needed the CML bit in order to inplement
the TLS issue we are debating now:

http://www.ietf.org/mail-archive/web/hybi/current/msg03553.html
http://www.ietf.org/mail-archive/web/hybi/current/msg03530.html

Or was I mistaken about what they were arguing for?