Hi Dave,
Thanks for your reply.
The particular reasons for bringing up 2.7 and 2.16 first is that my employer is currently using 2.7 and would prefer using a small increment. Having said that, if adding features to LTS is not advisable (especially given that 2.7 has less than 6 months of projected life), I think I can present the arguments against using the 2.7.
Additional consideration is the timing. My employer needs fragmentation support as soon as possible, with the intent of running it on a desktop environment. Historically, when the engineers are able to provide my employer with what is needed now, they are allowed more time for incremental improvements.
The third consideration involves the MPS project by Hanno Becker. I've been collaborating with Hanno, and with Hannes Tschofenig and Thomas Fosetti on the project of adding QUIC support to mbedTLS. This goal depends on TLS 1.3 support (Hannes has written a prototype, which I was able to add QUIC in an internal version), and on MPS. I would like to avoid putting a duplicate effort into non-MPS fragmentation support.
Unfortunately, if I want to meet the timing requirements of my employer, I will not be able to use MPS, since it needs more maturing.
Because of the above considerations, I would like to suggest the following plan of actions:
As the first step, I would like to add the MVP (minimal viable product) fragmentation to the development version. The MVP takes the following assumptions:
1. The RAM footprint is not a concern for the MVP (my employer is going to run it in the desktop environment). 2. Unification of the fragmentation between TLS and DTLS is not a concern for the MVP 3. LTS is not a concern for the MVP (potentially not at all)
Because of the above simplifying assumptions, I believe that the change can be small and focused. I think I can have code ready for review in a couple of weeks.
As the second step, I would like to put my effort into helping Hanno Becker with his MPS system. Once sufficiently mature, the MPS will supersede the MVP fragmentation, and will open the doors for adding support for QUIC. The simplifying assumptions 1. (RAM) and 2. (TLS <=> DTLS) will be addressed by MPS. Addressing the last assumption may not be required.
What are your thoughts?
On Wed, Oct 14, 2020 at 10:28 AM Dave Rodgman dave.rodgman@arm.com wrote:
Hi Omer,
Thanks for offering to help us with this feature.
Normally, we wouldn’t add new features directly to an older branch, for a few reasons. 2.7 is quite old and is in fact only guaranteed to be supported until Feb 21, so it’s not the ideal place to spend effort on new features. Introducing new features here would also create the situation where 2.7 has features not in development, and vice-versa, creating an upgrade dilemma for users (unless we were to port the feature to all supported branches). And adding significant new features to LTS branches can always introduce some risk of destabilising it.
So for these reasons, we would normally recommend targeting the development branch for new features (with backports only where there is a strong reason to do so), and then picking up the next stable release that contains the new feature.
Is there a particular reason you’re focusing on 2.7, rather than development, or would it be viable for you to add this to development and pick up the next release?
Thanks
Dave
*From: *mbed-tls mbed-tls-bounces@lists.trustedfirmware.org on behalf of Omer Shapira via mbed-tls mbed-tls@lists.trustedfirmware.org *Reply to: *Omer Shapira omer.shapira@gmail.com *Date: *Monday, 12 October 2020 at 20:04 *To: *"mbed-tls@lists.trustedfirmware.org" < mbed-tls@lists.trustedfirmware.org> *Subject: *[mbed-tls] Working on TLS handshake record fragmentation (#1840)
Hello,
My employer (Facebook) is willing to give me some time to TLS handshake fragmentation support to MbedTLS 2.7 [0] . This would be my first contribution to MbedTLS, and I have several novice questions:
- What is the best way to add the feature to MbedTLS 2.7?
- Trade-off between the consistency of the fragmentation code across the
branches, vs. the consistency of the branches.
Question 1: Best way to add the feature to MbedTLS 2.7
One constraint that I am facing is the code must be added to the upstream branch that is as close as possible to the 2.7.xx. My understanding of the Contribution Guidelines[1] is that while the LTS branches are mostly meant for the bug fixes, backporting of the new features is welcomed as long as the API/ABI compatibility is maintained and the disruption to the users is minimized.
If adding support to the LTS branches is not advisable, are there any other possibilities of contributing the code to an upstream branch that is very close to the 2.7.xx?
Question 2: Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches.
Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. The `development` branch supports variable-length buffers[2] . Variable messages sizes would make the fragmentation easier in the development branch. In addition, there is the MPS effort by Hanno Becker which would make the fragmentation support even easier in the development branch. None of that is present in the 2.7 or the 2.16 branches.
What is the preferable trade-off in such a situation: a. Minimizing the change to the "host" version (2.7 or 2.16), on the expense the implementation of the feature differ between 2.7 and `development`, or b. Minimizing the differences in the implementation of the feature, on the expense of more intrusive changes to the earlier versions?
[0] https://github.com/ARMmbed/mbedtls/issues/1840 [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md [2] https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.h...
--
Sincerely Yours, Omer Shapira