Richard L. Barnes wrote:
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"
Yeah, sorry, wrote that before I got to 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.
I'm assuming from your response below that you're OK with going to MUST as well?
I don't think it makes much difference here, SHOULD is strong enough.
But I can make it a MUST if you insist.
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).
Even still, it would probably be more helpful to have individual
recommendations in the handshake and framing sections.
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?
OLD:
"
Servers that are not intended to process input from any Web page but only for certain sites SHOULD
verify the "Origin" field is an origin they expect, and should only respond with the
corresponding "Sec-WebSocket-Accept" if it is an accepted origin.
"
NEW:
"
Servers that are not intended to process input from any Web page but only for certain
sites SHOULD verify the "Origin" field is an origin they expect. If the origin
indicated is unacceptable to the server, then it SHOULD respond with an HTTP 403
Unauthorized error response and _Fail the WebSocket Connection_.
"
Thinking more about this: there is no reason to "Fail the WebSocket
Connection" (as this implies TCP connection closure), just rejecting
with 403 is sufficient. I will reword your text to say that.
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.
Suggested text:
"
Despite the protection provided by masking, non-compliant HTTP proxies will
still be vulnerable to poisoning attacks of this type by clients and servers
that do not apply masking.
"
Ok.
Note that that is not quite correct is masking is not optional for
clients, but this is still under discussion.
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.
So you're changing this to MUST?
Ok :-).
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
