- mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] 3.0 plans - move net.c out of the library

by Manuel Pegourie-Gonnard

Hi again, In the first email of the thread I tried giving a fair exposition of the question, now I'm going to give my personal opinion. Similarly to what I suggested for timing.c, I'm inclined to remove net.c as such, move most of its content (net_bind(), net_accept(), etc.) out of the library (most probably into a new file in programs/ssl, shared by SSL examples), and keep in the library only the 3 functions that can be used as SSL callbacks (and a supporting context type), but in a new module named for example ssl_io_sockets.c. This would also be similar to the other SSL modules that provide a reference/example implementation of some SSL callback but can easily be disabled (or jsut disregarded) in favour of a custom implementation for custom needs or unsupported platforms. Just like the current net_sockets.c, this new reduced module would probably only be supported on platforms with sockets, which is Posix platforms and Windows. Advantages include: - Reduce the amount of code and API surface in the library. Things like binding and accepting are hardly related to (D)TLS so there is little justification for having them in the library. Also, things in the library are bound by API stability rules which are sometimes a constraint. - It would clarify that we're not providing a general-purpose socket abstraction, as general socket management would be out of the library, and only the bits for plugging a socket into our SSL layer would be in the library. - (By the way currently net_sockets.h includes ssl.h, so it's already quite specific to our SSL module rather than generic, but moving the remaining bits of it into the SSL namespace would make that clearer.) - User would still have the convenience (on supported platforms) of ready-for-use callbacks. If you have an application already working with sockets without TLS, then we provide all the bits needed to turn that into an application using TLS on top of those sockets. I think that would be a good compromise between convenience for users, and reduced surface for the library. Regards, Manuel.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move certs.c out of the library

by Hanno Becker

Hi, I support this. Could certs.c live in `tests/data_files`? We should also make sure this file is automatically synced with the actual CRT and key files in that directory. There is a script which does that, but IIRC it's not called as part of the CI, which lead to certs.c and the data files get out of sync multiple times in the past. Best Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Manuel Pegourie-Gonnard via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Monday, April 20, 2020 10:49 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [mbed-tls] 3.0 plans - move certs.c out of the library Hi all, In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: should we move certs.c out of the library? [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ Currently the X.509 library includes test certificates and keys, which are enabled by default in config.h - `MBEDTLS_CERTS_C`. These are used in the following places: - in library/x509.c in mbedtls_x509_self_test() - in tests/suites/test_suite_ssl.function - in programs/fuzz and programs/ssl In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we'd like to remove certs.h and the certificates it contains from the library (except perhaps one static cert for mbedtls_x509_self_test()). Tests and example programs that need built-in certificates could still get them using any mechanism, included a file certs.c similar to the current one - but this file would no longer live in library or be included when building libmbedx509. Reasons include: - Including test certificates and keys in the library provides little value, as users will want to use their own certificates and keys anyway. - Shipping private keys as part of the library is bad practice, even under the `mbedtls_test_` sub-namespace. There's a slight risk that some users could use them for prototyping and then inadvertently keep using unsafe private keys in production. If you disagree or have concerns, please speak up! Also, if want to suggest ideas for where the replacement to library/certs.c should live or how it could be maintained, now's a good time as well! Regards, Manuel. -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls 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.

6 years, 2 months

2
1
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Manuel Pegourie-Gonnard

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: 1. 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.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Manuel Pegourie-Gonnard

Hi Torsten, [I'm assuming didn't mean to reply on the list and not just to me, so I'm replying on the list.] > On 20/04/2020 11:51, Manuel Pegourie-Gonnard via mbed-tls wrote: >> For reference, this module includes the following functions, which are used >> in the following places: >> >> - mbedtls_timing_hardclock() implements cycle counting (on selected >> architectures, not including M-class), used only in >> programs/test/benchmark.c > > I used mbedtls_timing_hardclock() for my own benchmarking experiments on > Linux and Windows, but couldn't get it to run on the target machine. So > I've use my own ms counter instead. So, it could be easily removed as > part of the library. > Good to know, thanks for sharing this data point. > Question: How do you want to do the benchmarking instead? With the same > code, but outside the library? > Yes, I was thinking that the functions that are only used in benchmark.c could be defined in benchmark.c, and the functions that are only used in udp_proxy.c could be defined in udp_proxy.c. (Or actually for the latter, we might want to start using them in ssl_client2.c and ssl_server2.c as well, as including millisecond timestamps in the debug output would be usefull to debug some issues. In that case, we'll probably put those functions in a new file, used by udp_proxy, ssl_client2 and ssl_server2 (just like query_config.c is currently used by ssl_client2, ssl_server2 and query_compile_time_config).) Regards, Manuel.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] Some thoughts towards mbed TLS 3.0

