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

[Volker Simonis]

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