Hi Janos,

Thanks for your reply. I mean session resumption as described in RFC5246, for this the session id and master secret are (re)used from a previous session. Now I've dived a little deeper and I see that this is also implemented in mbedtls (see ssl_handle_id_based_session_resumption and mbedtls_ssl_cache_get).

So my initial idea to (optionally) remove the master secret (or session id) from the SSL session would not be a generic solution. I'll leave this as it is, probably only apply a patch on my local mbed tls clone.

Thanks for now, Maarten

From: Janos Follath Janos.Follath@arm.com Sent: woensdag 25 mei 2022 15:34 To: Maarten Meijer maarten.meijer@nedap.com; mbed-tls mbed-tls@lists.trustedfirmware.org Subject: Re: Clear master secret from mbedtls_ssl_session after handshake is ready

Hi Maarten,

I am not sure I understand what you mean. Could you please elaborate why you would want to disable session resumption?

(Did you mean renegotiation perhaps? Renegotiation has weaknesses and can already be disabled by commenting out the MBEDTLS_SSL_RENEGOTIATION in mbedtls_config.h)

Regards, Janos

From: Maarten Meijer via mbed-tls <mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org> Date: Wednesday, 25 May 2022 at 13:26 To: mbed-tls <mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org> Subject: [mbed-tls] Re: Clear master secret from mbedtls_ssl_session after handshake is ready Hi all,

I have found that for TLS session resumption the master secret is needed (see https://datatracker.ietf.org/doc/html/rfc5246#appendix-F.1.4). As such in general it should not be advised to remove the master secret from the SSL connection state.

Although session resumption is refactored under TLS v1.3 it is, as far as I see, still needed there.

So to conclude: No need to optimize anything around the master secret as it is now, but it could be beneficial to add a pre-compiler option (because of the security constraints) to mbed TLS to disable session resumption. I could come up with a proposal for something like that. Any thoughts on that?

Regards, Maarten

From: Maarten Meijer via mbed-tls <mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org> Sent: woensdag 11 mei 2022 15:47 To: mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] Clear master secret from mbedtls_ssl_session after handshake is ready

Hi all,

I'm using an mbedTLS server on a CPU with a small memory foot print. In a search to serve as many as possible TLS clients, I found that the mbedtls_ssl_session.master[48] structure member is still in memory after the handshake is over. (I filed an issue to start with, but was quickly directed to this mailing list, thanks to Tom Cosgrove. See Clear master secret from mbedtls_ssl_session after handshake is ready * Issue #5832 * Mbed-TLS/mbedtls (github.com)https://github.com/Mbed-TLS/mbedtls/issues/5832)

I'm wondering why this is needed. The `master` secret references I can find in the code are either related to the TLS handshake, or to serialization/deserialization. I am wondering whether it makes sense to serialize/deserialize the master secret but I'm not sure if it is a use case to support serialization of ongoing handshake operations.

Based on this 2 questions:

* Is the master secret relevant when the handshake is over? * Is the master secret really useful in serialization/deserialization? If so, I could use `MBEDTLS_SSL_CONTEXT_SERIALIZATION` in my eventual merge request to keep facilitating this.

Looking forward for relevant answers. Thanks in advance,

Maarten