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

Hi everyone,

We have mbedtls 3.2.1 working fine under FreeRTOS on our embedded devices (which is great), but I've recently been asked to integrate the ATECC608A PSA driver via MBEDTLS_USE_PSA_CRYPTO, so that we can use opaque asymmetric keys etc.

I tried doing this today, but various PSA definitions seem to be missing (e.g. PSA_ECC_CURVE_SECP256R1), which makes me think I'm missing ARM's PSA crypto library itself. Where can I download this from, or is this embedded inside mbed OS?

Also: the ATECC608A PSA example driver that I found on the Internet seems quite limited and a bit old (e.g. it's using some deprecated macros). Is there an updated (and actively developed) version of this code anywhere I should be using instead?

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?

Thanks for your help, Nick

Hello,

The ATECC608A driver was a proof-of-concept for the first draft version of the secure element driver interface. The driver interface has changed considerably since this first draft, and we have not ported the driver to the current interface.

The driver is for Mbed TLS running on Mbed OS, and requires the chip support package provided by the hardware manufacturer (https://github.com/MicrochipTech/cryptoauthlib). There are quick start instructions at https://github.com/ARMmbed/mbed-os-example-atecc608a . I think the driver still works with the latest version of Mbed OS, but it's maintained by a different team at Arm and I haven't been following it lately.

The Mbed TLS team intends to create and maintain a new example driver, for the current driver interface. It will likely be available by the end of Q1 next year. We don't know yet whether it will be for the same secure element. (If someone else intends to make an ATECC driver, please let us know so we don't duplicate effort!)

Please note that we never intended this example driver for production, so it may have functionality gaps, an inability to suppress debug output, etc. However, to the best of my knowledge, it accomplishes its basic purpose and is secure (as much as unmaintained software can be secure).

Best regards,