Hi Matt, Thanks Could you help with following queries 1) On the blogpost for TLS1.3, you mentions the following in the session section 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 SSL_CTX_remove_session() to mark a session as non-resumable (and remove it from the cache) once it has been used.
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. 2) Can you suggest some places to put a time stamp in OpenSSL code. Thanks Best Regards, Neetish On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell <m...@openssl.org> wrote: > > > On 16/06/17 23:51, Neetish Pathak wrote: > > Thanks Matt, Appreciate ur response and tips > > > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell <m...@openssl.org > > <mailto:m...@openssl.org>> wrote: > > > > > > > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote: > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote: > > >> Hello > > >> Thanks > > >> I tried reading some content from the server side and I observed > the > > >> new_session_cb getting invoked in that case on the client side. I > > >> understand that may be due to delayed NewSession info transfer > from > > >> server side to client side. But it is helpful for saving the > session > > >> info on the client side. (Thanks Matt for your input) > > >> > > >> However, now I have two concerns > > >> > > >> 1) I see that latency for handshake with session resumption in > > TLS 1.3 > > >> has not improved as much as it improves for TLS 1.2 > > >> With TLS 1.3, I observed that resumption brings down the > connection > > >> time from 2.5 ms to 1.2-1.3 ms > > >> while with TLS 1.2 (using either session IDs or tickets), the > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms. > > >> > > >> The whole code is similar for running the two experiments with > only > > >> max TLS version changed. Can someone comment on the latency > > >> measurements for the two cases. > > >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. > Please > > >> comment. > > >> > > > > > > Are you seeing a HelloRetryRequest in the resumption flow? That > would > > > add an additional round trip. (Your numbers in milliseconds are of > > > course not transferrable to other systems; round-trips is an > easier to > > > understand number.) RFC 5246 and draft-ietf-tls-tls13-20 both have > > > message-flow diagrams that show the number of round trips in > various > > > handshake flows. > > > > Care should also be taken about when you are starting your "timer" > and > > when you stop it, e.g. if you stop your timer after the session > ticket > > data has been received by the client then this is not a "fair" test > (the > > connection is ready for data transfer earlier than the arrival of the > > session ticket). > > > > I would expect to see the TLS1.3 latency for a full handshake to be > > around the same as for a TLS1.2 resumption handshake. With a TLS1.3 > > resumption only marginally different. There are the same number of > round > > trips for a TLS1.3 full handshake as that there are for a resumption > > one. The primary difference is that the Certificate message is not > sent > > (which can be quite a large message). > > > > Your timings suggest you are testing this over a LAN where the > effects > > of network latency are going to be relatively low. The real benefits > > from fewer round trips will really be seen when network latency is > more > > significant. > > > > > > > > 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. > > That should be fine (my worry was that you might also be including the > subsequent session ticket transfer). > > > 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. > > > > 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. > > If you are on a local machine I would not expect a significant speed up > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of > round-trips required in order to avoid unnecessary network latency. If > you are on a local machine then there isn't any significant network > latency anyway - so timings are presumably dominated by the CPU > intensive tasks. You should make sure that you are comparing like with > like, i.e. the same ciphers, key lengths, key exchange algorithms, > curves etc between TLSv1.2 and TLSv1.3. Differences in any one of these > could obviously have significant performance impacts. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
