Re: [TLS] Next protocol negotiation

Adam Langley <agl@google.com> Thu, 21 January 2010 19:40 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 3497228B23E for <tls@core3.amsl.com>; Thu, 21 Jan 2010 11:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.81
X-Spam-Level:
X-Spam-Status: No, score=-105.81 tagged_above=-999 required=5 tests=[AWL=0.167, 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 1Ef3xsCFB7mK for <tls@core3.amsl.com>; Thu, 21 Jan 2010 11:40:26 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 769273A6905 for <tls@ietf.org>; Thu, 21 Jan 2010 11:40:24 -0800 (PST)
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o0LJeH4J002199 for <tls@ietf.org>; Thu, 21 Jan 2010 19:40:17 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1264102819; bh=OGeraRRzRCwrkjJf9kiRruH2JPc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=jdxfc1P75ZBt6G/YO82ucFi8++kPQ1GQDgYOE1/RuZe7SbKG2IYxErzDb0IGGZKlZ WBkXs4mOiygToCUH6qACw==
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:content-transfer-encoding:x-system-of-record; b=dMnUGpxqL0wrILe8Z+mPDbBReI3K/HvQFUqhTwaeFFFCeHXRKBTG0D6t7ekOqQUw1 04PhgEuNISv05dva4O1WQ==
Received: from pwi4 (pwi4.prod.google.com [10.241.219.4]) by wpaz5.hot.corp.google.com with ESMTP id o0LJdGq0031310 for <tls@ietf.org>; Thu, 21 Jan 2010 11:40:16 -0800
Received: by pwi4 with SMTP id 4so427792pwi.32 for <tls@ietf.org>; Thu, 21 Jan 2010 11:40:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.59.19 with SMTP id h19mr1276870wfa.243.1264102815351; Thu, 21 Jan 2010 11:40:15 -0800 (PST)
In-Reply-To: <Pine.LNX.4.44.1001211402310.531-100000@citation2.av8.net>
References: <a84d7bc61001200757p30ffded4y8b0f34b157fa4dc4@mail.gmail.com> <Pine.LNX.4.44.1001211402310.531-100000@citation2.av8.net>
Date: Thu, 21 Jan 2010 11:40:15 -0800
Message-ID: <a84d7bc61001211140r24388501l644b47cb4868cae0@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Dean Anderson <dean@av8.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Thu, 21 Jan 2010 19:40:27 -0000

On Thu, Jan 21, 2010 at 11:22 AM, Dean Anderson <dean@av8.com>; wrote:
> 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.

I believe the point about named virtual hosting to be incorrect. I
don't know of any cases where SNI doesn't solve this.

(The level of support for SNI in the browser fleet isn't good. I have
numbers from our HTTPS servers but I've never asked to clear them for
public release. However, for new protocols this isn't an issue since
we require SNI support from our clients from the outset.)

I also don't feel that the computational overhead of encryption + MAC
is significant. You're welcome to look at
http://bench.cr.yp.to/results-stream.html for the numbers, but it ends
up being a judgement call in the end. Either way, wherever you fall on
the line, it becomes less of an issue each year.

The latency impact of TLS, of course, is significant and we're working
on more aspects of TLS than just this draft to reduce this.

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

You're welcome to consider the draft on its merits irrespective of
this argument. I think it still stands.


Cheers

AGL