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

Martin Rex <> Fri, 04 June 2010 13:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D52B3A6A60 for <>; Fri, 4 Jun 2010 06:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.528
X-Spam-Status: No, score=-7.528 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 53fC8cFmtCKc for <>; Fri, 4 Jun 2010 06:28:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4D9D43A6A5C for <>; Fri, 4 Jun 2010 06:28:53 -0700 (PDT)
Received: from by (26) with ESMTP id o54DSPfU028795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jun 2010 15:28:30 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Michael D'Errico)
Date: Fri, 4 Jun 2010 15:28:24 +0200 (MEST)
In-Reply-To: <> from "Michael D'Errico" at Jun 3, 10 10:31:36 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Subject: Re: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Jun 2010 13:28:55 -0000

Michael D'Errico wrote:
> I think the current name doesn't describe the feature very well.  SMTP and
> HTTP call it "pipelining" so perhaps you could use that name instead.  My
> software should tolerate TLS pipelining if a peer were to use it, but I
> don't feel comfortable adding it as a feature.

You probably mean that your server side implementation should tolerate
it if some TLS False Start enabled component were to use it?

I assume that a lot of server implementations will tolerate such clients.
After all, waiting for and verifying the server's ChangeCipherSpec&Finished
handshake messages is a duty of the client and in the interest of the client.

There is _no_ obligation on the server to perform any kind of heuristics
on initial(!!) TLS handshakes on a connection whether there already is
incoming application data TLS record available from the communication
channel at the time when the server is about to send off his
ChangeCipherSpec&Finished handshake messages.  For renegotiation handshakes
there is an explicit requirement in the specs 22465/4346/5246 that
interleaving of handshake messages and data records must be tolerated.

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.

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.