Hi Peter
A few comments on just two of your points:
The last one [AES] is 12k because the MbedTLS AES uses big tables and is quite fast
There are a number of #defines that can be used to tune the flash size of AES vs its performance in Mbed TLS, particularly in the latest v3.6.0 release - have a look in mbedtls_config.h.
by dropping old crypto suites you are really saving very little FLASH memory
You're absolutely right: this is not about saving code size. However, by removing code and configuration options we do significantly improve maintainability and the ability to work on other algorithms and features.
Because we try to ensure everything gets tested, rarely-used features continue to take up time in our CI, which has been a significant problem for the team over the last year or so.
Having multiple configuration options increases complexity, which makes future development work harder and more error-prone.
And having algorithms available which have been generally deprecated by the industry leads to questions from perhaps less experienced people than yourself, which takes up our time answering them.
Thanks
Tom Cosgrove Mbed TLS Developer
________________________________ From: Peter via mbed-tls mbed-tls@lists.trustedfirmware.org Sent: 29 March 2024 14:37 To: Manuel Pegourie-Gonnard Manuel.Pegourie-Gonnard@arm.com Cc: mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org; Satya Prakash Prasad satyaprakash.developer.unix@gmail.com Subject: [mbed-tls] Re: [Mbed-tls-announce] Latest Release of Mbed TLS
I don't know enough to give you detail but if you download the current root cert file cacert.pem from one of the usual places, and check the signatures, you will find the ones I am referring to. If some of these don't work with what comes in MbedTLS 3 then you will get hassle!
I also do not get why actually remove algorithms which are regarded as less secure. If you are building a server (which is usually not a good idea in IOT) then you can choose which crypto suites to advertise. If you are building a client then you need to find mutual support with the server you are connecting to, and if that server is offering some old crypto then it is *their* problem more than yours, and in most cases the customer for your box will just send it back saying it doesn't work. This space is full of cheap chinese boxes...
There are lots of reasons why, in a "private" network scenario, one might want to run old crypto. The 1st one is that it works, has been working for say 10 years, and most commercial users want a system which works even if it is in theory less secure.
I know about DES and 3DES (implemented these in Z80/Z180/H8-300 asm), built and sold some commercial line encryptors, and been following the crypto scene ever since PGP came out :) So while I know little about TLS/X509 details, I am not a complete numpty.
And it is quite obvious that in the IOT space most attacks will come from completely different directions to brute force cracking of RSA with an array of the new Nvidia chips (which btw cost $30k each) :) In a completely private system the attack surface is likely negligible, and if you are selling some box and there is enough money in it then somebody will just buy one and crack it. All the microcontrollers out today can be cracked, by one of the old methods like glitching the clock, etc.
Anyway people love to argue this stuff, but I think actually removing algorithm support is not what MbedTLS should be doing. Absolutely everything should be included, with #defines for selective builds.
From my project notes, STM32F417 CPU:
- removing all of TLS: 200k saved - removing DES and 3DES: 7k saved - replacing TLS AES with 32F417 hardware AES: saves 12k
The last one is 12k because the MbedTLS AES uses big tables and is quite fast, at 800kbytes/sec (168MHz ARM32). A widely used open source "tinyAES" which is under 1k in size runs at 100kbytes/sec. AES256 done with the 32F417's hardware AES feature runs at some megabytes/sec but this was not measured.
We never implemented DES/3DES with the 32F417's hardware DES feature because the product is not performance sensitive. The real goodie would be hardware RSA/EC (which takes a few hundred ms which in some applications is quite slow) but this chip doesn't have it (there are plenty of coprocessors, for a few $).
So by dropping old crypto suites you are really saving very little FLASH memory, while creating real headaches for users who have to interface to industrial gear where they don't control the other end and where, frankly, whoever set up the "other end" has probably
- never documented it - left the company 10 years ago - is living in Thailand and having fun - died of old age
Peter
Hi Peter,
Thanks for your input.
We try to be careful in removing support for deprecating things because we want to avoid situations where users have to choose between using an older version of mbed TLS that's no longer maintained, or facing interop issues. As I said, if you find yourself in such a situation, please let us know about the specifics so that we can try to find a solution. User input is crucial for this sort of thing. (You'll note that we always ask on the mailing list before we remove a feature.)
Regarding certificates, as of 3.6.0, SHA-1 signatures are not accepted by default, but SHA-1 is still present in the code base, enabled in the default configuration, and its use for certificate signatures could still be enabled manually by creating a new certificate verification profile `mbedtls_x509_crt_profile` (IIRC we're still doing this for some of our tests). Or preferably, you could mark specific certificates you still want to trust as directly trusted by adding them to the ?`trust_ca` argument of mbedtls_x509_crt_verify()? - this is probably preferable to trusting SHA-1 signatures for all certificates. (The signature on directly-trusted certificates is not checked as it doesn't need to be: the certificate is trusted due to user choice, not because of its signature.)
Granted, it requires manual work, but as usual, it's a compromise between security and convenience. At the moment, meaningful SHA-1 collisions are a real thing and becoming cheaper every year, so clearly we can no longer accept them by default. But that doesn't mean you're left without options.
Regards, Manuel.
From: Peter peter@peter2000.co.uk Sent: 29 March 2024 11:49 To: Manuel Pegourie-Gonnard Manuel.Pegourie-Gonnard@arm.com Cc: mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org; Satya Prakash Prasad satyaprakash.developer.unix@gmail.com Subject: Re: [mbed-tls] Re: [Mbed-tls-announce] Latest Release of Mbed TLS
This is a bit of input from a non TLS expert. Well, I know what it does but the LWIP-TLS implementation in the project I have been working on for past few years was done by someone else.
It still uses TLS 2.16.2 and there are no plans to change this because a) it is a lot of work b) it has been extensively tested c) an IOT box cannot be on an open port anyway so this will only ever be a client sitting behind NAT or some such.
Upgrading to later TLS was discussed and it will be done if we have a customer who demands it :)
But there is a gotcha with just saying (as all the crypto experts on the internet like to say) that algorithm X is now insecure, deprecated, so remove support for it. It is the sort of thing which google like to do but they get away with it because they own the world.
So you do that, save perhaps 10k of FLASH (on a CPU which has 1MB), but then you find that some certificates in cacert.pem are really old (maybe 20 years?) and are signed with a hash which was, ahem, deprecated, is "insecure", and your box now will not connect to that server anymore. It takes a fair bit of work to find out why it doesn't connect!
And I am talking about some big-name websites.
And since this is not exactly a rare thing, and since MbedTLS is a bastard to debug when in some embedded box, I have a win32 executable version of it (done by the same guy; took him a week or so) which outputs decent diagnostics. Without such a tool, MbedTLS is asking to be a customer support nightmare; these issues are inherently complex.
It does look like one can safely drop DES and 3DES nowadays (based on my enquiries, but that means very little) but do you feel lucky? There is no way to be sure. If you control both ends then you *know* you aren't using DES but then if you control both ends you probably don't need latest TLS because the attack surface is way smaller ;)
Peter (a coder in asm and C since 1980, Z80 all the way to 32F417)
Hi Prakash,
Good question. No, 3.6.0 does not have all the features that are in 2.28.8 - however it should have all the features of 2.28.8 that are still relevant today.
As indicated by the major version being different, incompatible API changes have been made in 3.0.0. Among them was the removal of a number of features considered obsolete or unadvisable to use at the time. For example, support for SSL 3.0, TLS 1.0 and 1.1 was removed at that time. For a complete list, see "API Changes" under "Mbed TLS 3.0.0" in our ChangeLog:https://github.com/Mbed-TLS/mbedtls/blob/development/ChangeLog#L1455
After that, there were only compatible changes between 3.0.0 and 3.6.0 in particular no feature removal. So, the only features that are in 2.28.8 and not in 3.6.0 are those documented in the entry for 3.0.0.
Note that on the other hand, 3.6.0 has a lot of features that are not in 2.28.8. For example, 3.6.0 has support for TLS 1.3. For a complete list, see all the "Features" sections for all the versions from 3.0.0 to 3.6.0 in the ChangeLog.
Now, for most people I'd strongly recommend using 3.6.0 for new development. The only reasons I could see for using 2.28.x today are:
If you have an existing code base using 2.28.x and now is not a convenient time to move to a new major version. (But please note that 2.28.x will not be maintained after the end of 2024, so you'll have to migrate at some point before that.) 2. If you happen to need one of the features that was removed in 3.0.0. That should be a very rare occurrence as 3.x is supposed to support everything that's still relevant. So, if you find yourself in this situation, please let us know.
TL;DR: most people should use 3.6.0.
Hope this helps, Manuel.
From: Satya Prakash Prasad via mbed-tls mbed-tls@lists.trustedfirmware.org Sent: 29 March 2024 03:51 To: mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] Re: [Mbed-tls-announce] Latest Release of Mbed TLS
Hi,
Many thanks for the updates and information as provided. Please let us know the difference between 3.6.0 and 2.28.8 release.
Are all the features of 2.28.8.available in 3.6.0? Please advise which version to use based on functionality.
Regards, Prakash
On Thu, Mar 28, 2024 at 9:12?PM Minos Galanakis via Mbed-tls-announce via mbed-tls <mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org> wrote: Hi Mbed TLS users,
We have released Mbed TLS versions 3.6.0 LTS and 2.28.8.
These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.6.0, https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.8).
We recommend all users to consider whether they are impacted, and to upgrade appropriately. 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. -- Mbed-tls-announce mailing list -- mbed-tls-announce@lists.trustedfirmware.orgmailto:mbed-tls-announce@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave@lists.trustedfirmware.orgmailto:mbed-tls-announce-leave@lists.trustedfirmware.org
-- mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org