On Tue, Sep 06, 2011 at 12:56:32PM -0700, Roy T. Fielding wrote:
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.
Roy please, it's not "to bypass", it's the opposite. Using in place
proxies, URL classification, anti-virus, malware blocking, authentication
etc... is a way to *respect* organizational security. The reason why
alternative solutions do work in corporate environments precisely is
because they are compatible with deployed and well-controlled
technology. Corporate admins are much less tempted by deploying new
protocols they don't understand with new components and their bag
of authentication mechanisms etc...
Opening any port different from 80 in corporate environment generally
is a no-go. 443 is generally filtered by white lists and only accessible
to a small number of users because it's not analysable. Some products do
emit fake certificates to spoof the original site to be able to open the
stream and analyze the contents. This causes issues such as end-users not
being able to decide whether or not they accept an unknown cert.
I'm not fond either of passing everything on top of port 80. But it's
what offers the finest control everywhere. HTTP offers the user
authentication and server qualification that TCP lacks. And there are
much less risks of seeing a port being abused. Hey BTW I'm right now
responding from a location I can only escape by abusing a non-80 port...
If this place only had to deal with port 80 and normal proxies, I could
not have accessed my mail over SSH. That's why corporate admins prefer
to focus on what they can control (eg: HTTP) and not on every shiny new
protocol.
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.
There is no reason to slow those components down if there is no
traffic increase. The cost of analysing a 1MB WS message or a 1MB
HTTP response basically is the same.
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.
I don't agree with you on this point. It's not a matter of difficulty
but a matter of adoption. If you offer something that nobody deploys
because admins are reluctant, you'll still see BOSH and friends everywhere
because it will be what already works.
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.
The warning is important and I agree with you on this point.
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).
But TLS still costs more and is closed at many places (such as where I'm
right now). TLS+NPN will offer admins a greater control over what's
transiting (so that they don't have to let users SSH over their proxies)
but still it will prevent content filters from *seeing* what's exchanged.
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.
I must say it bugs me to understand how you can disagree with the
outcome of a design when you already disagree with the established
requirements. Maybe you should have fought more at the beginning
to explain why you thought those requirements were stupid and try
to ensure the WG would not start its work at all then.
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.
One point that was raised was the time to fail. It's very hard to
distinguish between a slow success and a slow failure. Also it does
not address the requirements in corporate networks concerning user
authentication, accounting, site filtering, content filtering, etc...
and in the end port 80 would still be the de-facto standard.
Regards,
Willy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf