This is in part why I created: https://github.com/tlswg/tls13-spec/pull/402
My understanding is that the server is able to send any data that does not depend on client authentication at t=0.5 and any data that depends on client authentication at either t=0.5 if it successfully consumes the client authentication in the 0-RTT flight, or t=1.5 failing that. On 27 January 2016 at 11:46, David Benjamin <david...@chromium.org> wrote: > It's possible I'm reading the draft wrong, so this thread may be a very > short one. > > (t here is in units of RTT, so t=0 is when the client sends ClientHello and > t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 is > when the client receives ServerHello, etc.) > > Looking at the Zero-RTT exchange here: > https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2 > > Is the intention that the client, even in the successful 0-RTT case, send > two Finished messages (one at t=0 and one at t=1) and that the server not > send application data until receiving the second of these at t=1.5? If so, > does this not defeat the purpose of 0-RTT? Although the client now eagerly > sends at t=0, it will not see the response until t=2, which is no better > than the resumption case (in TLS 1.2 or 1.3) where the client doesn't send > until t=1. > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
