[gnutls-devel] TCP Fast Open

Nikos Mavrogiannopoulos nmav at gnutls.org
Thu Jul 21 16:13:05 CEST 2016

On Thu, Jul 21, 2016 at 4:06 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> One question with that. Do you plan to enable it unconditionally or
>> conditionally if some state is known about the server? I know that
>> google has done quite some experiments with false start and chrome and
>> they only enable it on specific servers. The reason I believe is that
>> certain middle-boxes choke when a finished message is followed by
>> application data.
> I would like to enable it by default...
> Everybody wants 0RTT for TLS a.s.a.p., middle boxes just have to work :-) .
> But of course we have to be careful for the near future.
> I will need to make lot's of tests before I can decide. But for now (during
> development / pre-release), I have these feature enabled by default.
> BTW, just testing False Start together with session resumption (with GnuTLS
> 3.5 / master)... as it turns out, after handshake returns there is no session
> data yet. I guess it is available after the first read !? Or what is the best
> time to retrieve it ?

False start doesn't do anything on resumed sessions because on these
sessions the client is the one sending the finished packet last. There
could be a server-side false start in that case (briefly discussed in
draft-ietf-tls-falsestart-02) but it is not defined by that draft -and
not implemented by gnutls. Thus, you shouldn't see a difference when
enabling it on client side and resuming.


More information about the Gnutls-devel mailing list