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

[Martin Rex <[e-mail]>]

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