Re: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt

"Brian Smith" <brian@briansmith.org> Fri, 04 June 2010 14:28 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 E47E83A699A for <tls@core3.amsl.com>; Fri, 4 Jun 2010 07:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.201
X-Spam-Level:
X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_50=0.001]
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 ZfO7lOBBRv0p for <tls@core3.amsl.com>; Fri, 4 Jun 2010 07:28:11 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id D8A913A67F0 for <tls@ietf.org>; Fri, 4 Jun 2010 07:28:10 -0700 (PDT)
Received: from T60 (unknown [70.245.69.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A3F0F509DF; Fri, 4 Jun 2010 10:27:50 -0400 (EDT)
From: "Brian Smith" <brian@briansmith.org>
To: <mrex@sap.com>, <tls@ietf.org>
References: <4C07E6F8.2090102@pobox.com> from "Michael D'Errico" at Jun 3, 10 10:31:36 am <201006041328.o54DSOc2011772@fs4113.wdf.sap.corp>
In-Reply-To: <201006041328.o54DSOc2011772@fs4113.wdf.sap.corp>
Date: Fri, 4 Jun 2010 09:27:51 -0500
Message-ID: <007601cb03f2$209c8a50$61d59ef0$@briansmith.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGEXif2Lv6KEtD2FvrcmkTQEjIgbgI7vThvAbDZ+GA=
Content-Language: en-us
Subject: Re: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt
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: Fri, 04 Jun 2010 14:28:14 -0000

Martin Rex wrote:
> When TCP is used as the transport, I assume that sending the
> ChangeCipherSpec&Finished handshake message in a TCP segment seperate
> from the successor TLS application data record ("TCP Push") likely makes
TLS
> False Start clients interoperate with any TLS server implementation.

My prototype server implementation does not work with this mechanism. First,
my implementation always reads as much input as is available, up to its
buffer size, so any data after the client's Finished message will be read
into the buffer. Then, it will abort the connection if it sees anything
after the Finished message--mostly because it actually reuses the receive
buffer as its send buffer. Or, in other words, my implementation is
optimized for the fact that the initial TLS handshake is half-duplex. I
would be surprised if I was the only person to implement such an
optimization. 

Trying to separate the packets will do any good, as the server operating
system is just going to coalesce them anyway before the application can
process them. And, sending separate packets would be quite a pessimization
for the GRPS clients that would benefit the most from this extension.

> TLS implementations that work similar to OpenSSL, reading each record
> individually (header first, then the rest of the body) probably don't care
at all
> about network-level segments.

I think most implementations work similarly to OpenSSL in that respect,
especially if they support renegotiation; in renegotiation you can have
application data interleaved with the handshake messages so optimizations
like the ones described above do not work. Most implementations seem to use
the same logic for initial and renegotiated handshakes whenever possible.

Regards,
Brian