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. > >> 2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS >> 1.3 RFC. How do we generate pre-shared keys in advance even without >> making the first connection. Can someone guide me in the right direction. As Ben says this is not currently supported in master but there is pending WIP PR to add it. >> > > The security properties of such "external" PSKs are substantially > different than the "ephemeral" PSKs used in resumption flows. Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE based secret (assuming a suitable kex_mode is used). What do you see as the concern? Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
