Skip to main content

5. Extension Negotiation

5. Extension Negotiation​

5.1. Extension Definition​

This document defines a new TLS extension, extended_master_secret (with extension type 0x0017), which is used to signal both client and server to use the extended master secret computation. The extension_data field of this extension is empty. Thus, the entire encoding of the extension is 00 17 00 00 (in hexadecimal.)

Although this document refers only to TLS, the extension proposed here can also be used with Datagram TLS (DTLS) [RFC6347].

If the client and server agree on this extension and a full handshake takes place, both client and server MUST use the extended master secret derivation algorithm, as defined in Section 4. All other cryptographic computations remain unchanged.

5.2. Client and Server Behavior: Full Handshake​

In the following, we use the phrase "abort the handshake" as shorthand for terminating the handshake by sending a fatal handshake_failure alert.

In all handshakes, a client implementing this document MUST send the extended_master_secret extension in its ClientHello.

If a server implementing this document receives the extended_master_secret extension, it MUST include the extension in its ServerHello message.

If both the ClientHello and ServerHello contain the extension, the new session uses the extended master secret computation.

If the server receives a ClientHello without the extension, it SHOULD abort the handshake if it does not wish to interoperate with legacy clients. If it chooses to continue the handshake, then it MUST NOT include the extension in the ServerHello.

If a client receives a ServerHello without the extension, it SHOULD abort the handshake if it does not wish to interoperate with legacy servers.

If the client and server choose to continue a full handshake without the extension, they MUST use the standard master secret derivation for the new session. In this case, the new session is not protected by the mechanisms described in this document. So, implementers should follow the guidelines in Section 5.4 to avoid dangerous usage scenarios. In particular, the master secret derived from the new session should not be used for application-level authentication.

5.3. Client and Server Behavior: Abbreviated Handshake​

The client SHOULD NOT offer an abbreviated handshake to resume a session that does not use an extended master secret. Instead, it SHOULD offer a full handshake.

If the client chooses to offer an abbreviated handshake even for such sessions in order to support legacy insecure resumption, then the current connection is not protected by the mechanisms in this document. So, the client should follow the guidelines in Section 5.4 to avoid dangerous usage scenarios. In particular, renegotiation is no longer secure on this connection, even if the client and server support the renegotiation indication extension [RFC5746].

When offering an abbreviated handshake, the client MUST send the extended_master_secret extension in its ClientHello.

If a server receives a ClientHello for an abbreviated handshake offering to resume a known previous session, it behaves as follows:

  • If the original session did not use the extended_master_secret extension but the new ClientHello contains the extension, then the server MUST NOT perform the abbreviated handshake. Instead, it SHOULD continue with a full handshake (as described in Section 5.2) to negotiate a new session.

  • If the original session used the extended_master_secret extension but the new ClientHello does not contain it, the server MUST abort the abbreviated handshake.

  • If neither the original session nor the new ClientHello uses the extension, the server SHOULD abort the handshake. If it continues with an abbreviated handshake in order to support legacy insecure resumption, the connection is no longer protected by the mechanisms in this document, and the server should follow the guidelines in Section 5.4.

  • If the new ClientHello contains the extension and the server chooses to continue the handshake, then the server MUST include the extended_master_secret extension in its ServerHello message.

If a client receives a ServerHello that accepts an abbreviated handshake, it behaves as follows:

  • If the original session did not use the extended_master_secret extension but the new ServerHello contains the extension, the client MUST abort the handshake.

  • If the original session used the extension but the new ServerHello does not contain the extension, the client MUST abort the handshake.

If the client and server continue the abbreviated handshake, they derive the connection keys for the new session as usual from the master secret of the original session.

5.4. Interoperability Considerations​

To allow interoperability with legacy clients and servers, a TLS peer may decide to accept full handshakes that use the legacy master secret computation. If so, they need to differentiate between sessions that use legacy and extended master secrets by adding a flag to the session state.

If a client or server chooses to continue with a full handshake without the extended master secret extension, then the new session becomes vulnerable to the man-in-the-middle key synchronization attack described in Section 1. Hence, the client or server MUST NOT export any key material based on the new master secret for any subsequent application-level authentication. In particular, it MUST disable [RFC5705] and any Extensible Authentication Protocol (EAP) relying on compound authentication [COMPOUND-AUTH].

If a client or server chooses to continue an abbreviated handshake to resume a session that does not use the extended master secret, then the current connection becomes vulnerable to a man-in-the-middle handshake log synchronization attack as described in Section 1. Hence, the client or server MUST NOT use the current handshake's verify_data for application-level authentication. In particular, the client MUST disable renegotiation and any use of the "tls-unique" channel binding [RFC5929] on the current connection.

If the original session uses an extended master secret but the ClientHello or ServerHello in the abbreviated handshake does not include the extension, it MAY be safe to continue the abbreviated handshake since it is protected by the extended master secret of the original session. This scenario may occur, for example, when a server that implements this extension establishes a session but the session is subsequently resumed at a different server that does not support the extension. Since such situations are unusual and likely to be the result of transient or inadvertent misconfigurations, this document recommends that the client and server MUST abort such handshakes.

Last updated on