Re: Drastically cutting primary features [was Re: Last call for public comments on Web Crypto charter]

On 11/24/2011 7:05 PM, Brian Smith wrote:
> Brian Smith wrote:
>> Mark Watson wrote:
>>> The possibility to develop secure application protocols in
>>> Javascript,
>>> without using TLS, is exactly the one of the points of this API, at
>>> least for us.
>> I do anticipate this work enabling substitutes for TLS.
> Of course, I wrote exactly the opposite of what I meant:
>
> I do NOT anticipate this work enabling substitutes for TLS.

I was hoping it was what you had previously sent ;)

Actually, it really depends on what you mean by "substitute". TLS is 
great for what it does & when used correctly makes the Internet a better 
place.

And then you have oddballs like Netflix come along saying that even a 
really fast TLS  handshake (say, 500 ms) is simply not fast enough, 
given our desire to drive content playback startup time down as much as 
we can.

There is an additional performance issue that I did not mention in my 
last email: TLS can be really taxing on your servers. Sure, you can 
throw SSL HW accelerators at the problem, but when running in the cloud, 
you may not have the ability to modify those HW accelerators, as they're 
owned by Amazon or whoever. With millions of active users, a server 
misconfig on the part of the cloud provider can mean cache thrashing, 
where SSL session keys are evicted and your sub-second playback start 
becomes a couple of seconds or more, assuming that SSL session 
resumption was even an option in the first place.

We've been using our own lightweight security wrapper for our own 
protocol for 4 years now. It's been working really well. We use tokens 
containing session keys (HMAC & encryption keys) encrypted with a 
symmetric key known only to the server (a little like Kerberos) so each 
transaction requires a single round trip and two messages (a request & 
response) unlike the two round trips & 9 messages sent for a regular (no 
client auth) SSL handshake just to open the socket before I send a 
single byte of application data over HTTP(S) or otherwise.

We like what we've got and would love to replicate that world in 
Javascript in a standard way. BTW, we have already ported our protocol 
over to JS, but there is one piece that we need proprietary WebKit 
extensions for. You can probably guess what the extensions are ;)

Mitch

>
>> I wouldn't be surprised if some uses of key material and/or
>> transmissions of key material were specifically restricted to
>> authenticated and encrypted (i.e. TLS) connections by implementations.
>> The key material is going to be traceable to the user's identity so it
>> will likely have to be protected to the same extent as the user's
>> identity is.
>>
>> Browser makers seem keen to prevent any new mixed content scenerios.
>> AFAICT, that means that the browser has to understand at least some of
>> the security properties of the transport security protocol used, to
>> ensure that transport security protocol has the same/similar
>> properties that TLS has. The easiest way to do that would be to just
>> have all applications use TLS. If TLS isn't appropriate for some
>> applications like streaming video, then we should have a (separate?)
>> discussion of how that is going to work.
>>
>> - Brian
>

Received on Friday, 25 November 2011 13:11:28 UTC