[openssl-users] Session Ticket Support in Openssl TLS 1.2

Tue Jun 20 09:09:00 UTC 2017

On 19/06/17 19:11, Neetish Pathak wrote:
> 2) Can you suggest some places to put a time stamp in OpenSSL code. 

I agree with Ben's responses to all your other questions. For this
question, I'm not sure what you are trying to achieve? Starting before
SSL_accept/SSL_connect and finishing after they return should be fine.
Or are you looking for a breakdown of where the time is going?

Matt

> 
> Thanks
> Best Regards,
> Neetish
> 
> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell <matt at openssl.org
> <mailto:matt at 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 <matt at openssl.org <mailto:matt at openssl.org>
>     > <mailto:matt at openssl.org <mailto:matt at 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
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
> 
> 
> 
> 