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

[Matt Caswell]

On 23/01/2019 17:42, David Benjamin wrote:
> On Wed, Jan 23, 2019 at 4:24 AM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
>     On 22/01/2019 20:41, David Benjamin wrote:
>     > On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni
>     <openssl-users at dukhovni.org <mailto:openssl-users at dukhovni.org>
>     > <mailto:openssl-users at dukhovni.org <mailto:openssl-users at 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