JDK-8219568 extended master secret performance problems

[Xuelei Fan]

Hi Daniel,

Was extended master secret extension used when legacy resumption is 
expected?  I did not get the point from JDK-8219568 and this 
description.  It would be helpful if there is a test code to reproduce 
the behavior.

Thanks,
Xuelei

On 4/6/2019 11:36 AM, Daniel Jeliński wrote:
> Hi all,
> Ever since upgrading to Java 8u161 we are running into performance 
> problems that were caused by the implementation of extended master secret.
> 
> First problem was described in 8219568; server does not allow resuming 
> legacy sessions even when jdk.tls.allowLegacyResumption is set to true. 
> Based on the mail archives of the original discussion [1] and the 
> release notes [2] I think this was not what was intended. Should the 
> setting (jdk.tls.allowLegacyResumption) on the server side work like 
> this instead?
> allow = true -> proceed with abbreviated handshake
> allow = false -> proceed with full handshake
> 
> Documentation is ambiguous enough that we would probably not even need 
> to change it. Today it states that setting allowLegacyResumption to 
> false rejects abbreviated handshakes, without clarifying what the 
> default does.
> 
> Second problem is that while the server rejects the abbreviated 
> handshake, it generates and caches a new session ID on every client 
> reconnect, effectively thrashing the session cache. These IDs are never 
> used. Should we stop generating session IDs when legacy resumption is 
> disabled?
> 
> Regards,
> Daniel
> 
> 
> [1] 
> http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8192045