Re: [TLS] Next protocol negotiation
Dean Anderson <dean@av8.com> Thu, 21 January 2010 19:23 UTC
Return-Path: <dean@av8.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 F40373A6A29 for <tls@core3.amsl.com>; Thu, 21 Jan 2010 11:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 emoupObAxR12 for <tls@core3.amsl.com>; Thu, 21 Jan 2010 11:23:15 -0800 (PST)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 5987C28B23E for <tls@ietf.org>; Thu, 21 Jan 2010 11:23:15 -0800 (PST)
Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (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 <dean@av8.com>
X-X-Sender: dean@citation2.av8.net
To: Adam Langley <agl@google.com>
In-Reply-To: <a84d7bc61001200757p30ffded4y8b0f34b157fa4dc4@mail.gmail.com>
Message-ID: <Pine.LNX.4.44.1001211402310.531-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: tls@ietf.org
Subject: Re: [TLS] Next protocol negotiation
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: Thu, 21 Jan 2010 19:23:17 -0000
Adam, 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... ;-) --Dean On Wed, 20 Jan 2010, Adam Langley wrote: > On Wed, Jan 20, 2010 at 7:39 AM, Nikos Mavrogiannopoulos > <nmav@gnutls.org> 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] http://googleblog.blogspot.com/2009/06/lets-make-web-faster.html > > > AGL > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 256 5494
- [TLS] Next protocol negotiation Adam Langley
- [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Nikos Mavrogiannopoulos
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Nikos Mavrogiannopoulos
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Marsh Ray
- Re: [TLS] Next protocol negotiation Steve Dispensa
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Marsh Ray
- Re: [TLS] Next protocol negotiation Yoav Nir
- Re: [TLS] Next protocol negotiation Yoav Nir
- Re: [TLS] Next protocol negotiation Yoav Nir
- Re: [TLS] Next protocol negotiation Marsh Ray
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Dean Anderson
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Dean Anderson
- Re: [TLS] Next protocol negotiation Adam Langley