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

Martin Rex <mrex@sap.com> Fri, 04 June 2010 15:37 UTC

Return-Path: <mrex@sap.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 47CB03A67BD for <tls@core3.amsl.com>; Fri, 4 Jun 2010 08:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.539
X-Spam-Level:
X-Spam-Status: No, score=-7.539 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 CIrgpQFcmZTM for <tls@core3.amsl.com>; Fri, 4 Jun 2010 08:37:53 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 631323A67DA for <tls@ietf.org>; Fri, 4 Jun 2010 08:37:52 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o54FbU3p022296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jun 2010 17:37:35 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006041537.o54FbT23020988@fs4113.wdf.sap.corp>
To: brian@briansmith.org (Brian Smith)
Date: Fri, 4 Jun 2010 17:37:29 +0200 (MEST)
In-Reply-To: <007601cb03f2$209c8a50$61d59ef0$@briansmith.org> from "Brian Smith" at Jun 4, 10 09:27:51 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
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
Reply-To: mrex@sap.com
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 15:37:55 -0000

Brian Smith wrote:
> 
> 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. 

What exactly do you mean by "read as much input as is available".

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

The underlying operating system is not allowed to coalesce across a
TCP Push boundary.  Your server would have to blindly iterate recv()
on an non-blocking socket until EWOULDBLOCK in order to "accidentally"
run on the app data.  But reading until EWOULDBLOCK is not reliable
in reading all the expected handshake data (which may be fragmented).


The existing proposal does neither require nor suggest the client to
coalesce the final client handshake messages (ChangeCipherSpec&Finished)
into a single TCP segment along with the initial TLS application data
record, and I think it would be a bad idea to make such a suggestion.

The currently stated purpose is solely to cut down on the number of
network round trips before the first TLS record with application
data can be sent from client to server.  That still works even when
sending the final handshake messages and the initial data records
in seperate TCP segments with a PSH flag on the segment with the
handshake messages.

 

-Martin