[openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Viktor Dukhovni]

> On Jan 23, 2019, at 12:42 PM, David Benjamin <davidben at google.com> wrote:
> 
> (a) Debugging hooks for tracing, often copied from the openssl binary.
> (b) As a callback to know when the handshake (in the RFC8446 sense described above, not the OpenSSL sense) is done, sensitive to SSL_CB_HANDSHAKE_DONE.
> (c) As a callback to block renegotiations.
> 
> The problem here is (c), and empirically has affected versions of NGINX, Node, HAProxy and the real TLS 1.3 ecosystem. There may be more yet undiscovered problems; we only had KeyUpdates on in Chrome for a week on Chrome Canary before we had to shut it off. At three affected callers, one cannot simply say this is the consumer's fault.
> 
> As for the others, (b) also doesn't want to trigger on KeyUpdate, though it may tolerate it. (I have seen versions of (b) which ignore duplicates and versions which break on renegos---no one tests against it, which is why it's off by default in BoringSSL.) (a) is closest to the scenario you are concerned about, but such debugging notes are just that: debugging. I have never seen code which cares about their particulars. Indeed, if it did, adding TLS 1.3 would not be compatible because 1.3 changes the state machine.
> 
> Thus, the fix is clear: don't signal HANDSHAKE_START and HANDSHAKE_DONE on KeyUpdate. Not signaling has some risk, but it is low, especially in comparison to the known breakage and ecosystem damage caused by signaling.

I'm inclined to agree with David here.  I should also note that there are two
issues in this thread, of which this is the second.  The first one is about
the limit on the number of key update messages per connection, and I hope
that we can do something sensible there with less controversy.

-- 
	Viktor.