by Manuel Pegourie-Gonnard

Hi Torsten, > this will be a long mail. Sorry for that. > On the contrary, thank you so much for this extensive and well though-out feedback, that's very helpful! I'll try to complement Gilles's reply, and skip the points he already answered unless I have something to add, as I'm generally in full agreement with what he wrote. > 3. For certification and evaluation purposes I need some test vectors > for each crypto function on target. While I know about the > comprehensive self-test program I'm now talking about built-in > functions like mbedtls_sha512_self_test(), etc to be enabled with > #define MBEDTLS_SELF_TEST. > > These self-tests are very different in coverage. For SHA-384 and > SHA-512 they are fine, for HMAC-SHA-384 and HMAC-SHA-512 I couldn't > find any as well as for HKDF-HMAC-SHA-256 (in RFC 5869) or > HKDF-HMAC-SHA-384/512 (official test vectors difficult to find). > AES-CTR and AES-XTS are only tested with key length 128 bit, not with > 256 bit. AES-CCM is not tested with 256 bit and even for 128 bit, > the test vector from the standard NIST SP 800-38C with long > additional data is not used. > The builtin self-test for GCM is the best I've seen with mbedtls: > all three key lengths are tested as well as the IUF-interface and > the comfort function. Bravo! > Indeed so far we don't have clear guidelines on self-test functions, and we should try to have more consistency here. Since this is incremental, backwards-compatible improvements, it can be done at any time (unlike some API improvements that can only be done when preparing major versions). Contributions in this area are certainly welcome! > 7. While at Elliptic Curve Cryptography: I assume that some of you > know that projectives coordinates as outer interface to ECC are > dangerous, see David Naccache, Nigel P. Smart, Jacques Stern: > Projective Coordinates Leak, Eurocrypt 2004, pp. 257–267. Yes, and as it happens this was revisited recently by researchers, and brought back to our attention: https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advi… > you have Jacobian coordinates, i.e. projective coordinates, as outer > interface. In the comment, its is noted that only the affine part is > used, but can this be assured? In all circumstances? > In practice, I'm pretty confident this is the case, because both ecp_normalize_jac() and ecp_normalize_mxz() set Z to 1, these functions are always called before returning data, and if we forgot to call those functions, we'd get incorrect X and Y coordinates and fail unit test and interop tests. But as a matter of principle, I agree that exposing Jacobian coordinates in the API was a poor decision. Fortunately, we already intended to start phasing out the existing ECP interface in 3.0 (to which extend exactly is still to be discussed), and in the future is should be fully removed in favour of the PSA Crypto API, which doesn't have this problem. > 8. In my personal opinion the definition > [...] > mbedtls_ecp_keypair; > > is dangerous. Why not differentiate between private and public key > and domain parameters? I agree, and I think it's a generally accepted opinion in the crypto implementation community that private and public keys should be clearly distinguished from one another, for example by using distinct types (in typed languages). This is by the way a long-standing problem that existed in the RSA module from the start, and when ECC was added it followed a similar pattern. Again, I think the transition of the PSA Crypto API is going to be the answer here, as it will provide much cleaner key management. > 9. Regarding ECC examples: I found it very difficult that there isn't > a single example with known test vectors as in the relevant crypto > standards, i.e. FIPS 186-4 and ANSI X9.62-2005, with raw public > keys. What I mean are (defined) curves, public key value Q=(Qx,Qy) > and known signature values r and s. In the example ecdsa.c you > generate your own key pair and read/write the signature in > serialized form. In the example programs/pkey/pk_sign.c and > pk_verify.c you use a higher interface pk.h and keys in PEM format. > > So, it took me a while for a program to verify (all) known answer > tests in the standards (old standards as ANSI X9.62 1998 have more > detailed known answer tests). One needs this interface with raw > public keys for example for CAVP tests, see The FIPS 186-4 Elliptic > Curve Digital Signature Algorithm Validation System (ECDSA2VS). > > 11. In the moment, there is no single known answer tests for ECDSA > (which could be activated with #define MBEDTLS_SELF_TEST). I > wouldn't say that you need an example for every curve and hash > combination, as it is done in ECDSA2VS CAVP, but one example for > one of the NIST curves and one for Curve25519 and - if I have a > wish free - one for Brainpool would be fine. And this would solve > #9 above. > I might be misunderstanding, but isn't the function ecdsa_prim_test_vectors() in tests/suites/test_suite_ecdsa.function close to what you're looking for? I mean, except for the fact that it's not in the self-test function, and that it's using data from RFCs rather than from NIST or ANSI? But I agree this is a bit messy and could be made cleaner. Also, if you ever feel like contributing your dream self-test function for ECDSA as PR, this will be a very welcome contribution! > 13. Feature request: Since it was irrelevant for my task (only > verification, no generation) I didn't have a detailed look a your > ECC side-channel countermeasures. But obviously you use the same > protected code for scalar multiplication in verify and sign, > right? Wouldn't it be possible to use Shamir's trick in > verification with fast unprotected multi-scalar multiplication. In > the moment, mbedtls_ecdsa_verify is a factor 4-5 slower than > mbedtls_ecdsa_sign, while OpenSSLs verify is faster than sign. > Yes, this was done to save both on code size and developer time, but I agree it's suboptimal for performance. As Gilles wrote, as a general rule we tend to favour code size and security/maintainability over performance, but in that instance if we provide an option for a verify-only ECDSA build (which I agree we should), then we're likely to reach smaller code size by having a standalone unprotected implementation of multi-scalar multiplication, so that would probably be a great option: better performance _and_ smaller code. Unfortunately we're already quite busy with other things, so this kind of optimisation will probably have to wait for a bit more, but we're taking good note of the suggestion and will try to implement it in the future. Again, thanks for this comprehensive and useful feedback. Regards, Manuel.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Torsten Schuetze

