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

[Alexey Melnikov <[e-mail]>]

Richard L. Barnes wrote:

>Hey all,
>  
>
Hi Richard,
Thanks for the re-review and additional comments. My answers below.

>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.
>
No, it got moved to its own section "Implementation-Specific Limits" 
under the "Security Considerations"

>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".
>
I am Ok with changing MAY to 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.
>
This is an escape clause, in case we need it in the future. But this is 
not really different from what the document already allows now: 
interpetation of frame payloads in presence of extensions is up to 
extensions (modulo the framing structure).

>(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.
>
This requirement is already in the spec. In Section 5.4:

   o  An intermediary MUST NOT change the fragmentation of a message if
      any reserved bit values are used and the meaning of these values
      is not known to the intermediary.

   o  An intermediary MUST NOT change the fragmentation of any message
      in the context of a connection where extensions have been
      negotiated and the intermediary is not aware of the semantics of
      the negotiated extensions.

>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.
>
As above. I believe the current text reflects a compromise after an 
August long debate on the issue.

>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.
>
It was defined earlier in the document.

>Suggest going back to a requirement that a frame MUST contain valid UTF-8 (i.e., that it breaks at code-point boundaries).
>
I am afraid there is WG consensus on the current proposal.

>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.
>
I think it also applies to the handshake itself (in presence of possible 
extensions).

>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".
>
This section doesn't define normative behaviour

>Shouldn't it either return an HTTP error or Fail the Websocket Connection_ ?
>
Yes. Any suggestions how to make this clearer?

>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."
>
Ok, I've inserted your text into my copy of the draft.

>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.
>
Yes.

>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.
>
Ok.

>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?
>  
>
A change of the reference is probably needed. Not sure if RFC 3766 is 
suitable though, I need to reread it.