I have a strong preference for the library, the tests and companion programs to build out of the box on officially supported platforms. On platforms that don't work out of the box, users should be able to drop in platform support code in the form of #defines or extra modules to link with.
Ok, we don't have an official list of supported platforms. But inasmuch as we do have officially supported platforms, they include Linux and other modern Unix-like or POSIX environments, Windows, and Mbed OS. Mbed OS is a special case because Mbed TLS is part of the build tree there, so the mbedtls tree doesn't have to contain Mbed OS support.
This doesn't mean that the library should have a timing module. I think the timing wrappers that the library needs, i.e. mbedtls_timing_{get,set}_delay, should be in platform.c.
For platform features that are only used by test or sample programs, I think we should have a separate platform support file, and separate #defines so that you can build the library even if you can't build all the programs. For example, it makes sense to build DTLS support without having the timing functions used by the benchmark program.
-- Gilles Peskine Mbed TLS developer
On 21/04/2020 10:46, Manuel Pegourie-Gonnard via mbed-tls wrote:
Hi all,
So personally I'm quite strongly inclined to remove timing.c from the library, and move most of its content elsewhere, with one possible exception:
- mbedtls_timing_set_delay() and mbedtls_timing_get_delay() are an example
implementation (only for Unix and Windows) of timer callbacks for DTLS, only used in programs/ssl/*.c
Since timer callbacks are a hard requirement for using DTLS, and it seems quite desirable to be able to support DTLS out of the box at least on some platforms, I was thinking this pair of function (and the associated context type) could be kept in the library, in a new module that would be called something like ssl_dtls_timer.c.
This would be somewhat similar to ssl_cookies.c, ssl_tickets.c and ssl_cache.c: they all provide implementations of callbacks that can be used with the main SSL/(D)TLS module, but users are obviously free to compile them out and use their own implementation if the one we provide does not meet their needs.
As it happens, all three of these support modules work best if MBEDTLS_HAVE_TIME is defined, but can work without it.
For the new ssl_dtls_timer.c I'm suggesting, the situation would be different: the module could have a hard dependency on MBEDTLS_HAVE_TIME, but work better on selected platforms (say, C11, POSIX and Windows) where we know how to access sub-second timing information. (Or alternatively, have a hard dependency on C11-or-Posix-or-Windows.)
For the record, mbedtls_ssl_conf_handshake_timeout() accepts timeout values in milliseconds, but recommended values for use over the general internet start at 1 second: https://tools.ietf.org/html/rfc6347#section-4.2.4.1 So it might make sense to provide this module even when we only have second resolution - we'd just have to work out how the timer function would behave when passed sub-second values. (My first thought it rounding up to the next second would be quite OK.)
What do you'all think? Personnally, I don't have a strong opinion between the three following options, though I have a slight preference for the first one:
- Provide ssl_dtls_timer.c in the library with hard dep on HAVE_TIME
and enhanced features with C11/Posix/Windows. 2. Provide ssl_dtls_timer.c in the library with hard dep on C11/Posix/Windows. 3. Move it all out of the library and let the thing live somewhere under programs/ as it's only used by example/testing programs.
Note though that we could also choose to go with option 3 for Mbed TLS 3.0, see how it goes, and later switch to option 2 or 1 if we want, as adding modules can be done at any time. (In the same vein, we could start with 2 and switch to 1 at any time as well.)
Regards, Manuel.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.