On 20/04/2020 11:51, Manuel Pegourie-Gonnard via mbed-tls wrote: > [ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ] > > Currently the crypto library includes a module called timing.c, enabled by > default in config.h (but disabled by config.py baremetal), containing various > functions related to timing (not to be confused with the time abstration > present in the platorm module). > > In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, > we're considering removing (parts of) this module from the library, and > moving its parts to a variety of other places, such as example programs (or > a library/file shared by them, like the current query_config mechanism). > > For reference, this module includes the following functions, which are used in > the following places: > > - mbedtls_timing_hardclock() implements cycle counting (on selected > architectures, not including M-class), used only in > programs/test/benchmark.c I used mbedtls_timing_hardclock() for my own benchmarking experiments on Linux and Windows, but couldn't get it to run on the target machine. So I've use my own ms counter instead. So, it could be easily removed as part of the library. Question: How do you want to do the benchmarking instead? With the same code, but outside the library? Torsten

6 years, 2 months

1
0
0 0

3.0 plans - move net.c out of the library

by Manuel Pegourie-Gonnard

Hi all, [ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ] Currently the SSL/TLS library includes a module called net_sockets.c (formerly net.c), enabled by default in config.h (but disabled by config.py baremetal), that contains some networking functions based on POSIX or Windows sockets, including functions suitable for use as I/O callbacks with our SSL/TLS modules. Those functions are used only in example/testing programs, but nowhere in the library itself. In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we're considering removing (parts of) this module from the library, and moving its parts to a variety of other places, such as example programs (or a library/file shared by them, like the current query_config mechanism). Reasons for removing this module from the library include: - overall the module is less portable and perhaps of lesser quality than the rest of the library - it's currently entirely untested on Windows (despite being very platform-specific) - there are often confusions about whether the module is meant to be a general-purpose networking library, or just provide basic support for our example and test, as well a simple prototypes - it's not our core area of expertise, let's do one thing and to it well Reasons for keeping (parts of) it in the library include: - having mbedtls_net_recv{,_timeout}() and mbedtls_net_send() available right in the library makes it easier to test and develop prototype - this module is listed as a component in our high-level design document [2], so perhaps removing it from the library can be seen as a bigger change? [2]: https://tls.mbed.org/high-level-design What do you think? Should we remove the entire module from the library, keep it all, or just keep some parts? In that case, which parts and where? Regards, Manuel.

6 years, 2 months

1
0
0 0

3.0 plans - move timing.c out of the library

by Manuel Pegourie-Gonnard

[ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ] Currently the crypto library includes a module called timing.c, enabled by default in config.h (but disabled by config.py baremetal), containing various functions related to timing (not to be confused with the time abstration present in the platorm module). In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we're considering removing (parts of) this module from the library, and moving its parts to a variety of other places, such as example programs (or a library/file shared by them, like the current query_config mechanism). For reference, this module includes the following functions, which are used in the following places: - mbedtls_timing_hardclock() implements cycle counting (on selected architectures, not including M-class), used only in programs/test/benchmark.c - mbedtls_timing_get_timer() is a millisecond counter (only for Unix and Windows), used only in programs/test/udp_proxy.c - mbedtls_set_alarm() is an abstraction of alarm() (only for Unix and Windows), used only in programs/test/benchmark.c - 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 Reasons for removing this module from the library include: - overall the module is less portable and of lesser quality than the rest of the library - it's also very hard to test and we've lost a lot of time and energy to that, with very limited success - it doesn't really belong in libmbedcrypto - it's not our core area of expertise, let's do one thing and to it well Reasons for keeping (parts of) it in the library include: - for mbedtls_timing_set_delay() and mbedtls_timing_get_delay(): they're convenient to have for DTLS examples and prototyping, we could keep them in some place in libmbedtls (not libmbedcrypto). What do you think? Should we remove the entire module from the library, or keep some parts? In that case, which parts and where should they live? Regards, Manuel.

6 years, 2 months

1
0
0 0

3.0 plans - move certs.c out of the library

by Manuel Pegourie-Gonnard

