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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
