While waiting for opinions regarding the question of adding features to the LTS versions, I have written a draft design doc.

I discussed the "design review process" with Hanno Becker, and we decided to try and use GitHub for the design review.

I have created PR #3783 [0], which includes `docs/proposed/hs_fragmentation.md` [1].

I will appreciate your comments, and will update the design doc following the feedback. Once there is clarity on the approach, I will proceed with the implementation PRs.

[0] https://github.com/ARMmbed/mbedtls/pull/3783 [1] https://github.com/ARMmbed/mbedtls/pull/3783/commits/8be34f22237ee3cd3c1db2d...

On Mon, Oct 12, 2020 at 12:04 PM Omer Shapira via mbed-tls < mbed-tls@lists.trustedfirmware.org> wrote:

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:

1. What is the best way to add the feature to MbedTLS 2.7?
2. 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 -- mbed-tls mailing list mbed-tls@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls