|
CSR :
|
|
|
CSR :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Summary
-------
Add support of Transport Layer Security (TLS) Protocol version 1.3 from Java SE 8 MR 3.
The base document for this CSR is [JDK-8202625]: TLS 1.3 Implementation. This CSR includes changes and references to [JDK-8208526] (TLS 1.3 half-close and synchronization issues), [JDK-8046321] (JEP 249: OCSP Stapling for TLS), [JDK-8140436] (Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS) and [JDK-8043758] (JEP 219: Datagram Transport Layer Security (DTLS)). How this CSR differs from its base or related documents is indicated in each Specification item.
All the changes proposed are based on the [Java SE 8 MR 3](https://jcp.org/aboutJava/communityprocess/mrel/jsr337/index3.html), which was forward-ported to OpenJDK 8 Updates Release.
Problem
-------
TLS 1.3 ([RFC 8446](https://tools.ietf.org/html/rfc8446)) is a major overhaul of the TLS protocol and provides significant security and performance improvements over previous versions. Several early implementations from other vendors are available already. We need to support TLS 1.3 in Java SE 8 to remain competitive and keep pace with the latest standard.
A minimal inter-operable and compatible TLS 1.3 implementation should support:
- Protocol version negotiation
- TLS 1.3 full handshake
- TLS 1.3 session resumption
- TLS 1.3 key and iv update
- OCSP stapling for TLS (JEP-249)
- TLS 1.3 backward compatibility mode
- TLS 1.3 required extensions and algorithms
- RSASSA-PSS signature algorithms (JDK-8230978)
As a new version, TLS 1.3 supersedes and obsoletes previous versions of TLS including version 1.2 (RFC 5246). It also obsoletes or changes other TLS features such as the OCSP stapling extensions (RFC 6066, RFC 6961), and the session hash and extended master secret extension (RFC 7627). The Java Secure Socket Extension (JSSE) in the JDK provides a framework and a Java implementation of the SSL and TLS protocols. Currently, the JSSE API and JDK implementation supports SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2.
No new public APIs are required for the minimal implementation. However, it is required to define new algorithms for TLS 1.3, and document the behavior difference between TLS 1.3 and TLS 1.2 or prior versions.
TLS 1.3 implementation was introduced in Java SE 11 under [JEP 332](https://openjdk.java.net/jeps/332). CSR for Java SE 11 is [JDK-8202625](https://bugs.openjdk.java.net/browse/JDK-8202625).
Solution
--------
This CSR requests to support a minimal inter-operable and compatible TLS 1.3 implementation in the SunJSSE security provider of the next OpenJDK 8 Update release. See the "Specification" section for the details.
OCSP Stapling is added as part of this backport. See more in the [JEP-249](https://openjdk.java.net/jeps/249) description.
The solution for this CSR builds on top of the following CSRs:
* [JDK-8233417](https://bugs.openjdk.java.net/browse/JDK-8233417): JEP 244: TLS Application-Layer Protocol Negotiation Extension (Java SE 8)
* [JDK-8233418](https://bugs.openjdk.java.net/browse/JDK-8233418): Add support for RSASSA-PSS Signature algorithm (Java SE 8)
Specification
-------------
1. New standard algorithm name for SSLContext protocols
----------------------------------------------------
Define the standard algorithm name for TLS 1.3 for SSLContext protocols:
TLSv1.3: supports TLS version 1.3 (RFC 8446);
may support other TLS versions
Need to add the standard algorithm name to the SSLContext section in the "Java Security Standard Algorithm Names" specification, and update the "JDK Providers" and "Java Secure Socket Extension (JSSE) Reference Guide" documentation accordingly.
Changes from [JDK-8202625] TLS 1.3 Implementation: RFC is now published and its number known.
2. New standard algorithm names for the enabled or supported protocols
----------------------------------------------------
Define the following standard algorithm name for TLS 1.3 for the negotiated, enabled or supported protocols of classes SSLSession, SSLEngine, SSLServerSocket, SSLSocket and SSLParameters:
TLSv1.3: TLS version 1.3 protocol (defined in RFC 8446)
Need to add the standard algorithm name to the protocols block of the "Additional JSSE Standard Names" section in the "Java Security Standard Algorithm Names" specification, and update the "Java Secure Socket Extension (JSSE) Reference Guide" documentation accordingly.
Changes from [JDK-8202625] TLS 1.3 Implementation: RFC is now published and its number known.
3. New System Property to configure the default server enabled protocol suite
----------------------------------------------------
A System Property, "jdk.tls.server.protocols", is added to configure the default enabled protocol suite in server side of SunJSSE provider.
The property string is a list of comma separated standard SSL protocol names. The syntax of the property string can be described as this Java BNF-style:
ServerProtocols:
('"' SSLProtocolNames '"') | SSLProtocolNames
SSLProtocolNames:
SSLProtocolName { , SSLProtocolName }
SSLProtocolName:
(see below)
The "SSLProtocolName" is the standard SSL protocol name as described in the "Java Cryptography Architecture Standard Algorithm Name Documentation". If the property value does not comply to the above syntax, or the specified value of SSLProtocolName is not a supported SSL protocol name, the instantiation of the SSLContext provider service (via SSLContext.getInstance() methods) may generate a java.security.NoSuchAlgorithmException. Please note that the protocol name is case-sensitive.
Note that this System Property impacts only the default protocol suite (SSLContext of algorithm "SSL" and "TLS"). If an application uses a version specified SSLContext ("SSLv3", "TLSv1", "TLSv1.1", "TLSv1.2", "TLSv1.3"), or set the enabled protocol version explicitly, this System Property has no impact.
Note that this System Property does not impact the API specification of JSSE, JSSE client side and third party's provider.
Changes from [JDK-8202625] TLS 1.3 Implementation: *no changes*.
4. Enable TLS 1.3 for server side by default
----------------------------------------------------
TLS version 1.3 will be enabled for server side in the default SSLContext ("SSL" or "TLS") in JDK.
For compatibility reasons TLS version 1.3 will be disabled for client side in the default SSLContext ("SSL" or "TLS") in JDK.
The supported, client default enabled and server default enabled TLS versions of different SSLContext protocols can be summarized as follow:
-----------------------+---------------+----------------------------
SSLContext protocols | supported TLS | enabled TLS versions
| versions +-------------+--------------
| | client mode | server mode
-----------------------+---------------+-------------+--------------
SSL | TLSv1.3 | TLSv1.2 | TLSv1.3
| TLSv1.2 | TLSv1.1 | TLSv1.2
| TLSv1.1 | TLSv1 | TLSv1.1
| TLSv1 | SSLv3 | TLSv1
| SSLv3 | | SSLv3
-----------------------+ (SSLv2Hello) +-------------+ (SSLv2Hello)
SSLv3 | | TLSv1 |
| | SSLv3 |
-----------------------+ +-------------+
TLS | | TLSv1.2 |
| | TLSv1.1 |
| | TLSv1 |
| | SSLv3 |
-----------------------+ +-------------+
TLSv1 | | TLSv1 |
| | SSLv3 |
-----------------------+ +-------------+
TLSv1.1 | | TLSv1.1 |
| | TLSv1 |
| | SSLv3 |
-----------------------+ +-------------+
TLSv1.2 | | TLSv1.2 |
| | TLSv1.1 |
| | TLSv1 |
| | SSLv3 |
-----------------------+ +-------------+
TLSv1.3 | | TLSv1.3 |
| | TLSv1.2 |
| | TLSv1.1 |
| | TLSv1 |
| | SSLv3 |
-----------------------+---------------+-------------+--------------
TLSv1.3 can be enabled on the client-side via:
- the existing SSLSocket/SSLEngine/SSLParameters APIs
- the 'TLSv1.3' SSLContext
- the jdk.tls.client.protocols property
- the https.protocols property
If there is a need, TLSv1.3 can be disabled explicitly. See the "Customizing JSSE" section in the "Java Secure Socket Extension (JSSE) Reference Guide" documentation.
Changes from [JDK-8202625] TLS 1.3 Implementation: TLSv1.3 is disabled by default on the client-side.
5. New TLS cipher suite names for TLS 1.3
----------------------------------------------------
Define two new standard cipher suite names for TLS 1.3 in this implementation.
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
Although TLS 1.3 uses the same cipher suite space as previous versions, TLS 1.3 cipher suites are defined differently and cannot be used with TLS 1.2. Similarly, TLS 1.2 and lower cipher suites cannot be used with TLS 1.3. Need to update the "JSSE Cipher Suite Names" section in the "Java Security Standard Algorithm Names" specification, and the "Java Secure Socket Extension (JSSE) Reference Guide" and "SunJSSE" section of the "JDK Providers" documentation accordingly.
Changes from [JDK-8202625] TLS 1.3 Implementation: *no changes*.
6. New TLS handshake extensions
----------------------------------------------------
Implement TLS 1.3 mandatory-to-implement extensions, including:
- supported_versions (new TLS handshake extension in JDK)
- cookie (new TLS handshake extension in JDK)
- signature_algorithms
- signature_algorithms_cert (new TLS handshake extension in JDK)
- supported_groups
- key_share (new TLS handshake extension in JDK)
- server_name
and the required extensions for session resumption:
- pre_shared_key (new TLS handshake extension in JDK)
- psk_key_exchange_modes (new TLS handshake extension in JDK)
Note that the following optional extensions are also supported:
- max_fragment_length
- status_request
- application_layer_protocol_negotiation
Changes from [JDK-8202625] TLS 1.3 Implementation: the API is not extended to use max_fragment_length extension from the client-side. The max_fragment_length extension is available for use on the server-side only.
7. Support stateless HelloRetryRequest
----------------------------------------------------
In JDK, a TLS 1.3 server will operate a stateless HelloRetryRequest for performance and security improvement.
Changes from [JDK-8202625] TLS 1.3 Implementation: *no changes*.
8. Support post-handshake key and IV update
----------------------------------------------------
TLS 1.3 has a post-handshake key and IV update, which will update the sending and receiving keys for one side of the connection. Applications can trigger an update by calling SSLSocket.startHandshake() or SSLEngine.beginHandshake(). Key Usage Limits will also trigger an update when the algorithm limits are reached
Changes from [JDK-8202625] TLS 1.3 Implementation: *no changes*.
9. Support session resumption with post-handshake new session ticket
----------------------------------------------------
After TLS 1.3 handshake complete, a JDK server will send a NewSessionTicket message. The client may use this message for session resumption if needed later.
Changes from [JDK-8202625] TLS 1.3 Implementation: *no changes*.
10. Support RSASSA-PSS key exchange and X.509 certificate
----------------------------------------------------
Support RSASSA-PSS algorithms with public key OID either rsaEncryption or RSASSA-PSS. See also the [RSSSSA-PSS CSR](https://bugs.openjdk.java.net/browse/JDK-82333418) for JCE components.
Changes from [JDK-8202625]: TLS 1.3 Implementation: *no changes*.
11. OCSP stapling for TLS
----------------------------------------------------
As part of the SunJSSE security provider backport to OpenJDK 8 Updates release, support for server-side OCSP stapling (described by [JEP 249: OCSP Stapling for TLS](https://bugs.openjdk.java.net/browse/JDK-8046321)) is introduced. Client-side OCSP stapling support ([JDK-8237486](https://bugs.openjdk.java.net/browse/JDK-8237486)) is not under the scope of this change, and may be added at a later time.
The new properties for server-side OCSP stapling are the same than described in [JEP 249](https://bugs.openjdk.java.net/browse/JDK-8046321), with the changes described in section *12. Support OCSP stapling for server certificate authentication*.
Changes from [JDK-8202625] TLS 1.3 Implementation: this change is not part of [JDK-8202625]; it comes from [JDK-8046321] JEP 249: OCSP Stapling for TLS. Differences with JEP 249 are described in *12. Support OCSP stapling for server certificate authentication*.
12. Support OCSP stapling for server certificate authentication
----------------------------------------------------
TLS 1.3 improves the Online Certificate Status Protocol (OCSP) stapling by using different handshake messages. JDK will support OCSP stapling for server certificate authentication. It is a pure implementation update in JDK, applications should not be impacted.
By default, and contrary to JDK-11 SE, both *jdk.tls.client.enableStatusRequestExtension* and *jdk.tls.server.enableStatusRequestExtension* property values are set to *false*. To enable support for server-side OCSP stapling on either the client or server, set the respectively property values to *true*.
For more details refer to the "OCSP Stapling and Certificate Revocation" section in the "Java Secure Socket Extension (JSSE) Reference Guide" documentation, or to [JEP 249](https://bugs.openjdk.java.net/browse/JDK-8046321).
Note that TLS 1.3 deprecates the "status_request_v2" extension, and therefore deprecate the OCSP stapling implementation based on the "status_request_v2" extension. TLS 1.3 uses different handshake messages for OCSP stapling. Although the update is transparent to applications, we should update the OCSP stapling descriptions accordingly in the "Java Secure Socket Extension (JSSE) Reference Guide" documentation.
Changes from [JDK-8202625] TLS 1.3 Implementation: this change is not part of [JDK-8202625]; it comes from [JDK-8046321] JEP 249: OCSP Stapling for TLS. Differences with JEP 249: *jdk.tls.client.enableStatusRequestExtension* and *jdk.tls.server.enableStatusRequestExtension* property values are set to *false* by default.
13. Limits on key usage
----------------------------------------------------
There are cryptographic limits that some algorithms have on the amount of plaintext which can be safely encrypted under a given set of keys. A new Security Property, "jdk.tls.keyLimits" has been added for TLS 1.3. When the amount of encrypted data by the algorithm has been reached a post-handshake Key and IV Update is triggered to derive new keys. This value is configurable so administrators can control their own security policies.
Changes from [JDK-8202625]: TLS 1.3 Implementation: *no changes*.
14. Deprecated extensions in TLS 1.3
----------------------------------------------------
The following extensions are deprecated, and do not apply to TLS 1.3 any more:
- status_request_v2 (RFC 6961)
- extended_master_secret (RFC 7627)
- renegotiation_info (RFC5746)
- ec_point_formats (RFC 4492)
Note that the JDK will continue the support of them for TLS 1.2 and prior versions.
Changes from [JDK-8202625]: TLS 1.3 Implementation: *no changes*.
15. Implement in compatibility mode
----------------------------------------------------
In order to mitigate the compatibility impact, TLS 1.3 will be implemented in the compatibility mode, as described in the "Middlebox Compatibility Mode" section of the TLS 1.3 specification.
Changes from [JDK-8202625]: TLS 1.3 Implementation: *no changes*.
16. New debug logger
----------------------------------------------------
The current implementation dumps debug log to both System.err and System.out, and is hard to read and analyze. A new debug logger will be used with this enhancement. For compatibility, the System Property "javax.net.debug" is still used to switch on/off the debug log.
If the System Property "javax.net.debug" is not defined, the debug logging is turned off.
If the System Property "javax.net.debug" is defined as empty, the debug logger is
specified by System.getLogger("javax.net.ssl"), and applications can customize
and configure the logger or use external logging mechanisms. If the System Property
"javax.net.debug" is defined and non-empty, a JDK private debug logger implemented is used.
For the JDK private debug logger, there are a few enhancement so that it is easier to read and analyze. For example, in the current implementation, a handshake message debug log may look like:
ServerHello, TLSv1.2
RandomCookie: random_bytes = {5A 4E F9 E3 0C C5 C3 FE B6 50 ED 3E 40 2D 5D 75 27 12 B7 C0 FB CA C5 DD 6E 79 DB FF AE C8 32 63}
Session ID: {90, 78, 249, 227, 53, 127, 161, 141, 161, 33, 124, 107, 167, 128, 131, 252, 2, 170, 193, 168, 50, 40, 183, 150, 161, 217, 57, 214, 248, 78, 138, 158}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
A similar debug log in the enhanced implementation may look like:
javax.net.ssl|DEBUG|01|main|2018-05-03 18:51:03.351 PDT|ServerHello.java:362|Produced ServerHello handshake message (
"ServerHello": {
"server version" : "TLSv1.2",
"random" : "84 89 84 9A B9 76 10 11 14 8E 0A 2E 66 F5 32 D9 6A B4 5A 92 41 ED 01 BA E3 DB 9E 4C 81 C5 54 29",
"session id" : "57 D7 69 7B 34 C8 5F 67 03 AF 9E 11 69 C3 29 86 7C 88 35 34 54 72 5E 7F A6 54 C8 A1 9C A0 3D 24",
"cipher suite" : "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C)",
"compression methods" : "00",
"extensions" : [
"renegotiation_info (65,281)":
{ "renegotiated connection": [<no renegotiated connection>] }
]
}
)
The new JDK private debug logger will record the logger name, the logger level, the thread ID, the thread name, the time and the caller for each log item.
Changes from [JDK-8202625]: TLS 1.3 Implementation: *no changes*.
17. New System property jsse.enableFFDHE to disable Finite Field Groups for DHE cipher suites (FFDHE)
----------------------------------------------------
Clients implementing [RFC 7919](https://tools.ietf.org/html/rfc7919) send the Finite Field Groups parameters in the "supported_groups" TLS extension, for DHE cipher suites. Some servers may not be able to handle this extension or the FFDHE groups in it. The new *jsse.enableFFDHE* System property can be set to *false* to switch this off (*true* is the default value).
Changes from [JDK-8202625]: TLS 1.3 Implementation: the new System property is does not come from [JDK-8202625] but from [JDK-8140436] Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS (see [JDK-8244613] Release Note describing the property).
18. KRB5 cipher suites are not supported for TLSv1.3 protocol
----------------------------------------------------
The Kerberos-based cipher suites (KRB5) are no longer considered safe. They will be supported for compatibility reasons in TLSv1.2 or previous but disabled by default. Use *jdk.tls.client.cipherSuites* and *jdk.tls.server.cipherSuites* properties to enable them on the client and server sides respectively.
Kerberos cipher suites:
- TLS_KRB5_WITH_3DES_EDE_CBC_SHA
- TLS_KRB5_WITH_3DES_EDE_CBC_MD5
- TLS_KRB5_WITH_RC4_128_SHA
- TLS_KRB5_WITH_RC4_128_MD5
- TLS_KRB5_WITH_DES_CBC_SHA
- TLS_KRB5_WITH_DES_CBC_MD5
- TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
- TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
- TLS_KRB5_EXPORT_WITH_RC4_40_SHA
- TLS_KRB5_EXPORT_WITH_RC4_40_MD5
Changes from [JDK-8202625] TLS 1.3 Implementation: [JDK-8202625] removes KRB5 cipher suites while we keep them here for backward compatibility purposes.
19. Add a new System Property for TLS 1.3 half-close policy
----------------------------------------------------
A new System property, *jdk.tls.acknowledgeCloseNotify*, is added as described by [CSR 8208526: TLS 1.3 half-close and synchronization issues](https://bugs.openjdk.java.net/browse/JDK-8208526). Changes in JDK-8's default behavior are the same as described for JDK-11 in the referred CSR.
Changes from [JDK-8202625] TLS 1.3 Implementation: this change is not part of [JDK-8202625]; it comes from [JDK-8208526] TLS 1.3 half-close and synchronization issues. Differences with [JDK-8208526]: *no differences*.
20. A system property com.sun.net.ssl.dhKeyExchangeFix was removed
----------------------------------------------------
A system property introduced by [4348279: DH ServerKeyExchange DSA signature encoding bug](https://bugs.openjdk.java.net/browse/JDK-4348279) was removed. The new SunJSSE security provider is not affected by this bug and properly encodes and decodes the signature.
Changes from [JDK-8202625] TLS 1.3 Implementation: this is not part of [JDK-8202625] but came with the TLS 1.3 implementation in [JDK-8196584].
21. A minimal Java specification change
----------------------------------------------------
javax.net.ssl.ExtendedSSLSession:
public abstract class ExtendedSSLSession implements SSLSession {
/**
* Obtains an array of supported signature algorithms that the local side
* is willing to use.
* <p>
* Note: this method is used to indicate to the peer which signature
- * algorithms may be used for digital signatures in TLS 1.2. It is
+ * algorithms may be used for digital signatures since TLS 1.2. It is
* not meaningful for TLS versions prior to 1.2.
* <p>
* The signature algorithm name must be a standard Java Security
* name (such as "SHA1withRSA", "SHA256withECDSA", and so on).
* See Appendix A in the <a href=
* "{@docRoot}/../technotes/guides/security/crypto/CryptoSpec.html#AppA">
* Java Cryptography Architecture API Specification & Reference </a>
* for information about standard algorithm names.
* <p>
* Note: the local supported signature algorithms should conform to
* the algorithm constraints specified by
* {@link SSLParameters#getAlgorithmConstraints getAlgorithmConstraints()}
* method in <code>SSLParameters</code>.
*
* @return An array of supported signature algorithms, in descending
* order of preference. The return value is an empty array if
* no signature algorithm is supported.
*
* @see SSLParameters#getAlgorithmConstraints
*/
public abstract String[] getLocalSupportedSignatureAlgorithms();
/**
* Obtains an array of supported signature algorithms that the peer is
* able to use.
* <p>
* Note: this method is used to indicate to the local side which signature
- * algorithms may be used for digital signatures in TLS 1.2. It is
+ * algorithms may be used for digital signatures since TLS 1.2. It is
* not meaningful for TLS versions prior to 1.2.
* <p>
* The signature algorithm name must be a standard Java Security
* name (such as "SHA1withRSA", "SHA256withECDSA", and so on).
* See Appendix A in the <a href=
* "{@docRoot}/../technotes/guides/security/crypto/CryptoSpec.html#AppA">
* Java Cryptography Architecture API Specification & Reference </a>
* for information about standard algorithm names.
*
* @return An array of supported signature algorithms, in descending
* order of preference. The return value is an empty array if
* the peer has not sent the supported signature algorithms.
*
* @see X509KeyManager
* @see X509ExtendedKeyManager
*/
Changes from [JDK-8202625] TLS 1.3 Implementation: *no changes*.
22. Increase the priorities of GCM cipher suites
----------------------------------------------------
The priority of cipher suites based on GCM (Galois/Counter Mode) will be increased.
Descending priority list of GCM-based cipher suites which are enabled by default:
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
Changes from [JDK-8202625] TLS 1.3 Implementation: this is not part of [JDK-8202625] but came with the TLS 1.3 implementation in [JDK-8196584].
23. A new system property, "jsse.enableMFLNExtension"
----------------------------------------------------
A new System property introduced in the context of [JDK-8043758] JEP 219: Datagram Transport Layer Security (DTLS), *"jsse.enableMFLNExtension*, is added. This property, when *false* -default value-, disables the use of the max_fragment_length TLS extension. In 8u the MFLN extension may be used by TLS servers only; as the API for clients to change the max fragment size was not in the scope of the backport.
Changes from [JDK-8202625] TLS 1.3 Implementation: this property was not introduced by [JDK-8202625]; it comes from [JDK-8043758]. Differences with [JDK-8043758]: the property has no effect on TLS-clients, as they are unable to use the max_fragment_length TLS extension (see *6. New TLS handshake extensions*).
Compatibility Risk
----------------------------------------------------
Note that TLS 1.3 is not directly compatible with previous versions. Although TLS 1.3 can be implemented with a backward-compatibility mode, there are still several compatibility risks to upgrade to TLS 1.3:
- TLS 1.3 uses a half-close policy, while TLS 1.2 and prior versions use a duplex-close policy. For applications that depend on the duplex-close policy, there may be compatibility issues when upgrading to TLS 1.3. This can be fixed with the *jdk.tls.acknowledgeCloseNotify* System property.
- The signature_algorithms_cert extension requires that pre-defined signature algorithms are used for certificate authentication. In practice, however, an application may use non-supported signature algorithms.
- The DSA signature algorithm is not supported in TLS 1.3. If a server is configured to only use DSA certificates, it cannot upgrade to TLS 1.3.
- The supported cipher suites for TLS 1.3 are not the same as TLS 1.2 and prior versions. If an application hard-codes cipher suites which are no longer supported, it may not be able to use TLS 1.3 without modifying the application code.
- The TLS 1.3 session resumption and key update behaviors are different from TLS 1.2 and prior versions. The compatibility should be minimal, but it could be a risk if an application depends on the handshake details of the TLS protocols.
- There can be a compatibility risk associated to the removal of the *com.sun.net.ssl.dhKeyExchangeFix* property and the change on the signature encoding. However, this bug has been fixed for around 20 years and no interaction with a JDK not applying the fix is expected.
The compatibility risk should be low. If there is a need, TLSv1.3 can be disabled explicitly. See the "Customizing JSSE" section in the "Java Secure Socket Extension (JSSE) Reference Guide" documentation.
|