[8u] TLSv1.3 RFR: 8245476: Disable TLSv1.3 protocol in the ClientHello message by default

[Martin Balao]

On 7/16/20 1:51 AM, Alexey Bakhtin wrote:
>> One question: why do we need to include TLS 1.3 when retrieving the list
>> of client enabled ciphersuites to assign
>> CustomizedTLSContext::clientDefaultCipherSuites field?
>>
> TLS1.3 cipher suites should be enabled, otherwise we can not switch to TLSv1.3 protocol with  SSLSocket.setEnabledProtocols() or SSLSocket.setSSLParameters(). TLS1.3 cipher suites will be disabled and handshake fails because of no appropriate protocol + cipher suite.
> 

I see your point but looks a bit confusing to me that TLS 1.3
ciphersuites would be enabled in the client's default Context when the
protocol is not. Even if these ciphersuites are not offered to the TLS
server in the handshake -which I guess you already verified-, I'd have
expected a more consistent context state there.

If we look at TLS 1.3, 1.2, 1.1, etc. contexts, there is a direct
relationship between protocols and ciphersuites enabled: no ciphersuite
from a greater-only protocol is included in the context. In other words,
the ciphersuite must 'support' one of the protocols to be in the
context. We would be making an (arbitrary) exception for the client's
default context only.

If the application enables a protocol dynamically -by means of
SSLSocket/SSLEngine::setEnabledProtocols or
SSLSocket/SSLEngine::setSSLParameters-, then it will probably want to
modify the ciphersuites as well -by means of
SSLSocket/SSLEngine::setEnabledCipherSuites or
SSLSocket/SSLEngine::setSSLParameters-. But the assumption then is that
it wants a more custom or manual configuration, and diverges from the
context's default.

What do you think?

Have you seen any other downside beyond ::setEnabledProtocols and
::setSSLParameters?

Thanks,
Martin.-