IETF Logo Mail Archive

Re: [TLS] Next protocol negotiation

Adam Langley <agl@google.com> Wed, 20 January 2010 15:57 UTC

Return-Path: <agl@google.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 29A663A6A8E for <tls@core3.amsl.com>; Wed, 20 Jan 2010 07:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.477
X-Spam-Level:
X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 XCc0+RFZLl7F for <tls@core3.amsl.com>; Wed, 20 Jan 2010 07:57:39 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 29C2A3A6A61 for <tls@ietf.org>; Wed, 20 Jan 2010 07:57:39 -0800 (PST)
Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o0KFvXXC005378 for <tls@ietf.org>; Wed, 20 Jan 2010 15:57:33 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1264003053; bh=4npLwODVK01doQzthGTTV4+RSvk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=AU17wxnx4uv/ytNYMrRxjZgTZow6XciUKVn4khkyb0vUADeqFrqVzWjtjqY+P4g9F myW5XJGFFocgIRuX5zBWA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=aAW7gfvVvSPbZPq2RHGBaPFsKv7t0WqNqTj+CDcYieyXl3hPuaJ+scu6dZ76ROdCW M/xE6vczutErLzQrZo15A==
Received: from pzk34 (pzk34.prod.google.com [10.243.19.162]) by kpbe17.cbf.corp.google.com with ESMTP id o0KFvVuS008138 for <tls@ietf.org>; Wed, 20 Jan 2010 07:57:32 -0800
Received: by pzk34 with SMTP id 34so4058803pzk.11 for <tls@ietf.org>; Wed, 20 Jan 2010 07:57:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.20.39 with SMTP id x39mr94232wfi.213.1264003051425; Wed, 20 Jan 2010 07:57:31 -0800 (PST)
In-Reply-To: <4B5723A5.8050508@gnutls.org>
References: <a84d7bc61001200520t4e3be7d4sb0bb614abb0b5e4e@mail.gmail.com> <c331d99a1001200646o55d7d2f6wfaad058b84e6024e@mail.gmail.com> <a84d7bc61001200705v39b37ba3qaea1ca4149afb0a0@mail.gmail.com> <4B5723A5.8050508@gnutls.org>
Date: Wed, 20 Jan 2010 07:57:31 -0800
Message-ID: <a84d7bc61001200757p30ffded4y8b0f34b157fa4dc4@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset="UTF-8"
X-System-Of-Record: true
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: Wed, 20 Jan 2010 15:57:40 -0000

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

v2.23.0 | Report a Bug | By Email