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

Marsh Ray <marsh@extendedsubset.com> Fri, 04 June 2010 16:59 UTC

Return-Path: <marsh@extendedsubset.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 489273A67A3 for <tls@core3.amsl.com>; Fri, 4 Jun 2010 09:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 rvthMXam3FTs for <tls@core3.amsl.com>; Fri, 4 Jun 2010 09:59:04 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 5D1953A69BF for <tls@ietf.org>; Fri, 4 Jun 2010 09:59:04 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OKaEM-000JHq-Bo for tls@ietf.org; Fri, 04 Jun 2010 16:58:50 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 5C2BA64D8 for <tls@ietf.org>; Fri, 4 Jun 2010 16:58:49 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19Z/mQYVY7KyH4k7EHYnaagcHhucHAnmMY=
Message-ID: <4C0930C4.4030806@extendedsubset.com>
Date: Fri, 04 Jun 2010 11:58:44 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: tls@ietf.org
References: <201006041537.o54FbT23020988@fs4113.wdf.sap.corp>
In-Reply-To: <201006041537.o54FbT23020988@fs4113.wdf.sap.corp>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 16:59:05 -0000

On 6/4/2010 10:37 AM, Martin Rex wrote:
> Brian Smith wrote:
>>
>> 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".

The description makes sense to me. Seems like a straightforward
optimization for a memory-constrained environment.

The $256 question is then, how many other servers are there that are
using similar optimizations?

I could also imagine code that rejected the unexpected data on the
principle of being conservative from a security perspective. The TLS
RFCs strongly imply (if not state explicitly) that this is illegal behavior.

It would be good for the ID to discuss possible ways for clients to
detect and handle servers that don't accept this optimization.

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

+1

The ID currently doesn't mention TCP anywhere, and of course, TLS
doesn't specifically require TCP anyway. Schemes that depended on
maintaining specific TCP segmentation characteristics would likely be
broken by any number of intermediate TCP-level proxies that never
guaranteed to preserve it (e.g. Tor).

- Marsh