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

["Brian Smith" <[e-mail]>]

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