[gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768)

[Development of GNU's TLS library]

Airtower commented on a discussion on doc/cha-gtls-app.texi:

>  and authentication keys using @funcref{gnutls_session_ticket_key_generate}.
>  Those keys should be associated with the GnuTLS session using
> - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly
> -(e.g., every few hours), to prevent them from becoming long-term keys which
> -if revealed could be used to decrypt all previous sessions.
> + at funcref{gnutls_session_ticket_enable_server}.
> +
> +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with
> + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys
> +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is
> +a necessary mechanism to prevent the keys from becoming long-term keys and as such preserve
> +forward-secrecy in the issued session tickets.
> +
> +The master key and the rotation key mechanism will both survive across forks. Forked processes
> +should rotate the key all at the same time and should generate exactly the same new keys.
> +This of course assumes all processes have the same time, which should be true.

Follow-up question that might become relevant: Would it be possible to share the master key across machines in a server cluster, assuming good clock synchronization? With TLS versions before 1.3 the cluster could use a shared session cache, but with ticket-based resumption only that's not going to work.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_106902959
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/20181005/3bfd5a7a/attachment.html>