On 26 April 2017 at 17:19, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > AFAIK, the only situations where client can abort sending 0-RTT data > is noticing lack of server EarlyData extension (so server isn't > listening anyway), or if the entiere handshake is aborted.. Doing it > in other situations leads to subtle race conditions.
NSS stops sending 0-RTT as soon as it processes EncryptedExtensions. It also stops if it receives a HelloRetryRequest. In both cases you know that the server is trial decrypting and so it will correctly handle more 0-RTT data, but there is no point sending more if you know that it is junk. >> In effect, we assume that the entire flight is processed atomically >> and generate errors based on that. Only when the entire flight is >> processed cleanly do we install keys and respond. > > My implementation processes message-by-message. So it installs the > client handshake keys after ServerHello. NSS processes message-by-message, but the we just delay installing the client handshake keys. This allows us to get the most out of 0-RTT, but has this small downside. >> This is a pain for us, we don't have the code that Ilari talks about, >> so some of our tests end up hitting decode errors on the server, but >> it's been manageable thus far. > > The code I was talking about was handling the special case that the > server might receive either encrypted or unencrypted alert in response > to its flight. And the difference it makes is just what error is > declared as abort reason. Yeah, it's totally manageable, but there are a few small warts in the tests (which match the sent alert on one side with the received alert on the other side in the normal case). _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
