Re: [hybi] On TLS-only Approaches

Mark Nottingham <mnot@mnot.net> Mon, 23 August 2010 04:39 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7463A67D1 for <hybi@core3.amsl.com>; Sun, 22 Aug 2010 21:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.14
X-Spam-Level:
X-Spam-Status: No, score=-104.14 tagged_above=-999 required=5 tests=[AWL=-3.030, BAYES_05=-1.11, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkr9LmGo1-9b for <hybi@core3.amsl.com>; Sun, 22 Aug 2010 21:39:14 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 1F5AD3A697A for <hybi@ietf.org>; Sun, 22 Aug 2010 21:39:14 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown [118.209.60.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E017B509DC; Mon, 23 Aug 2010 00:39:40 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <A6CD606F-0908-415B-9589-76291C88134A@apple.com>
Date: Mon, 23 Aug 2010 14:39:37 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <EBFF1F9D-E200-47B9-A554-02AAECD9FEF7@mnot.net>
References: <AANLkTikJcbyEZ-Y0FOXni89L8Awa_UBmMMDvLgsOuoou@mail.gmail.com> <43E0DD8E-1D83-44D2-8D8B-5914A0FFFDFB@mnot.net> <A6CD606F-0908-415B-9589-76291C88134A@apple.com>
To: Maciej Stachowiak <mjs@apple.com>
X-Mailer: Apple Mail (2.1081)
Cc: Server-Initiated HTTP <hybi@ietf.org>
Subject: Re: [hybi] On TLS-only Approaches
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Aug 2010 04:39:16 -0000

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.


> 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/