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