Hi Martin,

Checking the history, the handling of the MTU doesn't seem to have changed since fragmentation support started in 2.13. At the time, I think handshake message fragmentation wasn't supported, but I don't see what difference setting ssl_context.handshake.mtu as opposed to ssl_context.mtu would have made for the handshake. (It would have caused the handshake to use a smaller MTU than application messages, but it's not clear why you'd want that.)

We can add a function to specifically set the handshake MTU if there's a use for it, but it's not clear to me what the use would be. Unless you can tell us why mbedtls_ssl_set_mtu() doesn't work for you, I think our answer is to just use that.

Best regards,

One small addition…

I think there is no need to expose handshake mtu any further, and simply rely on mbedtls_ssl_set_mtu to properly configure all communication of a given session, assuming the handshake will actually use the configured ssl mtu.

thanks, Martin

On 12. 9. 2022, at 17:34, Martin Man mman@martinman.net wrote:

Hi Gilles,

thanks for the detailed explanation.

I think I figured out why I actually used only handshake mtu and not mbedtls_ssl_set_mtu.

In our app we support quick exchange of very little information over bluetooth backed link, and I think I saw the handshakes failing in cases where bluetooth lowered the MTU to around 512 bytes. And I definitely remember I saw handshakes not progressing. So I lowered the handshake mtu, and it fixed the problem, and I ignored the mbedtls_ssl_set_mtu or was afraid (read: did not understand what it does) to actually use it.

As you explained it, I think there is no need to expose it any further, and simply rely on mbedtls_ssl_set_mtu to properly configure all communication of a given session…

thanks for now for your help, Martin

...

On 8. 9. 2022, at 23:21, Gilles Peskine via mbed-tls mbed-tls@lists.trustedfirmware.org wrote:

Hi Martin,

Checking the history, the handling of the MTU doesn't seem to have changed since fragmentation support started in 2.13. At the time, I think handshake message fragmentation wasn't supported, but I don't see what difference setting ssl_context.handshake.mtu as opposed to ssl_context.mtu would have made for the handshake. (It would have caused the handshake to use a smaller MTU than application messages, but it's not clear why you'd want that.)

We can add a function to specifically set the handshake MTU if there's a use for it, but it's not clear to me what the use would be. Unless you can tell us why mbedtls_ssl_set_mtu() doesn't work for you, I think our answer is to just use that.

Best regards,

-- Gilles Peskine Mbed TLS developer

On 19/07/2022 14:51, Martin Man via mbed-tls wrote:

...

Hi guys,

I use mbedtls for years (since 2.10 IIRC) upgrading to latest available as time goes by. For DTLS that is.

I remember a case in the past where a link would have a small MTU (around 500 bytes) and I had to tune ssl_context.handshake.mtu to a lower value to successfully complete handshakes.

I do not remember exactly why, but I did not want to actually restrict maximum value via mbedtls_ssl_set_mtu, maybe it was even ignored back then for handshakes… but

Now when working on migration to 3.2.1 (gave some time to 3x releases to stabilize) I noticed that the whole ssl_context.handshake member is now private and inaccessible, which I guess is fine.

Could somebody with more knowledge of the code recommend what is the best strategy for DTLS app where MTU may not always be 1400?

thanks a lot for your time, Martin

-- mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org

secretimap--- via mbed-tls mbed-tls@lists.trustedfirmware.org wrote: > Finally: from what I've read, it seems that the move to fully integrate > PSA into mbedtls is both ongoing and incomplete. Would you recommend > using MBEDTLS_USE_PSA_CRYPTO in its current state, or is it still a > little way away (say, 12 months?) from being properly ready to use in > commercial projects?

A very good question, for which I'd also like the answer :-)

At the RIOT-OS Summit this Sept, we mostly agreed that we want the PSA API as our crypto API, and that we might even remove/hide all other interfaces.

Having mbedtls available ubiquitously is key to a number of security efforts.

On 27/09/2022 17:17, secretimap--- via mbed-tls wrote:

Finally: from what I've read, it seems that the move to fully integrate PSA into mbedtls is both ongoing and incomplete. Would you recommend using MBEDTLS_USE_PSA_CRYPTO in its current state, or is it still a little way away (say, 12 months?) from being properly ready to use in commercial projects?

The parts of MBEDTLS_USE_PSA_CRYPTO that are already implement are ready for production. Right now, you should switch on MBEDTLS_USE_PSA_CRYPTO if you want to benefit from PSA drivers, or if you want to get in early on the future. The main reason not to enable MBEDTLS_USE_PSA_CRYPTO is if you are not using any drivers: code size is critical: currently, if you are not using a driver, the USE_PSA code paths involve more glue code than the legacy code paths (we'll work on that once all the USE_PSA code paths are implemented).

USE_PSA_CRYPTO is progressing quickly. You can see what is currently available at https://github.com/Mbed-TLS/mbedtls/blob/development/docs/use-psa-crypto.md (or the same file in released versions of Mbed TLS starting with 3.1.0). You can see the remaining work that is underway or planned for the short term on the epic board at https://github.com/orgs/Mbed-TLS/projects/1 — look at the columns with “Use PSA” in their name.

Best regards,