Manuel Pégourié-Gonnard

> Since these functions are declared as “internal use”, arguably, we can remove them from Mbed TLS 2.2x before it becomes an LTS. There are associated `MBEDTLS_xxx_PROCESS_ALT` config options which...

[edit: this message is about 2.2x] If we can do that in a way that people using `PROCESS_ALT` don't have to change their code, sure. But I'm not convinced we...

Note that the relevance of FFDH-with-TLS-1.2 is currently quite low and will presumably only decrease over time as TLS 1.3 becomes dominant. Here are some stats from [a crawler on...

Based on this data, it is tempting to: - do nothing until 4.0, that is TLS-DHE-xxx ciphersuites keep using the legacy API even when `USE_PSA_CRYPTO` is enabled; - in 4.0,...

Reminder to self: advertise this plan on the mailing-list and ask for feedback.

Note: FFDH support will be added to TLS 1.3 (based on PSA) by #5979 - currently planned for the next quarter.

Sent an [email to the list](https://lists.trustedfirmware.org/archives/list/[email protected]/thread/S6CXDG56NXY2XF4QFXGULJ4XYZPTD6U2/) asking people to speak up if the above plan would cause trouble for them.

Labeling "api-break" based on the current plan, so that we don't forget about it when preparing 4.0.

> Just noting that this is in line with the upcoming TLS BCP -- see in particular the bit starting with "However, [...]" at https://www.ietf.org/archive/id/draft-ietf-uta-rfc7525bis-08.html#section-4.1-2.7.1 Note: the draft mentioned [is...

> More? E.g. are there buffer sizes that should become shorter now that only ECDH is supported for TLS 1.2 key exchange? I don't think extra work should be needed...