Hi all, In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: should we move certs.c out of the library? [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ Currently the X.509 library includes test certificates and keys, which are enabled by default in config.h - `MBEDTLS_CERTS_C`. These are used in the following places: - in library/x509.c in mbedtls_x509_self_test() - in tests/suites/test_suite_ssl.function - in programs/fuzz and programs/ssl In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we'd like to remove certs.h and the certificates it contains from the library (except perhaps one static cert for mbedtls_x509_self_test()). Tests and example programs that need built-in certificates could still get them using any mechanism, included a file certs.c similar to the current one - but this file would no longer live in library or be included when building libmbedx509. Reasons include: - Including test certificates and keys in the library provides little value, as users will want to use their own certificates and keys anyway. - Shipping private keys as part of the library is bad practice, even under the `mbedtls_test_` sub-namespace. There's a slight risk that some users could use them for prototyping and then inadvertently keep using unsafe private keys in production. If you disagree or have concerns, please speak up! Also, if want to suggest ideas for where the replacement to library/certs.c should live or how it could be maintained, now's a good time as well! Regards, Manuel.

6 years, 2 months

1
0
0 0

Session resumption + PSKs in Mbed TLS 3.X

by Hanno Becker

Hi all, I would like to bring up the following: (How) Shall the APIs for PSKs and TLS session resumption be modified in Mbed TLS 3.0? The motivation for this question is the consolidation of PSKs, ticket-based resumption and session-id-based resumption in TLS 1.3. Now, while there will be no TLS 1.3 support in Mbed TLS 3.0 as it stands, I think it would be beneficial to make the API amenable to TLS 1.3 as much as possible already now. Finding the right API here is non-trivial, and I'll describe first how the current API works and how TLS 1.2 and 1.3 differ, before making suggestions on how the Mbed TLS 3 API might look like. The mail is therefore quite long, but I hope you'll bear with me. # Session Resumption in Mbed TLS 2.X Recall how resumption works in Mbed TLS 2.X on the client: 1. Establish a connection as usual 2. Store established session for later re-use `mbedtls_ssl_session_save()` saves connection parameters relevant for session resumption in an instance of `mbedtls_ssl_session`. Optional: 2.1: Serialize session for offline storage 2.2: Deserialize session 3. Loading a stored session `mbedtls_ssl_session_load()` is called on the stored session after initialization and before running the handshake via `mbedtls_ssl_handshake()`. 4. Connect using stored session Run `mbedtls_ssl_handshake()` as usual. To my knowledge, the following is transparent to the user: * The means by which resumption is achieved, which can be either id- or ticket-based. * Whether the session was resumed or not - there is a silent fallback to a full handshake when session resumption is rejected by the server. On the server, ticket- and id-based resumption are configured independently as follows: - ID-based resumption is controlled via `mbedtls_ssl_conf_session_cache()` - Ticket-based resumption is controlled via `mbedtls_ssl_conf_session_tickets_cb()`. # PSKs in Mbed TLS 2.X Coming to PSKs: First, recall that, under the hood, resumed connections establish a master secret purely on the basis of a previous master secret, without resorting to asymmetric crypto. The same is true for PSK-based connections, and this observation is embodied in TLS 1.3 which, as mentioned, consolidates resumption and PSKs. In TLS 1.2, though, PSKs and session resumption are different, and consequently Mbed TLS handles them through a separate API `mbedtls_ssl_conf_psk()`, which takes the PSK identifier and the PSK itself. Side-question: Should this apply to the SSL configuration or the SSL context? It seems to me that somebody might want to run multiple PSK-based connections with different PSKs, but same configuration otherwise. At the moment, this would require a configuration per connection. Maybe this decision of what belongs at the level of the config could be thoroughly discussed independently? # PSKs in TLS 1.3 In TLS 1.3, all kinds of resumptions are hanlded ander the umbrella of PSKs: The client offers PSK identities in its ClientHello, the server picks one or leaves it, and the master secret for the connection is derived from the PSK associated with the PSK identity. Underlying this is some form of translation `PSK-Identity -> PSK` on the server which allows to derive the PSK from the PSK identity. How this mapping is realized is entirely implementation-specific, but it can take at least the following forms, giving back all forms of session resumption: - 'PSK Identity -> PSK' via database lookup: This subsumes classical PSKs and ID-based resumption, since the data necessary to resume a session is stored on the server. - 'PSK Identity -> PSK' via AEAD: The PSK can be encoded in the PSK identity itself by using some authenticated encryption of the PSK as the PSK identity, the key for which resides on the server. This subsumes Ticket-based resumption. There are the following noteworthy differences, though: 1. In TLS 1.2, the server provides a 'PSK identity hint' and the client picks a particular PSK identity. In TLS 1.3, the client offers a _list_ of PSKs, and the server picks one or none. 2. In TLS 1.2, the server can issue only a single session ticket. In TLS 1.3, the server can issue as many session tickets as he wishes, and the client can use any of those for later session resumption. This has the following consequences for the API: 1. The PSK-configuration API must allow the configuration of multiple PSKs on the client. 2. There must be a means to export more than one session ticket for later resumption. # API considerations for Mbed TLS 3.X ## Part 1: Load/Save API In essence, keep the flow of `mbedtls_ssl_session_load/save()`, but make the following adjustments. Whether the target structure remains `mbedtls_ssl_session` and how it looks like internally isn't relevant at this point and is up to discussion. 1. It must be possible 'save' a session multiple times, which in TLS 1.3 amounts to exporting the tickets issued by the server one-by-one. This can be realized in a variety of ways, for example: - Allow calling `mbedtls_ssl_session_save()` multiple times, and modify its semantics from the idempotent nature of Mbed TLS 2.X to iterating through the available tickets, and returning an error when no more tickets are available. This has the benefit that it likely requires no code change for users migrating from Mbed TLS 2.X, since a change is needed only when an application stores a single session multiple times, which could be done by calling `mbedtls_ssl_session_save()` multiple times before, while now one would need to call it once and manually replicate the obtained session structure. On the negative side, this wastes memory for applications not interested in session resumption, or those that only need a single ticket. We don't want the server to be able to flood the client with arbitrarily many tickets. - Allow registering a callback that's triggered whenever a new ticket arrives. The drawback of this is that it is larger deviation from the Mbed TLS 2.X API. On the positive side, applications that don't need tickets, or only need a limited number of such, can simply drop further tickets and thereby prevent allocating RAM for them. 2. It must be possible to 'load' multiple sessions, meaning that the client should offer any of them to the server for resumption. ## Part 2: Consolidation with PSK Make it possible to setup an `mbedtls_ssl_session` (or whatever it will be called) structure manually from an externally PSK provisioned PSK, and allow loading this session for resumption as above, via one of potentially many calls to `mbedtls_ssl_session_load()`. There are multiple variants to this, for example: 1. Make `mbedtls_ssl_session` transparent so users can build it manually by filling the respective fields. 2. Provide a helper API to build a session from a PSK. The old API `mbedtls_ssl_conf_psk()` can then be _derived_ from this for convenience, building a session from the provided PSK and loading it, in a single API. Before going into further details and making the mail even longer: What do you think of this approach? Do you see alternatives? Best, Hanno 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.

6 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls