Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8

Mon Dec 9 10:55:53 UTC 2019

Hi Volker/Iris,

Firstly, thanks to Oracle for offering to update the JDK8u specs and
contribute the necessary changes to re-implement the ALPN and RSASSA-PSS
APIs.

That said, I can see Volker's point here. Putting the changes into both
8u40 and 8u252 appears to add an extra redundant step as far as the
OpenJDK project is concerned. Is there a reason why the 8u40 backport is
needed? (more specifically, why does it need to be adopted as the RI?)
Is there any reason for Oracle to do the 8u40 backport before
backporting to 8u252 and publishing the latter changes?

Of course, if the open project is provided with the relevant 8u252
changes in a timely manner then I don't suppose the answers to the above
questions are critical. What dominates is the project's ability to
respond in time 1) to assimilate the ALPN and RSASSA-PSS API changes and
2) to add TLS 1.3 support on top of those changes. I'll leave it to
others (including my Red Hat colleagues) who are more au fait with TLS
and the jdk8u schedule to comment on that issue.

regards,

Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill

On 06/12/2019 13:34, Volker Simonis wrote:
> Hi Iris,
> 
> I've just realized that my first answer to this mail unintentionally
> went to you only (instead of being posted to the list). I'll therefore
> repost to the list, because I think this may be of interest to the
> others as well. Please feel free to re-post your initial answer to the
> list as well and sorry for the inconvenience :)
> 
> On Wed, Nov 6, 2019 at 10:54 PM Iris Clark <iris.clark at oracle.com> wrote:
>>
>> The TLS 1.3 protocol is rapidly gaining adoption on the Internet, and thus is
>> important even for legacy applications running on JDK 8.
>>
> 
> Thanks for addressing this issue. I think it will be well perceived by
> the OpenJDK community. Please find further comments inline:
> 
>> Backporting TLS 1.3 to JDK 8 would not, of itself, require API changes, but
>> API changes are required in order to backport two technologies necessary for
>> TLS 1.3, ALPN [1] and RSASSA-PSS [2]:
>>
>>   - The TLS ALPN (Application-Layer Protocol Negotiation) extension was added
>>     to Java SE 9 with JEP 244 (TLS Application-Layer Protocol Negotiation
>>     Extension (ALPN)) [3].  It allows negotiation of an application-layer
>>     protocol value during the TLS handshake which may be used during the
>>     selection of other TLS protocol parameters.  HTTP/2 [4] and other modern
>>     network protocols use ALPN. [5,6]
>>
>>   - Support for the RSASSA-PSS (RSA Signature Scheme with Appendix --
>>     Probabilistic Signature Scheme) algorithm was added to Java SE 11.  It is
>>     a cryptographic signature scheme used for secure data transmission which
>>     was initially standardized as part of PKCS#1 v2.1 [7].  An API is
>>     necessary to enable third-party provider support. [8,9]
>>
>> To enable efforts to backport TLS 1.3 to JDK 8, I'll shortly propose a
>> Maintenance Release of the Java SE 8 Platform JSR [0] in the JCP to backport
>> the ALPN and RSASSA-PSS APIs.  This will require updates to the Specification,
>> the Reference Implementation (RI), and the TCK, which I and my colleagues at
>> Oracle will provide.  I expect the Maintenance Release process to complete by
>> February 2020, in time for these changes to be merged into the April security
>> releases of JDK 8.
>>
>> In order to reduce risk we'd like to base the open-source RI on OpenJDK 8u40
>> [10], the RI for the previous two Maintenance Releases, rather than the most
>> recent OpenJDK 8 update release.
> 
> Which risks do you want to reduce here? It seems that basing the RI on
> 8u40 mainly reduces the risk of not completing the Maintenance Release
> process in time for the April security release.
> 
> For me, the much bigger risk would be to complete the Maintenance
> Release process in time but fail to deliver the new standard relevant
> features (plus the TLS 1.3 implementation) in the subsequent OpenJDk
> 8u security release because this would actually make OpenJDk 8u non
> Java SE 8 compliant.
> 
> So I'd instead propose to base the RI on the latest released update
> version of OpenJDK 8 at that time as that would give all downstream
> consumers of OpenJDK 8 the chance to easily comply to the
> specification changes introduced by the MR.
> 
>> We propose to name this "8u41," which is a
>> bit odd but does convey the special nature of any RI build: It's not meant for
>> production use, since it's never updated with security fixes.
>>
>> If it's not too much work then we'll also contribute the changes required by
>> the MR to the next appropriate OpenJDK 8 release, most likely 8u252.
> 
> See above. Why duplicate the work and do the changes for both, 8u40
> and maybe 8u252 if you could do them just as well in 8u252 alone?
> 
>> We do
>> not plan to contribute a backport TLS 1.3 to OpenJDK 8.
> 
> This will be already be a big enough effort for the OpenJDK 8u
> project, so we should try to avoid the extra effort caused by the
> required MR changes.
> 
> Thank you and best regards,
> Volker
> 
>>
>> Comments?
>>
>> Iris
>>
>> [0]: https://openjdk.java.net/projects/jdk8/spec/
>> [1]: https://bugs.openjdk.java.net/browse/JDK-8230977
>> [2]: https://bugs.openjdk.java.net/browse/JDK-8230978
>> [3]: https://openjdk.java.net/jeps/244
>> [4]: https://tools.ietf.org/html/rfc7540
>> [5]: https://bugs.openjdk.java.net/browse/JDK-8144093
>> [6]: https://bugs.openjdk.java.net/browse/JDK-8170282
>> [7]: https://tools.ietf.org/html/rfc3447
>> [8]: https://bugs.openjdk.java.net/browse/JDK-8190180
>> [9]: https://bugs.openjdk.java.net/browse/JDK-8206864
>> [10]: https://hg.openjdk.java.net/jdk8u/jdk8u40
> 