Re: [hybi] Websocket over TLS keep-alive overhead

[Takeshi Yoshino <[e-mail]>]

On Fri, Nov 30, 2012 at 3:42 AM, Roberto Peon <[e-mail]> wrote:

> ++
> On Nov 29, 2012 2:11 AM, "Jamie Lokier" <[e-mail]> wrote:
>
snip

>  It might make sense if TLS could transmit its own, much shorter,
>> keepalive messages, which are for the sole purpose of keeping the link
>> alive.  I would guess, since they have no other effect, that they
>> wouldn't be exploitable in the same way.  Is that right?
>>
>>
There might be some nop available at TLS level, but I'm not sure. I heard
that old attempt (0/n record splitting) to address ancestor of the BEAST
attack faced a problem that some of existing NWs can't handle empty record
correctly.

How about allowing the API to invoke TCP layer keepalive (null TCP packet)
instead of nop TLS record?

I found similar discussion in these threads for
http://tools.ietf.org/html/rfc6520.
- http://www.ietf.org/mail-archive/web/tls/current/msg07986.html
- http://www.ietf.org/mail-archive/web/tls/current/msg07987.html


>  It would be best if they could be invoked from the higher layer rather
>> than generated in TLS itself (because the higher layer will have a
>> better idea of the keepalive patterns that it needs), and if they were
>> one-way keepalives rather than PING/PONG to avoid amplification
>> attacks, and because PING/PONG is not the most efficient keepalive
>> pattern.
>>
>> Is there provision in TLS for that sort of thing now?
>>
>> (Of course over mobile links, it would make much more sense for power
>> efficiency to have a single, aggregated keepalive stream for all
>> sockets rather than one per active websocket, or some other way of
>> taking advantage of the phone's existing mobile link-level keepalives
>> which it already does and are designed for efficiency.)
>>
>>