<div dir="ltr">Hi Matt,<div>Thanks</div><div>Could you help with following queries</div><div><br></div><div>1) <span style="font-size:12.8px">On the blogpost for TLS1.3, you mentions the following in the session section</span></div><div style="font-size:12.8px"><span style="font-family:"PT Serif",Georgia,Times,"Times New Roman",serif;font-size:18.4px;background-color:rgb(248,248,248)">The specification recommends that applications only use a session once (although this is not enforced). For this reason some servers send multiple session messages to a client. To enforce the “use once” recommendation applications could use </span><code style="padding:0px 0.3em;border:1px solid rgb(221,221,221);font-family:Menlo,Monaco,"Andale Mono","lucida console","Courier New",monospace;line-height:1.5em;font-size:0.8em;vertical-align:baseline;display:inline-block;color:rgb(85,85,85);border-radius:0.4em">SSL_CTX_remove_session()</code><span style="font-family:"PT Serif",Georgia,Times,"Times New Roman",serif;font-size:18.4px;background-color:rgb(248,248,248)"> t<wbr>o mark a session as non-resumable (and remove it from the cache) once it has been used.</span><br></div><div style="font-size:12.8px"><span style="font-family:"PT Serif",Georgia,Times,"Times New Roman",serif;font-size:18.4px;background-color:rgb(248,248,248)"><br></span></div><div style="font-size:12.8px"><span style="background-color:rgb(248,248,248)"><font face="PT Serif, Georgia, Times, Times New Roman, serif">I am a bit confused here as to why "use once" is recommended. How will resumption be ensured then ? I get a PSK in first connection and use it again for all the other connections.</font></span></div><div style="font-size:12.8px"><span style="background-color:rgb(248,248,248)"><font face="PT Serif, Georgia, Times, Times New Roman, serif"><br></font></span></div><div style="font-size:12.8px"><span style="background-color:rgb(248,248,248)"><font face="PT Serif, Georgia, Times, Times New Roman, serif"><br></font></span></div><div style="font-size:12.8px"><span style="background-color:rgb(248,248,248)"><font face="PT Serif, Georgia, Times, Times New Roman, serif">2) Can you suggest some places to put a time stamp in OpenSSL code. </font></span></div><div style="font-size:12.8px"><span style="background-color:rgb(248,248,248)"><font face="PT Serif, Georgia, Times, Times New Roman, serif"><br></font></span></div><div style="font-size:12.8px"><span style="background-color:rgb(248,248,248)"><font face="PT Serif, Georgia, Times, Times New Roman, serif">Thanks</font></span></div><div style="font-size:12.8px"><span style="background-color:rgb(248,248,248)"><font face="PT Serif, Georgia, Times, Times New Roman, serif">Best Regards,</font></span></div><div style="font-size:12.8px"><span style="background-color:rgb(248,248,248)"><font face="PT Serif, Georgia, Times, Times New Roman, serif">Neetish</font></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 16/06/17 23:51, Neetish Pathak wrote:<br>
> Thanks Matt, Appreciate ur response and tips<br>
><br>
> On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:matt@openssl.org">matt@openssl.org</a>>> wrote:<br>
><br>
><br>
><br>
> On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:<br>
> > On 06/16/2017 01:58 PM, Neetish Pathak wrote:<br>
> >> Hello<br>
> >> Thanks<br>
> >> I tried reading some content from the server side and I observed the<br>
> >> new_session_cb getting invoked in that case on the client side. I<br>
> >> understand that may be due to delayed NewSession info transfer from<br>
> >> server side to client side. But it is helpful for saving the session<br>
> >> info on the client side. (Thanks Matt for your input)<br>
> >><br>
> >> However, now I have two concerns<br>
> >><br>
> >> 1) I see that latency for handshake with session resumption in<br>
> TLS 1.3<br>
> >> has not improved as much as it improves for TLS 1.2<br>
> >> With TLS 1.3, I observed that resumption brings down the connection<br>
> >> time from 2.5 ms to 1.2-1.3 ms<br>
> >> while with TLS 1.2 (using either session IDs or tickets), the<br>
> >> connection time reduces from 2.5 ms to 0.5-0.6 ms.<br>
> >><br>
> >> The whole code is similar for running the two experiments with only<br>
> >> max TLS version changed. Can someone comment on the latency<br>
> >> measurements for the two cases.<br>
> >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please<br>
> >> comment.<br>
> >><br>
> ><br>
> > Are you seeing a HelloRetryRequest in the resumption flow? That would<br>
> > add an additional round trip. (Your numbers in milliseconds are of<br>
> > course not transferrable to other systems; round-trips is an easier to<br>
> > understand number.) RFC 5246 and draft-ietf-tls-tls13-20 both have<br>
> > message-flow diagrams that show the number of round trips in various<br>
> > handshake flows.<br>
><br>
> Care should also be taken about when you are starting your "timer" and<br>
> when you stop it, e.g. if you stop your timer after the session ticket<br>
> data has been received by the client then this is not a "fair" test (the<br>
> connection is ready for data transfer earlier than the arrival of the<br>
> session ticket).<br>
><br>
> I would expect to see the TLS1.3 latency for a full handshake to be<br>
> around the same as for a TLS1.2 resumption handshake. With a TLS1.3<br>
> resumption only marginally different. There are the same number of round<br>
> trips for a TLS1.3 full handshake as that there are for a resumption<br>
> one. The primary difference is that the Certificate message is not sent<br>
> (which can be quite a large message).<br>
><br>
> Your timings suggest you are testing this over a LAN where the effects<br>
> of network latency are going to be relatively low. The real benefits<br>
> from fewer round trips will really be seen when network latency is more<br>
> significant.<br>
><br>
><br>
><br>
> In my application program, I put start and stop timer before and after<br>
> SSL_accept on server side and before and after SSL_connect on the client<br>
> side.<br>
<br>
</div></div>That should be fine (my worry was that you might also be including the<br>
subsequent session ticket transfer).<br>
<span class=""><br>
> I am not sure how I can put timers at individual steps of Handshake<br>
> using my client applications. I was assuming SSL and SSL_accept take<br>
> care of the entire handshake process.<br>
><br>
> Yes, I am testing on local machine. I will migrate my test to remote<br>
> machines. But I am not really able to understand why TLS 1.3 is slower<br>
> on my machine.<br>
<br>
</span>If you are on a local machine I would not expect a significant speed up<br>
in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of<br>
round-trips required in order to avoid unnecessary network latency. If<br>
you are on a local machine then there isn't any significant network<br>
latency anyway - so timings are presumably dominated by the CPU<br>
intensive tasks. You should make sure that you are comparing like with<br>
like, i.e. the same ciphers, key lengths, key exchange algorithms,<br>
curves etc between TLSv1.2 and TLSv1.3. Differences in any one of these<br>
could obviously have significant performance impacts.<br>
<div class="HOEnZb"><div class="h5"><br>
Matt<br>
<br>
--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><br>
</div></div></blockquote></div><br></div>