Hi Xuelei,
<sun/security/ssl/SSLSessionImpl.java>
Will this.requestedServerNames ever be null? This field is initialized
in constructors with Collections.xxxList(...) method.
Are the two private fields "peerPrincipal" and "localPrincipal" really
used? There are two pkg private methods, setPeer/LocalPrincipal(...)
which sets their values, however, I don't see these two fields used
inside this class.
line 232, 240, 248, 264, - 273: Are we sure that we want to throw
RuntimeException? It seems too generic?
Quite some more fields are initialized in one constructor (line 191)
than the other one (line 175), e.g. peerCerts, compressionMethod,
negotiatedMaxFragLen (and more). Is such difference expected? The
ordering of initialization is also different which may be error prone
for future maintenance.
That's all I have for today. Will continue review next Monday.
Valerie
On 5/25/2018 4:45 PM, Xuelei Fan wrote:
Hi,
I'd like to invite you to review the TLS 1.3 implementation. I
appreciate it if I could have compatibility and specification feedback
before May 31, 2018, and implementation feedback before June 7, 2018.
Here is the webrev:
http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00
The formal TLS 1.3 specification is not finalized yet, although it had
been approved to be a standard. The implementation is based on the
draft version 28:
https://tools.ietf.org/html/draft-ietf-tls-tls13-28
For the overall description of this enhancement, please refer to JEP 332:
http://openjdk.java.net/jeps/332
For the compatibility and specification update, please refer to CSR
8202625:
https://bugs.openjdk.java.net/browse/JDK-8202625
Note that we are using the sandbox for the development right now. For
more information, please refer to Bradford's previous email:
http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html
Thanks & Regards,
Xuelei