On Sep 3, 2011, at 11:51 AM, Joel Martin wrote: > You may feel that the wording of your note is not pejorative (because what you wanted to say is so much more so), but the tone and wording come across that way even if it is technically accurate. Of course it is pejorative. How can I explain this any better? The technique being used by WebSockets to bypass organizational security will cause deliberate harm to those networks which are actively monitoring standard ports for attacks of various sorts. It will also cause harm to existing HTTP services because the additional content scanning will cause all network services on those ports to be slowed. Causing harm is bad. I don't have non-pejorative words for it. The sole reason for this harm is because the individuals who organized this working group believe it is "too difficult" to introduce new Internet protocols on their own ports. The IESG may or may not wish to respect those people's desires, since they clearly are not managers of corporate networks, but I think they would at least like to warn network managers that such a thing is coming their way. That is why we have IESG notes. > Having a note in the spec that WebSocket connections over port 80 and 443 wlll have traffic patterns that are substantially different than normal HTTP patterns and how this might impact existing infrastructure is probably worthwhile but I don't think most of your note is helpful or serves much purpose (except as a passive aggressive way to express an opinion that the current WebSocket protocol is fatally flawed). > > Just one example: "convoluted and inefficient". A simple 4-byte running XOR hash is convoluted? Certainly it's slightly more complicated than raw bytes or plain text. But convoluted seems like a stretch by any measure. Inefficient? Again, it's obviously more inefficient than just passing bytes, but if you are going to do an operation to a series of bytes, it doesn't get much more efficient than XOR. And there was a fair bit of testing of the efficiency of different hashing algorithms on different platforms and this current algorithm was deemed not overly inefficient (if you disagree, please provide data). I am a server developer. Yes, it is obviously more inefficient to change every byte, just as it is obviously convoluted to exchange a true random hash key as part of the connection set-up. Using TLS all the time would have been just as complex but far less convoluted (TLS is well-tested, deployed, and frequently implemented in hardware). And let's not forget that the initial setup exchange itself (Upgrade) is also required for the sole purpose of doing this over ports 80/443. All of it, BTW, just to invoke a generic framing session that handles some of TCP over TCP (without adding anything interesting by default, like a MUX layer). > So I think your real objection is that the current WebSocket protocol is more complicated and more inefficient than if WebSockets used a new set of well defined ports (without the ability to pick other ports, or with 80 and 443 explicitly disallowed or the same problem crops up again) and was able to safely send data without hashing. In which case I think your real disagreement is not with the outcome of the working group but with requirement #7 (#6 in the original) of the WebSocket requirements document: http://tools.ietf.org/html/draft-ietf-hybi-websocket-requirements-02. My disagreement is with the content of a proposed standard. I don't care what the WG thinks its requirements are, nor how it has made decisions on the basis of those requirements. As I said before, I found it useless to participate within the WG under those conditions because they were deliberately designed to fail. So, I stopped participating. That does not mean the WG deliverables are not subject to last call review. > Personally, I think the ability to use port 80 and 443 for WebSockets is valuable and worthwhile and I agree with the requirement. But those ports are not mandatory (just defaults) and if it turns out that this is a mistake then it really isn't that difficult for web servers to deny WebSocket handshakes on port 80,443 and force WebSocket services to use other ports. It would also be simple to update the spec in the future and make client-to-server masking optional for ports that are not 80/443. I think the note should reflect what has been specified, not what might be specified at some point in the future. Yes, if the protocol had been specified as "try this new port first and only fall back to 80/443 as a last resort" then I would have more sympathy to the way it has been designed. There are many examples of doing that in practice, though none of them are called standards. However, that is not what is specified, that is not what browsers are implementing, and that is not what network managers will soon see on their monitors. ....Roy _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf