Re: Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak <npathak2@xxxxxxxx>]

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, &end);

            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@xxxxxxxxxxx> 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