Re: [TLS] Request for review: Next Protocol Negotiation Extension

[Michael D'Errico <[e-mail]>]

Last night at about midnight I awoke with a revelation
that this whole WebSockets protocol could be a hoax.
But assuming that it is real, here are some things that
concern me:

   - You have managed to take a binary-capable
     transport (HTTP) and turn it into a text-only
     non-binary capable transport.

   - The "framing" used to delineate messages sent
     over the protocol is sentinel-based similar to
     the C programming language string handling that
     uses NULL, but WebSockets uses 0xFF since it is
     invalid in UTF-8.  That means both the sender
     and receiver need to scan every byte of every
     message for the sentinel, which takes time and
     therefore increases latency.

   - Any text data that is in a different character
     set (e.g. ISO-8859-1) has to be converted to
     UTF-8 in order to be sent which adds latency to
     the protocol.

   - Am I missing something, or why didn't you use
     the "chunked" transfer coding of HTTP?  It gives
     you binary transfer (and therefore you can send
     UTF-8 over it too) and eliminates the need to
     inspect every byte sent and received.  If just
     the length was not enough for your framing needs,
     I'll point out that you can add chunk extensions
     and even send headers after the last chunk, all
     without changing HTTP.

   - The sentinel-based framing is a problem because
     it can be trivially broken by sending FF 00 and
     then any payload you want.  (This is why the
     sender also needs to scan all outbound traffic).

Collectively you are trying to "fix" TLS to solve your
latency problems, but as noted above you have some
things you can do to improve your own protocol first.

As they say, "get your own house in order."  Apologies
if that sounds harsh.

Mike

P.S. I hope that this is not the network protocol
version of getting rickrolled.