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

Michael D'Errico <mike-list@pobox.com> Tue, 02 February 2010 20:11 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 C19063A6B4B for <tls@core3.amsl.com>; Tue, 2 Feb 2010 12:11:11 -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 QWOisGKABEz4 for <tls@core3.amsl.com>; Tue, 2 Feb 2010 12:11:10 -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 2010F3A6B47 for <tls@ietf.org>; Tue, 2 Feb 2010 12:11:06 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 41CCB963E9 for <tls@ietf.org>; Tue, 2 Feb 2010 15:11:45 -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=McL6xGcj645B Sn2MDXrU0BDPZHU=; b=Wnk9rj/1rspsZxO2roY0GetHCFrYaobPNe6ygKv9Zkqp gib8YxvsppLrqK89VInCHhZYXGopq/Tv+mp6wcidI2ClHZrHnNkVhEXH5WVeiHeq 2TIext83Q9J5BQMRbu+OyG4BCH1jOPd8NXUDVn4ny7OgPyv0Ip17JUaRxQNFkFc=
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=eXaBRD qLewXs823pUYcqKTdkfVq2NX97VtQkcdJhP7GhvqeLUMoEWvJEnWawAVL1KDzLlQ QlIw/T4uY2Qa/hQ5B+px44cdGSixA9AwNdWzY/lTJSQ8QGPYFuabgjMFSJYzzpjz 02mdxJ8wwJEAFqMpVxrLcSFBPqhmWcClcEzzs=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 3B442963E7 for <tls@ietf.org>; Tue, 2 Feb 2010 15:11:45 -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 BDA3E963E3 for <tls@ietf.org>; Tue, 2 Feb 2010 15:11:44 -0500 (EST)
Message-ID: <4B6887D5.1030207@pobox.com>
Date: Tue, 02 Feb 2010 12:15:17 -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> <4B684A58.2010508@pobox.com> <000c01caa432$6a6d52b0$3f47f810$@org>
In-Reply-To: <000c01caa432$6a6d52b0$3f47f810$@org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 2F978FAE-1037-11DF-A64C-6AF7ED7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Subject: [TLS] TLS Performance (was Re: 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 20:11:12 -0000

Brian Smith wrote:
> Michael D'Errico wrote:
>> 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.) 

I'm only in control of one side of the TLS connection in the numbers I
presented, so some of the delay can be attributed to the client software.

I just did some tests on my MacBookPro to eliminate the uncertainty of
the client software and the network latency factor.  Here are the times
to establish a full handshake for a few cipher suites:

     003D - RSA (1024) AES-256 SHA-256 + session ticket:            10 ms
     003D - RSA (1024) AES-256 SHA-256 (normal session):           8.5 ms

     006B - DHE_RSA (1024/1024) AES-256 SHA-256 + session ticket:   72 ms
     006B - DHE_RSA (1024/1024) AES-256 SHA-256:                    71 ms

     006A - DHE_DSS (1024/1024) AES-256 SHA-256 + session ticket:   72 ms
     006A - DHE_DSS (1024/1024) AES-256 SHA-256:                    71 ms

when the DH parameters are 1536-bit:

     006B - DHE_RSA (1536/1024) AES-256 SHA-256 + session ticket:  202 ms
     006B - DHE_RSA (1536/1024) AES-256 SHA-256:                   201 ms

So you can see that forward secrecy costs a lot in terms of latency, even
for a fast processor.

The timing for session resumption is independent of the key exchange
mechanism:

     AES-256 SHA-256 + session ticket:        4.2 ms
     AES-256 SHA-256:                         1.2 ms

Here you can see that server-side session caches are considerably faster
than session ticket resumption (at least in my code).

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

What you are trying to do is not bad, but it doesn't seem to fit well
with the existing TLS protocol.  It seems like you want the client to
send a "packet" to the server, which simultaneously authenticates the
server, establishes the keys, and delivers a payload.  I'm not sure
that trying to twist TLS into this shape is the correct approach.

Mike