Hi Radhika,
We do not plan to extend support for Mbed TLS 2.16 beyond the three year support period.
We do plan to release a 2.x LTS (probably 2.28) alongside the final 2.16 release, so that we always have an LTS available.
Regards
Dave Rodgman
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Radhika Jandhyala via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Reply to: Radhika Jandhyala <radhikaj(a)microsoft.com>
Date: Monday, 22 November 2021 at 10:50
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] End of Life of LTS branch 2.16
Hi,
I am a maintainer for https://github.com/openenclave/openenclave. We include mbedtls 2.16 as a submodule in our project.
Reading the article below, it states that 2.16 support will last at least till Dec 2021. Will you continue to support 2.16 in 2022?
https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16
We are specifically interested in CVE fixes being backported to 2.16 and the timeframe where that will continue. Is there an updated timeline for this?
We do plan to upgrade to 3.0 in early 2022, but we anticipate that will take some effort due to breaking changes.
Thank you very much!
Radhika
Hi,
Mbed TLS 2.16 LTS is approaching the end of its support period – it was originally announced that it would be maintained for at least 3 years up until the end of 2021 – and currently there is no other LTS branch.
To ensure that there is no period of time without a supported LTS branch, we plan to release 2.28 LTS in the near future (which will have the usual 3 year support period). We will continue supporting 2.16 LTS until this is available. The expectation is that as 2.28 will be API-compatible with 2.16, users of 2.16 LTS will be able to upgrade to 2.28 very easily.
Progress towards 2.28 LTS can be followed here: https://github.com/orgs/ARMmbed/projects/18#column-15836286
Dave Rodgman
Hi,
I am a maintainer for https://github.com/openenclave/openenclave. We include mbedtls 2.16 as a submodule in our project.
Reading the article below, it states that 2.16 support will last at least till Dec 2021. Will you continue to support 2.16 in 2022?
https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16
We are specifically interested in CVE fixes being backported to 2.16 and the timeframe where that will continue. Is there an updated timeline for this?
We do plan to upgrade to 3.0 in early 2022, but we anticipate that will take some effort due to breaking changes.
Thank you very much!
Radhika
Hi,
We'd like to announce a change we intend to make: starting with Mbed TLS 3.1, it will no longer be possible to build with TLS, X.509, or PK without support for PSA Crypto.
Details: currently, use of PSA Crypto APIs from the TLS, X.509 and PK layers is controlled by the option MBEDTLS_USE_PSA_CRYPTO. When this option is disabled (which is the default), it's possible to build without MBEDTLS_PSA_CRYPTO_C. Starting with 3.1, we intend to start making TLS, X.509 and PK use PSA Crypto unconditionally, so MBEDTLS_PSA_CRYPTO_C will be automatically enabled in the build as soon as TLS, X.509 or PK is enabled.
Impact: for users who already build with PSA Crypto enabled (the default), no impact. For users who currently disable MBEDTLS_PSA_CRYPTO_C in their configuration, starting with 3.1 there will be no functional changes, but the size of the built library will increase due to the additional features enabled. The increase depends on the configuration, application, platform, and toolchain, but the order of magnitude currently ranges from about 9 KB for a minimal TLS configuration with LTO (link-time optimisation) to about 30 KB for a full configuration without link-time garbage collection (though size-constrained devices are very unlikely to use such a configuration); we aim to reduce this overhead in the future.
Rationale: maintaining two versions of every cryptographic operation in upper layers (one PSA, one non-PSA) imposes a significant burden on new developments. By removing that burden, we hope to progress faster on things that are more important in the long run, including better integration of PSA Crypto in TLS and X.509, and future code size optimisation of PSA Crypto. We realise the impact on users who were excluding PSA Crypto is significant. We're going to release Mbed TLS 2.28 in the coming months, which is not affected by this change and will receive bug fixes and security fixes for at least 3 years; we hope it provides an acceptable fall-back solution to affected users.
In the long run, PSA Crypto will become the only Crypto API we offer; we want to make its footprint as small as possible considering its feature set and we hope this change will enable us to make faster progress towards that goal.
Best regards,
Manuel Pégourié-Gonnard for the Mbed TLS team.
Hi,
While working on updating mbedtls to v3.0, I saw that the internal fields in MBEDTLS have been made private. ( ref- here<https://github.com/ARMmbed/mbedtls/blob/development/docs/3.0-migration-guid…>). It says there and I quote
"As a last resort, you can access the field foo of a structure bar by writing bar.MBEDTLS_PRIVATE(foo). Note that you do so at your own risk, since such code is likely to break in a future minor version of Mbed TLS.”
I just wanted to know if there is any alternative solution to this, rather than using `MBEDTLS_PRIVATE` everywhere. I know the next release of mbedtls probably plans to fix this with appropriate solution. But we wanted to push out our feature branch As early as possible.
I saw in the PR<https://github.com/zephyrproject-rtos/zephyr/pull/37753> in zephyr RTOS about updating to mbedtls-3.0. They have just added this line<https://github.com/ceolin/zephyr/blob/5bf3128a9703561e578651218f5bcdafb96f8…>
#if !defined(MBEDTLS_ALLOW_PRIVATE_ACCESS) #define MBEDTLS_ALLOW_PRIVATE_ACCESS
# endif
Is this an alternative solution to using `MBEDTLS_PRIVATE` for accessing a private field. If yes, can somebody please point me to respective document as this would greatly reduce our code-changes.
I understand there is some discussion going on in mbedtls about this change, and appropriate getter-setter functions shall be provided. But we wanted to push out out feature branch for early testing.
Thanks and Regards,
Aditya
Hi,
On Monday 8th we will have the next Mbed TLS Tech Forum. Please reply to the list if you have any agenda topics to raise.
As a starter for the agenda, we will likely discuss: https://github.com/ARMmbed/mbedtls/pull/5067 Proposal for driver dispatch code gen
Dave Rodgman
Zoom details below. The call will be recorded and made available on the TF website : https://www.trustedfirmware.org/meetings/
Join Zoom Meeting
https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT…
Meeting ID: 999 4846 2765
Passcode: 196117
One tap mobile
+12532158782,,99948462765# US (Tacoma)
+13462487799,,99948462765# US (Houston)
Dial by your location
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
888 788 0099 US Toll-free
877 853 5247 US Toll-free
Meeting ID: 999 4846 2765
Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt
I need to use mbedtls (bundled with Nordic SDK, and unsure of version) to
do some cloud-based functionality (AWS cloud, using OpenAM with a CA chain
containing 4 certs). According to something I read, I need to use a pkcs7
container? If so, it seems that mbedtls does not support pkcs7? I did
hand-copy some code from a PR, but as I was looking through the pkcs7.c, it
seems that it still only supports the CA Root. Is this true?
Is there anyone that can give me a hand in solving what I am attempting to
do?
Thank you
/Loren Rogers
Dear Sir,/Madam
We need to convert the files - root.cer,client1.cer
and client1-key.pem to jks using the tool keystore explorer. For that, the
password for the files are needed.Please provide passwords.We need to
establish connection between java client and mbedtls c server.Kindly
provide help.
Regards
Lekshmi G