Re: about JDK-8186628

[Ivan Gerasimov]

I'll go ahead with a review of the enhancement request JDK-8202086 
shortly on this list.


And we'll still need to decide what has to be done in the earlier 
releases of JDK.


With kind regards,

Ivan





On 4/20/18 10:06 AM, nezih yigitbasi wrote:
Ivan, thanks for the information. Any ideas about when one of these 
solutions can be released?


Nezih

2018-04-20 9:22 GMT-07:00 Ivan Gerasimov >:


Hello Nezih!

This issue is still being discussed off-list.
There have been two approaches proposed so far:  1) improve the
session cache and 2) provide an option to turn the cache off
completely.

The former one is good by itself, so I filed an enhancement
request [1] with a link to proposal made by Peter Levart [2].
However, as this is an enhancement, it seems unlikely it's going
to be backported to earlier releases of JDK.

With kind regards,
Ivan

[1] https://bugs.openjdk.java.net/browse/JDK-8202086

[2]

http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html




On 4/18/18 9:32 PM, nezih yigitbasi wrote:

Hi,
We are hitting the scalability problem of the SSL session cache
in production that JDK-8186628 is addressing.
I see that JDK-8186628 has not been updated since Nov'17, so I
just wanted to get information about what the current plans are
regarding that issue.

Thanks,
Nezih


-- 
With kind regards,

Ivan Gerasimov




--
With kind regards,
Ivan Gerasimov

Re: about JDK-8186628

[nezih yigitbasi]

Ivan, thanks for the information. Any ideas about when one of these
solutions can be released?

Nezih

2018-04-20 9:22 GMT-07:00 Ivan Gerasimov :

> Hello Nezih!
> This issue is still being discussed off-list.
> There have been two approaches proposed so far:  1) improve the session
> cache and 2) provide an option to turn the cache off completely.
>
> The former one is good by itself, so I filed an enhancement request [1]
> with a link to proposal made by Peter Levart [2].
> However, as this is an enhancement, it seems unlikely it's going to be
> backported to earlier releases of JDK.
>
> With kind regards,
> Ivan
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8202086
> [2] http://mail.openjdk.java.net/pipermail/security-dev/2017-
> November/016512.html
>
> On 4/18/18 9:32 PM, nezih yigitbasi wrote:
>
> Hi,
> We are hitting the scalability problem of the SSL session cache in
> production that JDK-8186628 is addressing.
> I see that JDK-8186628 has not been updated since Nov'17, so I just wanted
> to get information about what the current plans are regarding that issue.
>
> Thanks,
> Nezih
>
>
> --
> With kind regards,
> Ivan Gerasimov
>
>

Re: about JDK-8186628

[Ivan Gerasimov]

Hello Nezih!

This issue is still being discussed off-list.
There have been two approaches proposed so far:  1) improve the session 
cache and 2) provide an option to turn the cache off completely.


The former one is good by itself, so I filed an enhancement request [1] 
with a link to proposal made by Peter Levart [2].
However, as this is an enhancement, it seems unlikely it's going to be 
backported to earlier releases of JDK.


With kind regards,
Ivan

[1] https://bugs.openjdk.java.net/browse/JDK-8202086
[2] 
http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html 



On 4/18/18 9:32 PM, nezih yigitbasi wrote:

Hi,
We are hitting the scalability problem of the SSL session cache in 
production that JDK-8186628 is addressing.
I see that JDK-8186628 has not been updated since Nov'17, so I just 
wanted to get information about what the current plans are regarding 
that issue.


Thanks,
Nezih


--
With kind regards,
Ivan Gerasimov

Re: Code Review Request: TLS 1.3 full handshake (JDK-8196584)

[Xuelei Fan]

Thanks for the review.  The update will be in next webrev.

Thanks,
Xuelei

On 3/23/2018 12:35 PM, Adam Petcher wrote:

Note: I am not a Reviewer. This is not a Review.

I took a look at some of the files that I was working in during my 
extension development. I just have a few minor comments:


TransportContext.java, line 428: It's not clear why the outbound 
direction is closed here. Consider adding more comments to describe what 
is going on.


SessionId.java, lines 54: need to clone()?
SessionId.java, lines 81-87: you could do Arrays.hashCode(sessionId)

SSLExtension.java, line 441: The word "trad" is used here and in other 
places in the file. Should this be "trade"?


KeyShareExtension.java, lines 264-265: I think you can remove the 
comment, and the code is fine as it is. The problem of large ClientHello 
messages should be addressed when we add support for HelloRetryRequest.



On 2/22/2018 3:29 PM, Xuelei Fan wrote:

Updated to use package private HKDF implementation.

webrev (based on JDK-8185576):
  http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01

webrev (including JDK-8185576):
  http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01

Thanks,
Xuelei

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

Hi,

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:

 http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00

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

 http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00


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,
Xuelei

[1]: 
http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html 


[2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24