RFR: 8296820: Add implementation note to SSLContext.getInstance noting subsequent behavior if protocol is disabled

[Sean Mullan]

On Wed, 16 Nov 2022 17:39:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
>>> 
>>> > The wording in this PR specifically refers to the protocol version that
>>> 
>>> was specified. It isn't covering other optional protocols that may be supported.
>>> 
>>> Sorry, I may not make it clear. The protocol specified in SSLContext.getInstance is not TLS protocol version. I think the protocol disabled in security properties refers to protocol version. 
>> 
>> Where in the javadoc APIs does it say that? I think the only assumption you can make is that the SSLContext that is returned supports the protocol version that was specified. Whether or not it supports other versions is completely implementation-specific AFAICT.
>
>> > _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
>> > > The wording in this PR specifically refers to the protocol version that
>> > 
>> > 
>> > was specified. It isn't covering other optional protocols that may be supported.
>> > Sorry, I may not make it clear. The protocol specified in SSLContext.getInstance is not TLS protocol version. I think the protocol disabled in security properties refers to protocol version.
>> 
>> Where in the javadoc APIs does it say that?
> 
> The Javadoc APIs specification does not say it is referring to TLS protocol version.  In the standard algorithm documentation, the word "SSLContext Algorithms" is used and here is an example:
> 
> 
> Algorithm Name | Description
> -- | --
> TLSv1.2 | Supports RFC 5246: TLS version 1.2; may support other SSL/TLS versions
> 
> 
>> I think the only assumption you can make is that the SSLContext that is returned supports the protocol version that was specified. Whether or not it supports other versions is completely implementation-specific AFAICT.
> 
> Yes.  So we cannot assume that the literal SSLContext algorithm is the only supported TLS version for an JSSE provider, including the SunJSSE provider.

I plan to withdraw this PR for now. @XueleiFan you make some good points that the implementation note is too specific (there are other failure scenarios) and also that a connection may still be successfully established using other protocols if the implementation supports other protocols than what was requested.

I really think that what is needed is a better class description in the javadoc of the `SSLContext` class about what the protocol passed to `getInstance` means. Something similar to what is documented in the JSSE Developer's Guide: https://docs.oracle.com/en/java/javase/19/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-9BAC1902-A203-4422-8163-61D64ADD2FF7
I will open an RFE for that.

After that we can add more information on specific implementation specific scenarios, such as what is being proposed here.

-------------

PR: https://git.openjdk.org/jdk/pull/11172