Why put the test in a internal/java.base/.. sub-directory? I did not get the point why it cannot be in the general test/jdk/sun/security/ssl/HKDF directory. Using the "sun.security.ssl" in a test does not sound right to me, too.

I also run into testing failure:

TestHkdf.java:162: error: cannot find symbol
        HKDF kdfHkdf;
  symbol:   class HKDF
  location: class TestHkdf


On 2/22/2018 12:29 PM, Xuelei Fan wrote:
Updated to use package private HKDF implementation.

webrev (based on JDK-8185576):

webrev (including JDK-8185576):


On 2/20/2018 11:57 AM, Xuelei Fan wrote:

I'd like to invite you to review the TLS 1.3 full handshake implementation.  I appreciate it if I could have feedback before March 9, 2018.

In the "JDK-8185576: New handshake implementation" [1] code review around, I was trying to re-org the TLS handshaking implementation in the SunJSSE provider.  If you had reviewed that part, you can start from the following webrev that based on the update of JDK-8185576:

If you would like start from earlier, here is the webrev that contains the handshaking implementation re-org in JDK-8185576:

This changeset only implements the full handshake of TLS 1.3, rather then a fully implementation of the latest TLS 1.3 draft [2].

In this implementation, I removed:
1. the KRB5 cipher suite implementation.
Please let me know if you are still using KRB5 cipher suite.  I may not add them back if no objections.

2. OCSP stapling.
This feature will be added back later.

Resumption and key update, and more features may be added later.

Thanks & Regards,

[1]: http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html
[2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24

Reply via email to