On 23/01/2019 17:42, David Benjamin wrote: > On Wed, Jan 23, 2019 at 4:24 AM Matt Caswell <m...@openssl.org > <mailto:m...@openssl.org>> wrote: > > On 22/01/2019 20:41, David Benjamin wrote: > > On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni > <openssl-us...@dukhovni.org <mailto:openssl-us...@dukhovni.org> > > <mailto:openssl-us...@dukhovni.org <mailto:openssl-us...@dukhovni.org>>> > wrote: > > As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite > sure > > what to do there, but perhaps we could define a new even for > keyUpdates > > that does not mislead applications into assuming a new "handshake". > > > > I think this is clearly the right option. This is a compatibility > break, IMO. > > > > Prior to SSL_OP_NO_RENEGOTIATION (new in the same release that added > 1.3), > this > > was the only way to disable renegotiations. I've seen a lot of > codebases do > > this. I don't think one could even call it a mishandling. The natural > > interpretation of "SSL_CB_HANDSHAKE_START" is that a handshake has > started. > > Thus, if you wish to block renegotiations, absent a more direct API, > it's > > natural to count those and fail if you see more than one. > > > > A KeyUpdate is not a handshake. > > That's depends on your perspective. One peer sends a message, and the > other peer > (may) respond with a message. Sounds like a handshake to me. KeyUpdate > gets sent > in handshake records, with a HandshakeType value of 24 and is defined in > section > 4 of the RFC ("Handshake Protocol"). > > > This notion of "handshake" is not supported by RFC 8446 uses the terms "the > handshake", "a handshake", and "post-handshake". "Post-handshake", in > particular, implies KeyUpdate are after the handshake, not part of it.
I just don't agree with you here. About the best that can be said about RFC8446 in this regards is that the term handshake is overloaded. It certainly does mean "the initial handshake" in the way that you describe (and I myself use the term to mean that). But it is *also* used in other contexts, such as "handshake messages" or "handshake protocol" where it is referring to things not necessarily constrained to the initial handshake. Ignoring the unexpected interaction with KeyUpdates for the moment, it seems perfectly reasonable to me to use the SSL_CB_HANDSHAKE_START event to indicate "we are about to exchange handshake messages" - whether or not that is in the context of the initial handshake or not. > This documentation does not help code written prior to TLSv1.3, which is the > problem here. OpenSSL claims that TLS 1.3 is a backwards-compatible addition, > so > documentation updates for 1.3 may clarify but cannot be necessary. More on > this > below. I agree with this. That is precisely what I think that documentation does. > Thus, the fix is clear: don't signal HANDSHAKE_START and HANDSHAKE_DONE on > KeyUpdate. Not signaling has some risk > <https://boringssl.googlesource.com/boringssl/+/HEAD/BREAKING-CHANGES.md#breakage-risk>, > but it is low, especially in comparison to the known breakage and ecosystem > damage caused by signaling. Note: I have not said that we should not do this. All I have said is that changing the events should be done with caution. We do not (usually) allow breaking changes into stable releases - and with good reason. 1.1.1 has been declared as an LTS release. At the same time both 1.1.0 and 1.0.2 have moved to "security fix only" mode. So we are actively encouraging all users to move to that version. It's not a great message to send out if we are changing documented behaviour in a letter release and it could break some applications. What that means in practice is that in order for that change to be accepted I think it would require an OMC vote. I don't think the normal review process is good enough since this change would be actively breaking policy and isn't a bug fix (at least not in the usual sense of what that means). If we decided to make the change then we would also need to consider what it would mean for other message exchanges such as CertificateRequest and HelloRequest (not sure what we do now with this last one). Would we only change KeyUpdate (which would be a bit weird)? Or should we change all post-handshake messages to be consistent (which might risk more breakage than is strictly necessary to fix the KeyUpdate problem). Matt _______________________________________________ openssl-project mailing list email@example.com https://mta.openssl.org/mailman/listinfo/openssl-project