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.
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.
The security properties of such "external" PSKs are substantially
different than the "ephemeral" PSKs used in resumption flows. I do
not think I can recommend their use in the general case when
resumption flows are available.
Regardless, external PSK support is still a work in progress:
https://github.com/openssl/openssl/pull/3670
-Ben
|
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
