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

[Martin Rex <[e-mail]>]

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.


-Martin