[gnutls-devel] TCP Fast Open

[Tim Ruehsen]

On Thursday, July 21, 2016 4:27:55 PM CEST Tim Ruehsen wrote:
> 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.

OK, now I see what you mean :-(
So how can we come down to 0RTT TLS overhead and send all in one packet ?

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/4cd473cc/attachment.sig>