[8u] RFR : TLSv1.3 protocol support

[Martin Balao]

Hi Alexey,

On 5/14/20 6:09 PM, Alexey Bakhtin wrote:
> I’ve decided to keep some original files in the sun.securyti.ssl package in case of no functional modifications.
> I think it indicates that these files are version independent and better shows what is changed in these files from one version to another.

Yes, I see your point. Except for SunJSSE -where there are stronger
reasons-, looks like a trade-off between keeping the history and being
consistent with the strategy. We can keep these files then; I'll
document them as an exception.

> SunJSSE class was hardly changed by JDK-7092821 in JDK11.0.7
> JDK-7092821 is not part of JDK8, so I had two options:
> 1) use 11.0.7 version and revert JDK-7092821(huge changes)
> 2) use 8u262 version and add TLSv1.3 protocol definition (small changes)
> I decided to keep 8u262 version. In my opinion it better shows real modification in this file

Hardly or severely changed? I see quite a few changes. We will need a
backport of 7092821 to JDK-8 for parity with Oracle's JDK, but I
understand the inconvenience of doing it as part of the TLS 1.3 backport
because the changeset essentially affects files out of sun.security.ssl.
I agree with the decision you made here.

> JsseJCE class in 11.0.7 was modified to remove TLS_KRB5 feature. The rest changes are code formatting.
> I decided to keep original version of this file and show required modification in the step 7 (TLSv1.3: RFC-2712 support). This file also contains small modification on the step, but final version of this file is not identical to 11.0.7. It is 8u262 version with required modifications

Ok.

> 
> HostNameChecker class is not located in the sun/security/ssl file. As I remember, we decided to not replace files outside of sun/security/ssl but show and describe changes. The changes in this file are related to JDK-8038893
> and shown on the separate step 5

Oh, my fault there! Sorry.

>>
>> * Why was sun/security/ssl/KeyManagerFactoryImpl.java not modified? I
>> see a change in 8196584.
> 
> The only changes in this file - is code formatting. I decided to keep original
> JDK8u version because of no functional modification in the JDK11.0.7 version
> 

Hmm... I don't agree with this one. I suggest to align the file to
11.0.7 (doing file-replacement, to be consistent) and avoid a potential
conflict in the future due to formatting when backporting a patch to JDK-8.

>>
>> Some files are within sun/security/ssl but are not deleted by Step 0 and
>> are not deleted or modified by 8196584 either (because they don't exist
>> by the time 8196584 was applied, see 8038089):
>>
>> * classes/sun/security/ssl/KerberosClientKeyExchange.java
>> * classes/sun/security/ssl/Krb5Helper.java
>> * classes/sun/security/ssl/Krb5Proxy.java
>>
>> In the case of KerberosClientKeyExchange.java, I've seen it's modified
>> by Step 7. A few questions:
>>
>> * Did you file-replaced KerberosClientKeyExchange.java
>>  * If this file is not in 11u, why do we need it in 8u?
>>
>> * Are Krb5Helper.java and Krb5Proxy.java used?
>>  * I assume they are for the same reason than my 1st question, but want
>> to check just in case.
> 
> These files are related to RFC-2712 support. This feature is declared in JDK8u but deprecated in 11u
> Some customers could still use this feature, so we can not just remove it in JDk8u. As soon as JDK11 does not have this feature I've kept old files related to RFC-2712 and added missing functionality in the step 7

Oh, absolutely. Thanks for clarifying that.

Thanks,
Martin.-