[hybi] Review of draft-ietf-hybi-thewebsocketprotocol-13

["Richard L. Barnes" <[e-mail]>]

Hey all,

I was selected for the Gen-ART review of draft-ietf-hybi-thewebsocketprotocol, and submitted a review during IETF LC:
<>
Since it's coming up for telechat, I thought I would give it a second look.  Comments on the diff are below.

--Richard


Section 2, "Implementations MAY impose implementation-specific limits..."
This paragraph has been removed in -13.  While the "MAY" doesn't specify a requirement, it seems like it would be helpful to implementers in light of the exhaustion/DoS possibilities presented by huge frames and fragmentation.  I would even argue that it should be a "SHOULD".

Section 5.4, "Unless specified otherwise by an extension, frames have no semantic meaning."
This caveat seems to invite breakage, especially since there are no extensions defined and no examples given of what sort of semantics might be attached.  (I'm guessing this has to do with 'deflate'?)  At the very least, it seems like there should be a requirement that when an intermediary sees an extension that it doesn't understand, it MUST NOT fragment or coalesce frames.  

Section 5.4, "Implementation Note: in absence of any extension..."
Same considerations apply here.  This note seems to encourage behavior that will cause incompatibility in the future.  ISTM that explicit streaming really should be done with smaller, independent frames.

Section 5.6, "Note that a particular text frame might include a partial UTF-8 sequence, however the whole message MUST contain valid UTF-8"
This requirement is meaningless, since the concept of a "message" is not defined here.  Suggest going back to a requirement that a frame MUST contain valid UTF-8 (i.e., that it breaks at code-point boundaries).  

Section 8
Should be moved to Section 5.6.  It really only applies to text frames, and even then only if text frames are required to be UTF-8.

Section 10
In this section, and overall, it would be helpful if this document could briefly describe the browser/JS model and assign some terms that can be used consistently throughout. 

Section 10.2, "... should only respond with the corresponding "Sec-WebSocket-Accept" if it is an accepted origin. "
If I understand this correctly, the server causes the handshake to fail by omitting the "Accept".  Shouldn't it either return an HTTP error or Fail the Websocket Connection_ ?

Section 10.3, "It is necessary that the masking key is chosen randomly for each frame."
Suggested text: "Clients MUST choose a new masking key for each frame, using an algorithm that cannot be predicted by end applications that provide data.  For example, each masking could be drawn from a cryptographically strong random number generator."

Section 10.3, "It is also necessary that once the transmission of a frame from a client has begun, the payload (application supplied data) of that frame must not be capable of being modified by the application."
This seems to further argue against the idea that giant frames are useful.  They're clearly not useful for streaming (the opposite is suggested in Section 5.4, see above), since the application would have to provide all the data at once.  

Section 10.3
This section should note that even given the masking constraints in this document, proxies are still vulnerable to poisoning by non-browser clients that do not perform masking.

Section 10.4
Suggest making this a "SHOULD" or even "MUST".  If your implementation does not constrain these things, then it will be vulnerable to exhaustion attacks.

Section 10.6
[W3C.REC-wsc-ui-20100812] doesn't actually say anything substantive about how to choose ciphersuites, just that they MUST NOT be on the "export" list.  Suggest removing or replacing with a better reference, maybe RFC 3766?