Re: [hybi] On TLS-only Approaches

["Shelby Moore" <[e-mail]>]

>
> On 23/08/2010, at 2:03 PM, Maciej Stachowiak wrote:
>>
>> Do we have any past success stories along these lines? i.e. a new
>> protocol using a new port is developed, clients and servers start using
>> it despite the high rate of failure, and subsequently administrators
>> change their firewalls so that it commonly works.
>
> HTTP
> SIP
> ssh
> various forms of VPNs
>
> See also the contents of /etc/services on most Unix-like systems.


I read in this thread mostly bottom-up arguments about technology and very
little top-down game theory about what really matters.

Ultimately, success of anything depends on whether people need it, crave
it, want it, drool over it, and if there exists no other readily available
alternative which has less inertia against it.

We geeks need to remember that ultimately it is not about web services
developers, nor principles of technological perfection, it is about end
users:

http://www.ietf.org/mail-archive/web/hybi/current/msg03548.html

Tangential to my point above, if we want to enable the killer-application,
why are we refusing to enable 99% of the internet to use WebSockets:

http://www.ietf.org/mail-archive/web/hybi/current/msg03549.html

<truth-rant>And I am talking about the permutations of interconnections
that exist now, but are being wasted by we geeks who think we know
better.</truth-rant>

I see no reason that we can not support WebSockets over HTTP, HTTPS (TLS),
and also have a new port for WebSockets.

Why should we pick the winners and losers?  Let the market place decide. 
The more options we offer the market place, then the better chance we have
that our orthogonal effort on the WebSocket frames won't be wasted (i.e.
not maximized).



>
>
>> OK, let's try a game theoretic model. Here are some assumptions about
>> the three players:
>>
>> => The goal for browser vendors (Player B) is to provide features that
>> Web services developers want to use.
>>   => Corollary: Browser vendors are unlikely to ship features that
>> cannot or will not be used by Web service providers.
>>
>> => The goal for those deploying Web services (Player S) is to provide
>> the benefit to their users - preferably greater benefit to a greater
>> number of users.
>>   => Corollary: Deployers of Web services are often unwilling to use any
>> feature that lacks very wide reach to their audience, or is otherwise
>> unreliable.
>>
>> => The goal for network administrators (Player N) is to protect their
>> organization from unknown threats while at the same time enabling their
>> users to access sufficiently important services.
>>   => Corollary: Most network administrators will not allow access to
>> additional services
>>
>> Player B to move first. Player S to move second. I claim the optimal
>> move is to enable deployment over existing unblocked ports (which in
>> practice means 80 or 443). Can you give a game theoretic argument for
>> why "use a new port" is a better move? I think you have shown that it
>> might not be a complete failure, but I don't see how it improves
>> outcomes for Player S or Player B. It may be worse for Player N, but
>> it's not his move. With high probability, he won't respond with "block
>> all port 443 traffic".
>
>
> Why do you need to use TLS over port 443, if this is just about making the
> protocol more widely adoptable?
>
> Also, if it's as bleak as you paint it, how do you expect *any* of the new
> HTML5 features to get adoption? Never mind the network administrators --
> if "those deploying Web services" are so conservative, why would they use
> the video tag, etc?
>
> The answer to that (mostly) rhetorical question is the same as it is here;
> it's a gradual process; some Web sites will be more on the bleeding edge
> and either a) require their users to use relatively new browsers / "open"
> networks, or b) undertake fallback strategies for old browsers / closed
> ports. More conservative sites will follow later.
>
> AIUI in the various tests that have been undertaken, more than half of
> browsers *can* access services on new ports. Compared to deployed support
> for, say, the video tag, that's a great starting point.
>
> Finally, network administrators won't (often) block all port 443 traffic,
> but using it like this will encourage a market for devices that can
> intercept SSL/TLS. E.g.,
>   http://www.bluecoat.com/node/2644
>   https://www.microsoft.com/forefront/threat-management-gateway/en/us/features.aspx
>   http://wiki.squid-cache.org/Features/SslBump
>   http://www.collectivesoftware.com/Products/ClearTunnel
>
> Cheers,
>
> --
> Mark Nottingham     http://www.mnot.net/
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>