Re: [TLS] Request for review: Next Protocol Negotiation Extension

Marsh Ray <marsh@extendedsubset.com> Mon, 16 August 2010 19:24 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDEFD3A6A21 for <tls@core3.amsl.com>; Mon, 16 Aug 2010 12:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.696
X-Spam-Level:
X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001]
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 KYerMaN+eVev for <tls@core3.amsl.com>; Mon, 16 Aug 2010 12:24:45 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id E15893A69EA for <tls@ietf.org>; Mon, 16 Aug 2010 12:24:44 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1Ol5JA-000J71-I4; Mon, 16 Aug 2010 19:25:20 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E515D6095; Mon, 16 Aug 2010 19:25:17 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18LSs5czHmVDo3T2AG3KxaIq04HOcgDIWE=
Message-ID: <4C69909D.1060200@extendedsubset.com>
Date: Mon, 16 Aug 2010 14:25:17 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6
MIME-Version: 1.0
To: Adam Langley <agl@google.com>
References: <AANLkTi=5H_0hGzxMmfNU0hLS=5psW6J3c2to756OT--7@mail.gmail.com> <4C6978A3.1070404@pobox.com> <AANLkTinzpLgX7Y6eVFothtG2uuZTd207y5JiQn_nkbtg@mail.gmail.com>
In-Reply-To: <AANLkTinzpLgX7Y6eVFothtG2uuZTd207y5JiQn_nkbtg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Request for review: Next Protocol Negotiation Extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Aug 2010 19:24:46 -0000

On 08/16/2010 01:02 PM, Adam Langley wrote:
> But this draft was partly born as a result
> of the decay of the end-of-end principal which has rendered TCP port
> numbers an ineffective solution. Thus this draft made efforts to be
> more future-proof.

I am concerned by this proposal. Not that it's technically bad somehow 
but that it seems to be screaming and shaking its fist at the law of 
unintended consequences.

So let me just put these ideas out for discussion:

1. There are already plenty of options available ("VPNs") for tunneling 
arbitrary ports, IPs, even whole netblocks, through TLS or SSH. Perhaps 
these are too heavyweight of a solution in some cases, but nevertheless 
they are commonly used so we know they are options if the demand is great.

2. We already have a decent mechanism for supporting multiple protocols 
on a single IP address, even with TLS. It's "port numbers" doing exactly 
what they were designed to do.

The reason that "different application layer protocols are increasingly 
being carried over TLS using a small set of TCP port numbers, most often 
port 443" is due to the conscious decision of administrators and how 
they choose to configure their firewalls. They really do want to block 
all those other protocols! Today they can do so by selectively blocking, 
intercepting, and/or monitoring the ports they are assigned to.

But a lot of the stuff (standardized or not) running over 443 today is 
doing so just to get around the firewall! This degrades the ability of 
the admin to manage his network.

This is in fact a problem, not a feature that should be officially 
blessed with standardization in the form of a TLS extension.

If network admins are no longer able to effectively manage their traffic 
because it's all being tunneled through TLS on port 443, let's try to 
predict what the effect will be: Of course admins will continue to 
require the ability of the firewall to manage protocols, so they will 
have to inspect deeply the contents of port 443 traffic. This means 
clients will be forced to install trusted root CA certs from the 
inspecting firewall in order to make outbound connections. Of course 
these certs will remain trusted for connections from other networks as 
well. It means these CA private keys are not managed by audited 
processes in vaults underground, they get stored and used on 
internet-facing boxes where they are vulnerable to "unauthorized use". 
We all know they'll eventually be sold on Ebay without an effective 
revocation process. Of course, these root certs will be "automatically 
deployed", meaning browser users will be trained to accept new CA certs 
from time to time (yes, a hotel gave me a bogus cert for an unrelated 
website just a few days ago).

What if SMTP is standardized over this mechanism? What will ISPs which 
now block port 25 do to limit spam? Is this facility only appropriate 
for protocols which should not need blocking? Will those decisions be 
haphazardly decided?

Technical benefits aside, I believe that to the extent this proposal 
replaces the established port assignment mechanism it undermines some 
long established "interface contracts" of the net's design. If the goal 
is to some degree to usurp the admin's ability to control his traffic, 
the result will probably benefit no one.

As you guys know, I'm happy to be convinced, but think it could be a 
potentially significant change to some fundamental stuff which deserves 
due consideration.

- Marsh