[gnutls-devel] GnuTLS | add support for 0-RTT (!775)

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Fri Nov 2 16:31:48 CET 2018


Nikos Mavrogiannopoulos started a new discussion on lib/tls13/anti_replay.c:

> +	_gnutls_write_uint32(anti_replay->start_time.tv_nsec, p);
> +	p += 4;
> +	memcpy(p, id->data, id->size);
> +	p += id->size;
> +	key.data = buffer;
> +	key.size = p - buffer;
> +
> +	if ((session->internals.db_check_func ||
> +	     session->internals.db_retrieve_func) &&
> +	    session->internals.db_store_func) {
> +		db_check_func = session->internals.db_check_func;
> +		db_retrieve_func = session->internals.db_retrieve_func;
> +		db_store_func = session->internals.db_store_func;
> +		db_ptr = session->internals.db_ptr;
> +	} else {
> +		db_check_func = storage_check;

What do you think on avoiding having a memory back-end for simplicity? I worry that this is something that apps will want to tweak anyway, for memory usage/performance of it and it may become over-engineered later to cover all possible scenarios. gnutls-serv has already such a memory back-end, and I'd expect any other servers which support resumption already do as well.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114129497
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20181102/ded2fb9c/attachment.html>


More information about the Gnutls-devel mailing list