[gnutls-devel] TCP Fast Open

[Tim Ruehsen]

On Thursday, July 21, 2016 4:50:04 PM CEST Tim Ruehsen wrote:
> 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 ?

To answer my own question: it needs TLS 1.3 (for a good explanation see [1]).
I read there is currently much discussion going on about it... Nikos, are you 
waiting for the finalization of [2] before you start an implementation or what 
is your plan ?

[1] https://timtaubert.de/blog/2015/11/more-privacy-less-latency-improved-handshakes-in-tls-13/).
[2] https://tlswg.github.io/tls13-spec/

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/41d9c6ac/attachment.sig>