[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