[gnutls-devel] TCP Fast Open

[Tim Ruehsen]

On Thursday, July 21, 2016 4:13:05 PM CEST Nikos Mavrogiannopoulos wrote:
> 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.

From my understanding, False Start enabled makes handshake() come back before 
the handshake packet has been sent. How else can I piggy-back application data 
to the handshake ? So when the session is not resumed, I can't get session 
data right after handshake() comes back... the handshake isn't completed yet - 
resp. we didn't get any packet from the server so far.
I guess (will test it in a few minutes), that I have to wait for the first  
application data packet coming back.

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160721/453d0ece/attachment-0001.sig>