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

[Neetish Pathak]

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 <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>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170619/dfd92160/attachment.html>