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

[Neetish Pathak]

Benjamin/Matt,
Appreciate your tips and help so far.
Could you give me any pointers for placing my timestamps within the OpenSSl
code for right measurement for handshake. I am reading through the master
code. I think since in TLS 1.3 is session tickets are sent after handshake,
it would be ok to place a timestamp in the
*ossl_statem_server_pre_work *function
before *tls_finish_handshake* is called (This function is in state_srvr.c
which updates the stjatemachine I think). *It is only called for TLS 1.3*
*But I do not see any significant change when I put a timestamp here or at
the end of SSL_accept on my server application program.*
*Any help for the right location of time stamps will be appreciated.*

  *case* *TLS_ST_SW_SESSION_TICKET*:

*if* (SSL_IS_TLS13(s)) {

/*

 * Actually this is the end of the handshake, but we're going

 * straight into writing the session ticket out. So we finish
off

 * the handshake, but keep the various buffers active.

 */


/***End time
stamp*/

*struct* timespec end;

*clock_gettime*(CLOCK_MONOTONIC_RAW, );

uint64_t tempTimeEnd = end.tv_nsec / 1000;

*printf*("Handshake End time : %llu \n", tempTimeEnd);


*return* tls_finish_handshake(s, wst, 0);

} *if* (SSL_IS_DTLS(s)) {

/*

 * We're into the last flight. We don't retransmit the last
flight

 * unless we need to, so we don't use the timer

 */

st->use_timer = 0;

}


Thanks

BR,

Neetish

On Fri, Jun 16, 2017 at 5:54 PM, Benjamin Kaduk via openssl-users <
openssl-users@openssl.org> wrote:

> On 06/16/2017 05:36 PM, Matt Caswell wrote:
>
> 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?
>
>
> The risk of accidentally using psk_ke instead of psk_dhe_ke is noticeable,
> and in terms of concrete differences, there are additional requirements on
> external PSKs that the KDF and PSK identity must remain fixed across uses.
> That, combined with the potential for insufficient entropy during key
> generation (mentioned in section 2.2 of draft-20) seem to provide more
> openings for cryptographic attacks than for the full resumption flow.  It
> is probably fine for uses where the other properties of external PSKs are
> needed, but I'm not sure that the risk/reward balance favors using it just
> to get a speedup -- TLS 1.3 resumption should already be pretty fast.
>
> -Ben
>
> --
> 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

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

[Benjamin Kaduk via openssl-users]

On 06/16/2017 05:36 PM, Matt Caswell wrote:
>> 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?

The risk of accidentally using psk_ke instead of psk_dhe_ke is
noticeable, and in terms of concrete differences, there are additional
requirements on external PSKs that the KDF and PSK identity must remain
fixed across uses.  That, combined with the potential for insufficient
entropy during key generation (mentioned in section 2.2 of draft-20)
seem to provide more openings for cryptographic attacks than for the
full resumption flow.  It is probably fine for uses where the other
properties of external PSKs are needed, but I'm not sure that the
risk/reward balance favors using it just to get a speedup -- TLS 1.3
resumption should already be pretty fast.

-Ben
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Neetish Pathak]

Thanks Matt, Appreciate ur response and tips

On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell  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.
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.

Also, it is difficult to see all the messages for TLS 1.3 since all
messages after server hello are encrypted when I see on Wireshark. So I am
not sure where exactly session ticket info is exchanged

>
> >
> >> 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
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Matt Caswell]

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

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

[Benjamin Kaduk via openssl-users]

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

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

[Neetish Pathak]

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.

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.

Thanks
Best Regards,
Neetish

On Thu, Jun 15, 2017 at 2:30 AM, Matt Caswell  wrote:

>
>
> On 14/06/17 18:36, Neetish Pathak wrote:
> >
> > My calling sequence is :
> >
> > client.connectToServer();
> >
> > client.sslTcpConnect();
> >
> > client.sslTcpClosure();
>
> Does your client at any point attempt to read application data (i.e.
> through a call to SSL_read()/SSL_read_ex()?). It is not sufficient to
> just connect to a server via SSL_connect(). Because the session
> information is established *post* handshake in TLSv1.3, OpenSSL won't
> see it unless you actually try and read information from the connection.
>
> 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