Hi Ankita,

Regarding DTLS with hello verify, I think the most likely explanation for why it takes longer is it adds a round-trip. That is, the client has to send its Hello, then get a cookie back from the server, then send its Hello again with the cookie included, and only then we can continue to a normal handshake. Usually the number of round-trips is a pretty important factor in how long a handshake takes - actually TLS 1.3 make a lot of effort in order to reduce the number of round trips.

I don't think resetting the SSL context is an expansive operation, so I'd be a bit surprised if that was the main cause for the delay.

Regarding the toolchain, I think providing your own stdint.h and inttypes.h is a good workaround (assuming the files you provide are suitable of course). I would highly recommend running all the tests, including the selftest program. Some toolchains provide versions of snprintf (and friends) that are not compliant, and that's something we test in the selftest program (as well as a few other sanity checks about int sizes IIRC).

To be clear: this is just my opinion, and we don't officially support building Mbed TLS with a pre-C99 toolchain.

I'm not familiar with Diab compiler, but looking at its homepage, it does advertise support for C99 and even C11, so my top recommendation would still be to enable that support when building Mbed TLS.

Best regards, Manuel. ________________________________ From: Ankita Hatmode ankita.hatmode@agiliad.com Sent: 09 September 2025 07:08 To: Manuel Pegourie-Gonnard Manuel.Pegourie-Gonnard@arm.com Cc: mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org Subject: Re: [mbed-tls] DTLS handshake with and without hello verify request

Hi Manuel,

Thanks for the clarification.

I evaluated the DTLS handshake with and without the hello verify request enabled. In our setup, the handshake with a hello verify request takes more time compared to a handshake without it. Probably, resetting the context and again attempting a handshake is adding up to this overhead time. That's why we are trying to find a way to complete a handshake with hello verify request enabled but not resetting the context.

In terms of toolchain, we are using the Diab compiler(Windriver) and our environment is limited to C89 compliance. At present, we are compiling source code only for C89 . To address the missing headers, we have added local copies of stdint.h and inttypes.h in our include path.

Could you please advise if there are recommended approaches or caveats when using mbedTLS in a strictly C89 environment with such workarounds?

Thanks & regards, Ankita Hatmode.

On Thu, Sep 4, 2025 at 4:00 PM Manuel Pegourie-Gonnard <Manuel.Pegourie-Gonnard@arm.commailto:Manuel.Pegourie-Gonnard@arm.com> wrote: Hi Ankita,

Regarding DTLS cookies, resetting the SSL context and setting the client transport ID is indeed mandatory and how things are supposed to work when you enable hello verify request. Setting the client transport ID is necessary as that is used to compute and verify the cookie value. Resetting the SSL context is actually a feature: it means you don't have to maintain state on the server before the client reachability at the claimed address is established.

See https://mbed-tls.readthedocs.io/en/latest/kb/how-to/dtls-tutorial/#server-si... for context and details.

Why is resetting the context and setting the client transport ID a problem for you?

Regarding your second question, yes, we do require a toolchain with at least some C99 features, including those two headers. See https://github.com/Mbed-TLS/mbedtls/tree/mbedtls-3.6?tab=readme-ov-file#tool...

May I ask what toolchain you are using that doesn't have that level of C99 support? Perhaps your toolchain is just defaulting to C89 but that can be changed to C99?

Regards, Manuel. ________________________________ From: Ankita Hatmode via mbed-tls <mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org> Sent: 01 September 2025 06:28 To: mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org> Subject: [mbed-tls] DTLS handshake with and without hello verify request

Hi Team,

I am working on exploring DTLS handshake using the mbedtls-3.6.4 version on our embedded platform. I enabled the hello verify request feature and got stuck at hello verify request state on server side if I don't reset the ssl context and don't set the client transport ID. I want to know if there is any way to complete a handshake by bypassing the reset of ssl context and setting the client transport ID.

Also, our environment only supports C89 constructs. I could not see inttypes.h in the mbedtls-3.6.4, is there any specific reason to remove this file? I am getting compilation errors without inttypes.h and stdint.h. Is there any macro to be enabled to support the c89 compilation in mbedtls stack?

Looking forward to your response.

Thanks and regards, Ankita Hatmode

------------------------------------------------------------------------------------------------------------------------- Disclaimer: This email message including any attachments is confidential, and may be privileged and proprietary to Agiliad. If you are not the intended recipient, please notify us immediately by replying to this message and destroy all copies of this message including any attachments. You are NOT authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. Thank you. ------------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------------------- Disclaimer: This email message including any attachments is confidential, and may be privileged and proprietary to Agiliad. If you are not the intended recipient, please notify us immediately by replying to this message and destroy all copies of this message including any attachments. You are NOT authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. Thank you. ------------------------------------------------------------------------------------------------------------------------