Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted

Michael D'Errico <mike-list@pobox.com> Tue, 02 February 2010 15:48 UTC

Return-Path: <mike-list@pobox.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 8B8213A6B30 for <tls@core3.amsl.com>; Tue, 2 Feb 2010 07:48:48 -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=[AWL=0.000, 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 hCH2WOTCA-MH for <tls@core3.amsl.com>; Tue, 2 Feb 2010 07:48:47 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 960AD3A687B for <tls@ietf.org>; Tue, 2 Feb 2010 07:48:46 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8F2E39656F for <tls@ietf.org>; Tue, 2 Feb 2010 10:49:24 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=a0K9ssHozB5g gKYu93cVtOt5IDU=; b=vw/cZNih3K+0Fow4abVzZMHnwz59JSRV+4fDHAy/Ptm/ sLbvCLsIHwLCR04z8IwAYwZ09F3aO4rKuMD8LU3wYeZ1H2O+At5RvKDbzRaEiFF3 hdITnbv2QLN6cUenzzsxHLJW2xfl3x71mfRe/tCkefeYTZ+2046SHlz7bqwp5So=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Mh6wY2 edV+ICS9gOWHHXQKn2PPJqXeiAWK9LilfyPEF3WNFohzRc2QrCkGZgXsiRtXt3LC UL9BGj0ue3I25FMcctCquHimWlVVEqZOHc/YeCwgUXjq9PjLa94EPVTpJqgnmUoo SPk33dWjr1MUiubmEhCtQKkKx8st9dS+jK3Xw=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8AF7E9656E for <tls@ietf.org>; Tue, 2 Feb 2010 10:49:24 -0500 (EST)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 45F779656D for <tls@ietf.org>; Tue, 2 Feb 2010 10:49:24 -0500 (EST)
Message-ID: <4B684A58.2010508@pobox.com>
Date: Tue, 02 Feb 2010 07:52:56 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
References: <001901caa3e4$c0363750$40a2a5f0$@org> <a84d7bc61002020545n4a29f141na182b463d1de7ece@mail.gmail.com>
In-Reply-To: <a84d7bc61002020545n4a29f141na182b463d1de7ece@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 896BEB62-1012-11DF-8C3E-6AF7ED7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted
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: Tue, 02 Feb 2010 15:48:48 -0000

Adam Langley wrote:
> On Tue, Feb 2, 2010 at 3:50 AM, Brian Smith <brian@briansmith.org>; wrote:
> 
>> But, if the client already knows the certificate, then it
>> already knows the server's public key. Consequently, it is wasteful for the
>> client NOT to send the ClientKeyExchange along with the client hello.
> 
> Given a client-speaks-first protocol like HTTP (which I happen to be
> mostly concerned with), this could cut the full handshake from two to
> one round trips.
> 
> However, there's a much easier way of doing this: cut through mode. In
> this scheme the client starts sending application data records without
> waiting for the server's Finished message so long as the ciphersuite
> is sufficiently strong. Android already does this.

I'm not a cryptographer, but it seems to me that sending data over
the connection before it is validated is a very bad idea.  On my
test server, people have established connections in less than 40 ms
using a full handshake.  Most handshakes from around the world
complete in less than half a second.  Don't get too carried away
trying to optimize this, especially if you're not able to maintain
the security guarantees.

Mike