Re: Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

[Greg Wilkins <[e-mail]>]

For the benefit of the wider [e-mail] audience, I'd like to
summaries an unresolved issue from the Hybi WG with the websocket
draft protocol.

Draft 10 if this document contains the "deflate-stream" extension in
section 9.2.1

This extension does not comply with any of the anticipated uses of
extensions listed in section 4.8, at best this makes it a poor
exemplar of an extension, as worst it makes it an unexpected total
change to the framing seen on the wire.

Because the extension changes the framing of bytes on the wire, this
will force all tools and intermediaries that wish to observe the frame
boundaries, to implement this extension, making it non optional.  For
example, intermediaries that do not implement this extension will be
unable to buffer/forward on frame boundaries.

Because default-stream is applied after the masking of client sent
frames, it is highly inefficient, with little or no compression being
achieved due to the random masking keys and the masking of any regular
patterns in the payload.

The intent of masking was to prevent bytes sent on the wire being
being controlled by an attacker.  However, a security concern has been
raised that the predictability of the deflate algorithm to convert
byte patterns into shorter bit sequences may allow a payload to be
crafted that would predictably produce bytes on the wire regardless of
the masking applied.

A reasonable alternative has been proposed that does not apply
deflation to the stream. Rather it applies it only to the application
data before masking, while keeping the compression dictionary between
frames.   This alternative proposal is a good exemplar extension (in
line with 4.8), provides efficient compression and does not suffer
from the security concern raised.

Since draft -7, there have been many voices in the WG calling for the
withdrawal of deflate-stream and nobody has spoken in favour of the
retention of deflate-stream on any grounds other than it is already
implemented/deployed.

I fail to understand why a non essential feature that was put into
draft-3 without  discussion or consensus, that has demonstrable
deficiencies, security concerns and vocal opponents has been left in
the draft all the way to final call?


regards

Greg Wilkins