On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak <npath...@ncsu.edu> wrote:
> 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). >> > Yes Matt, when I switch to remote machines and test my application programs, I see that TLS 1.3 is faster than TLS 1.2 in the first connection (around same time as resumption time in TLS 1.2) itself and there is marginal or no improvement in the subsequent connections even on using resumption. Does this mean that resumption in TLS 1.3 is bringing not much benefit in terms of latency. It makes sense because round trips count for resumption or no resumption is 1 in TLS 1.3. The only benefit with resumption is that the client can now send zero-RTT data. (early data). However, if we consider the overall latency in handshake, it is going to be the same equivalent to 1 round trip. Is my understanding correct ? Is there any way to enable early data or it gets activated by default once the pre-shared keys are available at both the client and server ends ? I believe session resumption as a concept doesn't hold that much value from TLS 1.3 onwards since 1-RTT is directly achieved in TLS 1.3 first connection. Do you agree? > > >> > 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