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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf