<div dir="ltr"><div>Hi Xuelei,</div><div>What's the verdict on allowing legacy resumption on server even when EMS is enabled?</div><div><br></div><div>I was thinking of repurposing the current allowLegacyResumption flag for this; its name looks appropriate. However, it would be a change of behavior: currently we do not allow legacy resumption, and default value of allowLegacyResumption is true; we would either need to change the default, or change the default behavior. Would that be acceptable?<br></div><div>Regards,</div><div>Daniel<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pon., 8 kwi 2019 o 21:00 Xuelei Fan <<a href="mailto:xuelei.fan@oracle.com">xuelei.fan@oracle.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Daniel,<br>
<br>
Thanks for the quick feedback.  It helps me a lot.<br>
<br>
On 4/8/2019 9:59 AM, Daniel Jeliński wrote:<br>
> Hi Xuelei,<br>
> Thanks for your response!<br>
> My understanding is that legacy resumption = resumption of a session <br>
> that was established without extended master secret extension.<br>
> <br>
> Our Java application is a web server that is communicating with a large <br>
> number of clients, majority of which are built on top of OpenSSL 1.0.2, <br>
> which does not implement extended master secret. The clients send data <br>
> to server using frequent short-lived connections.<br>
> <br>
> When we use Java pre-8u161 or disable extended master secret <br>
> (/jdk/./tls/.useExtendedMasterSecret=false), the usual workflow is as <br>
> follows:<br>
> - client connects to server for the first time<br>
> - Full handshake happens, server creates a session ID and caches it<br>
> - session is established, data is transferred, connection is closed.<br>
> Later:<br>
> - subsequent client connection sends the cached session ID<br>
> - server resumes session using abbreviated handshake<br>
> - data is transferred, connection is closed.<br>
> <br>
> The same workflow with extended master secret enabled is as follows:<br>
> - client connects to server for the first time<br>
> - Full handshake happens, server creates a session ID and caches it<br>
> - session is established, data is transferred, connection is closed.<br>
> Later:<br>
> - subsequent client connection sends the cached session ID<br>
> - server checks that the session ID was established without extended <br>
> master secret and rejects it. Full handshake happens, server creates a <br>
> session ID and caches it<br>
> - session is established, data is transferred, connection is closed.<br>
> <br>
It sounds like a reasonable use case if applications want to take the <br>
risks.  I will think more about if we can make an enhancement to allow <br>
legacy resumption again if the extended master secret extension is not used.<br>
<br>
> Full handshake is much more expensive than abbreviated handshake, and <br>
> caching thousands of session IDs that are never reused creates a burden <br>
> on GC.<br>
> <br>
> My understanding of RFC 7627 is that rejecting abbreviated handshake <br>
> when extended master secret is not used makes sense only when we are <br>
> using client certificates for authentication. We are not using client <br>
> certificates in our communication, so we would prefer to resume sessions <br>
> whether extended master secret is used or not.<br>
> <br>
> TLS specification does not require the server to assign a session ID <br>
> when it knows it will not allow the client to resume session. We should <br>
> take advantage of that and not assign a session ID when the user does <br>
> not want to resume legacy sessions.<br>
> <br>
Good idea!<br>
<br>
Thanks,<br>
Xuelei<br>
<br>
> Let me know if that makes sense now.<br>
> Thanks,<br>
> Daniel<br>
> <br>
> <br>
> pon., 8 kwi 2019 o 17:43 Xuelei Fan <<a href="mailto:xuelei.fan@oracle.com" target="_blank">xuelei.fan@oracle.com</a> <br>
> <mailto:<a href="mailto:xuelei.fan@oracle.com" target="_blank">xuelei.fan@oracle.com</a>>> napisał(a):<br>
> <br>
>     Hi Daniel,<br>
> <br>
>     Was extended master secret extension used when legacy resumption is<br>
>     expected?  I did not get the point from JDK-8219568 and this<br>
>     description.  It would be helpful if there is a test code to reproduce<br>
>     the behavior.<br>
> <br>
>     Thanks,<br>
>     Xuelei<br>
> <br>
>     On 4/6/2019 11:36 AM, Daniel Jeliński wrote:<br>
>      > Hi all,<br>
>      > Ever since upgrading to Java 8u161 we are running into performance<br>
>      > problems that were caused by the implementation of extended<br>
>     master secret.<br>
>      ><br>
>      > First problem was described in 8219568; server does not allow<br>
>     resuming<br>
>      > legacy sessions even when jdk.tls.allowLegacyResumption is set to<br>
>     true.<br>
>      > Based on the mail archives of the original discussion [1] and the<br>
>      > release notes [2] I think this was not what was intended. Should the<br>
>      > setting (jdk.tls.allowLegacyResumption) on the server side work like<br>
>      > this instead?<br>
>      > allow = true -> proceed with abbreviated handshake<br>
>      > allow = false -> proceed with full handshake<br>
>      ><br>
>      > Documentation is ambiguous enough that we would probably not even<br>
>     need<br>
>      > to change it. Today it states that setting allowLegacyResumption to<br>
>      > false rejects abbreviated handshakes, without clarifying what the<br>
>      > default does.<br>
>      ><br>
>      > Second problem is that while the server rejects the abbreviated<br>
>      > handshake, it generates and caches a new session ID on every client<br>
>      > reconnect, effectively thrashing the session cache. These IDs are<br>
>     never<br>
>      > used. Should we stop generating session IDs when legacy<br>
>     resumption is<br>
>      > disabled?<br>
>      ><br>
>      > Regards,<br>
>      > Daniel<br>
>      ><br>
>      ><br>
>      > [1]<br>
>      ><br>
>     <a href="http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html" rel="noreferrer" target="_blank">http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html</a><br>
>      > [2] <a href="https://bugs.openjdk.java.net/browse/JDK-8192045" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8192045</a><br>
> <br>
</blockquote></div></div>