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

"Brian Smith" <brian@briansmith.org> Tue, 02 February 2010 18:05 UTC

Return-Path: <brian@briansmith.org>
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 D1D4A28C101 for <tls@core3.amsl.com>; Tue, 2 Feb 2010 10:05:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
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 UOIfLOMFSAAa for <tls@core3.amsl.com>; Tue, 2 Feb 2010 10:05:38 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 0ABB73A6975 for <tls@ietf.org>; Tue, 2 Feb 2010 10:05:37 -0800 (PST)
Received: from T60 (unknown [70.245.64.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E33E6509DE; Tue, 2 Feb 2010 13:06:15 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Michael D'Errico'" <mike-list@pobox.com>
References: <001901caa3e4$c0363750$40a2a5f0$@org> <a84d7bc61002020545n4a29f141na182b463d1de7ece@mail.gmail.com> <4B684A58.2010508@pobox.com>
In-Reply-To: <4B684A58.2010508@pobox.com>
Date: Tue, 2 Feb 2010 12:06:16 -0600
Message-ID: <000c01caa432$6a6d52b0$3f47f810$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: en-us
Thread-Index: AcqkH0+b1J8FlI1zQ++3BbK2RgitDwAEKTbQ
Cc: tls@ietf.org
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 18:05:38 -0000

Michael D'Errico wrote:
> Adam Langley wrote:
> > 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.

Half a second is not an acceptable latency for many applications, especially
over GPRS (even "3G"/"4G") connections. I developed my own HTTP+TLS stack
for a mobile app just to reduce the latency to acceptable levels. Plus,
ephemeral key exchange can add noticeable latency when the client's
processor is weak--which again is the case especially for mobile apps. (The
OS's TLS stack didn't provide adequate control over the session cache,
didn't support compression, and didn't support session tickets.) 

Latency concerns seem to be a strong motivation for people to develop new
protocols less secure than TLS like OAuth, and to choose non-ephemeral
key-exchange over ephemeral key exchange. A safe zero-roundtrip
handshake--even just for resumption--would make TLS practical for many more
applications and would reduce pressure for apps to provide the user a switch
to "turn off security" as many mobile apps are doing. If Adam or anybody
else has already tried to work out a mechanism for that, I'd love to hear
about it.

Cheers,
Brian