<div dir="ltr">Thanks Matt, Appreciate ur response and tips<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 16, 2017 at 3:36 PM, 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"><div class="HOEnZb"><div class="h5"><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 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>
</div></div>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></blockquote><div><br></div><div><br></div><div><font color="#0000ff">In my application program, I put start and stop timer before and after SSL_accept on server side and before and after SSL_connect on the client side.</font></div><div><font color="#0000ff">I am not sure how I can put timers at individual steps of Handshake using my client applications. I was assuming SSL and SSL_accept take care of the entire handshake process.</font></div><div><font color="#0000ff"><br></font></div><div><font color="#0000ff">Yes, I am testing on local machine. I will migrate my test to remote machines. But I am not really able to understand why TLS 1.3 is slower on my machine.</font></div><div><font color="#0000ff"><br></font></div><div><font color="#0000ff">Also, it is difficult to see all the messages for TLS 1.3 since all messages after server hello are encrypted when I see on Wireshark. So I am not sure where exactly session ticket info is exchanged</font> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
>> 2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS<br>
>> 1.3 RFC. How do we generate pre-shared keys in advance even without<br>
>> making the first connection. Can someone guide me in the right direction.<br>
<br>
</span>As Ben says this is not currently supported in master but there is<br>
pending WIP PR to add it.<br>
<span class=""><br>
>><br>
><br>
> The security properties of such "external" PSKs are substantially<br>
> different than the "ephemeral" PSKs used in resumption flows.<br>
<br>
</span>Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE<br>
based secret (assuming a suitable kex_mode is used). What do you see as<br>
the concern?<br>
<div class="HOEnZb"><div class="h5"><br>
Matt<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></div>