On Fri, May 29, 2020 at 04:59:57PM -0400, David Benjamin wrote: > > Half-RTT data > > We haven’t done much with half-RTT data outside of 0-RTT connections, but > half-RTT may risk similar issues. Half-RTT data in a client certificate > connection is sent before the server learns the client identity. That means > the connection is writable before all its properties are established, which > is an awkward API. > > One might think to avoid this state by configuring half-RTT data ahead of > time for the library to write during the handshake, immediately after > ServerHello..Finished. A half-RTT HTTP/2 SETTINGS frame doesn’t need a > streaming API, and this avoids exposing the incomplete state to the caller.
There are other issues with half-RTT HTTP/2 SETTINGS as well. I had a HTTP/2 implementation that used to send HTTP/2 SETTINGS as half-RTT if there was no client certificate[1]. I later changed it to not use half-RTT for HTTP/2 because some TLS clients puked with unexpected_message alert if one sent SETTINGS in half-RTT[2]. I do not know which clients did that[3]. [1] Not doing that with client certificate was caused by API issues with the handoff. The TLS library native API would have allowed sending data in half-RTT even with client certificate pending (unlike say false start, which is the TLS implementation just prohibits). [2] The unexpected_message actually came after the handshake completed (the client did send correct Finished MAC). (Fixing the issue was quite nasty shotgun debugging, and it took long time to verify issue was fixed, as normally there would only be one or two failures per day.) [3] Some terse user reports I heard reported things like the site not working in Firefox on Windows host, but working in Firefox on Linux VM on that host and site not working in Chrome (or Chromium?) but working in Firefox on the same system. (I did get one user report that the problem was fixed about a week after I did the change that fixed it.) -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
