Re: KeyUpdate Support

[Chuck Lever <chuck.lever@oracle.com>]

On 5/30/25 12:44 AM, Alistair wrote:
> On Thu, 22 May 2025, at 2:50 PM, Alistair wrote:
>> On 22/5/25 00:53, Chuck Lever wrote:
>>> On 5/21/25 10:50 AM, Benjamin Coddington wrote:
>>>> On 21 May 2025, at 8:53, Chuck Lever wrote:
>>>>
>>>>> On 5/21/25 2:43 AM, Hannes Reinecke wrote:
>>>>>> On 5/21/25 03:00, Alistair wrote:
>>>>>>> Currently tlshd uses `fork()` to fork the entire process after the kernel
>>>>>>> sends a netlink message. tlshd then calls the `tlshd_service_socket()`
>>>>>>> function from the child process and exits.
>>>>>>>
>>>>>>> This provides a high barrier between different handshake requests and
>>>>>>> ensures everything is freed when a handshake is complete.
>>>>>>>
>>>>>>> The problem with the current setup is that it makes it very difficult to
>>>>>>> share information between `tlshd_service_socket()` and the parent
>>>>>>> process.
>>>>>>> For security and system resources that's great, but it has the large down
>>>>>>> side of not supporting the TLS KeyUpdate.
>>>>>>>
>>>>>>> In the future we would like to support the TLS KeyUpdate mechanism, which
>>>>>>> means we need to maintain the `gnutls_session_t session` information
>>>>>>> for a
>>>>>>> connection to allow us to issue a KeyUpdate later on.
>>>>>>>
>>>>>>> AFAIK there is no way to re-create the `gnutls_session_t session` so
>>>>>>> we need
>>>>>>> to store it somewhere. We could pass it to the kernel and have the kernel
>>>>>>> pass it back. But `gnutls_session_t session` is gnutls internal state, so
>>>>>>> it's not fixed size making that tricky to do. Plus it will break if
>>>>>>> gnutls
>>>>>>> updates between a handshake and KeyUpdate.
>>>>>>>
>>>>>>> The other option is to pass the session data from the child process back
>>>>>>> to the tlshd parent process. The parent can then store the session data
>>>>>>> (maybe in a database?) and use it as required.
>>>>>>>
>>>>>>> I submitted the first step towards supporting that as a PR [1]. The PR
>>>>>>> changes the current `fork()` multi-process mechanism to a
>>>>>>> `g_thread_new()`
>>>>>>> threading mechanism.
>>>>>>>
>>>>>>> In the future this will allow us to maintain the gnutls_session_t session
>>>>>>> in the parent process, allowing KeyUpdate support. This could also be
>>>>>>> supported with `fork()` and IPC as well, but that is clunky-ier.
>>>>>>>
>>>>>>> My approach [1] hasn't been accepted, so now I'm trying to see what
>>>>>>> ideas other people have for supporting KeyUpdate?
>>>>>>>
>>>>>>> 1: https://github.com/oracle/ktls-utils/pull/95
>>>>>>>
>>>>>> Hehe. I knew it would come up.
>>>>>> The reason we didn't implement it for now is that there's an overlap
>>>>>> with session reset. In NVMe any error will be causing a session reset,
>>>>>> which then will trigger a TLS handshake. And, what's more, with secure
>>>>>> concatenation we even generate a new set of TLS PSKs on every reset.
>>>>>> All of this is transparent to the upper layers, so they will only see
>>>>>> a (hopefully short) delay.
>>>>>> Additionally, with the current in-kernel TLS the connection will be
>>>>>> reset when the IV values are being changed, which again would trigger
>>>>>> a reconnect on the NVMe side.
>>>>>>
>>>>>> So not that easy.
>>>>>>
>>>>>> But if you insist on doing that, why don't you use the keyring to
>>>>>> store the temporary session key? That is persistent, and required
>>>>>> to be present for tlshd to work ...
>>>>> I was about to suggest something similar. Depending on what APIs are
>>>>> available in (or might be added to) gnuTLS, preserve the session's
>>>>> metadata in a key ring, and return the key's serial number to the
>>>>> kernel as part of the handshake result. When requesting a KeyUpdate,
>>>>> pass that serial number back to tlshd.
>>
>>
>> Ok, that seems pretty do-able
>>
>>
>> I'm working on some kernel patches now that start to implement the 
>> basics of this
>>
>>
>>>>>
>>>>> It would help if someone could review gnuTLS to see what is available
>>>>> now, and start a discussion with that community if we need a capability
>>>>> or API that doesn't already exist. (Eg: translate a gnutls_session_t
>>>>> object into a JSON string; translate a JSON string into a
>>>>> gnutls_session_t object)
>>>> I believe gnutls_session_{get,set}_data will serialize the session object.
>>>> It would be trivial to store in a key.
>>> Oh, very cool.
>>
>>
>> I didn't see that previously. That does seem to do exactly what we need
> 
> A follow up on this, gnutls_session_{get,set}_data doesn't seem to store enough
> data to easily resume a session to handle a KeyUpdate. So we probably
> need to modify gnutls to get this working.

Thanks for checking.

I would start by joining the gnutls development community and asking
them for advice.


> Alistair
> 
>>
>>
>>>
>>>
>>>>> The other aspect of this is that tlshd will have to prevent saved
>>>>> session state from growing without bound. Probably the kernel will have
>>>>> to notify tlshd when a session is terminated so that associated saved
>>>>> session state can be discarded.
>>> It occurs to me that tlshd doesn't need to be involved in this aspect.
>>> The kernel can delete a key by serial number when it notices that a
>>> session has been permanently terminated.
>>
>>
>> Oh good point. That will help with freeing memory.
>>
>>
>> Alistair
>>
>>
>>>
>>>
>>
>>


-- 
Chuck Lever