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

[Marsh Ray <[e-mail]>]

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