Re: [TLS] Next protocol negotiation

Dean Anderson <> Thu, 21 January 2010 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F40373A6A29 for <>; Thu, 21 Jan 2010 11:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id emoupObAxR12 for <>; Thu, 21 Jan 2010 11:23:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5987C28B23E for <>; Thu, 21 Jan 2010 11:23:15 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.12.11/8.12.11) with ESMTP id o0LJMkIE026635 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 21 Jan 2010 14:22:46 -0500
Date: Thu, 21 Jan 2010 14:22:45 -0500
From: Dean Anderson <>
To: Adam Langley <>
In-Reply-To: <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: Re: [TLS] Next protocol negotiation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jan 2010 19:23:17 -0000


You do realize that using TLS as a base protocol requirement increases
the computational and operational costs, prohibits http named virtual
hosts, and probably other things.  Whatever you save in the first trip
is burned in the encryption/decryption later.  I think the goal of
improving connection negotiation speed is good in general, but I don't
think that using TLS is going to help other protocols connect faster.  
TLS has its own issues connecting fast (better than it was, but security
is more important---connection speed would be sacrificed for security at
the TLS layer).  And then you still have to negotiate the application
protocol, anyway.  If the application layer is progressive and slow, TLS
isn't going to change that.

Second, I don't think protocols should be designed with too much
emphasis on existing middleware boxes. These boxes will change as their
users' needs change.  As was noted, the goals of these boses are not
inherently evil, but are a tradeoff with the goals of protocol design,
and particularly fast negotiation and other needs the protocol probably
can't anticipate (this is layering, and is 'good'). A metaphor that
comes to mind is the tradeoff made at the airport between fast boarding
and security screening.  One designs aircraft and aircraft boarding
areas with one primary goal. But terminals one must accomodate the other
goals, (eg. security, parking, ground transportation, etc) too.

Third, my initial impression of the CONNECT scenario reminds me of the
old VTAM and 3270 terminals connecting to applications.  Perhaps we
should keep looking...or maybe we should reconsider VTAM or APPC... ;-)


On Wed, 20 Jan 2010, Adam Langley wrote:

> On Wed, Jan 20, 2010 at 7:39 AM, Nikos Mavrogiannopoulos
> <> wrote:
> > Ok now I see your point. However I still suggest solving issues at the
> > appropriate layer, even that has some performance cost.
> The appropriate layer for protocol disambiguation is TCP.
> Unfortunately, this mechanism has stopped functioning for practical
> purposes and we're aware that we aren't the only group facing this
> problem.
> Burning an additional round trip on protocol discovery is unacceptable
> for us[1]. 200ms is a good round-trip time on a 3G network and the
> nature of web content means that progressive discovery of additional
> resources amplifies this delay.
> Also, consider that without a suitable mechanism, we might be
> condemning future protocols to forever limiting their initial
> handshake to something that is HTTP compatible. We (Google) don't mind
> putting in the work to make more fundamental changes but others,
> perhaps, would choose not to for reasons of expediency, and would pay
> this technical debt forever more.
> [1]
> _______________________________________________
> TLS mailing list

Av8 Internet   Prepared to pay a premium for better service?         faster, more reliable, better service
617 256 5494