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

[Alexey Bakhtin]

Hello Martin,

TLSv1.3, 1.2 and 1.1 contexts are different because of we selected highest protocol explicitly, so return cipher suites for these protocol set only.
My approach requires less configuration from application point of view.
However you are right, this approach could be also misleading if default cipher and protocol set not match each other.

Updated webrev at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245476/webrev.v1/


Regards
Alexey

> On 16 Jul 2020, at 10:30, Martin Balao <mbalao at redhat.com> wrote:
> 
> 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.-
>