Hi Hubert, your proposal to include the worst case calculations are indeed another possibility. It provides more information for the developer than the current version of the document.
A few additional remarks: On 09/12/2017 08:11 PM, Hubert Kario wrote: > On Tuesday, 12 September 2017 14:30:48 CEST Hannes Tschofenig wrote: >> Hi Martin, >> >> I have implemented the record size extension into mbed TLS. It can be >> found at https://github.com/ARMmbed/mbedtls/pull/1088 >> >> There is only one problem that remains to be addressed IMHO. This >> extension was developed to address the problem of devices with small >> RAM. Application developers have to configure their embedded TLS stack >> in such a way that the parameters configured with this TLS extensions >> match the available hardware. >> >> The record_size_limit helps a lot already but does not quite to the >> final goal since it uses an artificial metric for deciding when to >> fragment records. >> >> Currently, a developer has to understand various security concepts to >> get this right, namely >> * Ciphersuite negotiated (and the overhead associated with it, such as >> tag length), >> * DTLS vs. TLS record layer header differences, >> * potential compression being applied. >> >> Additionally, there is, of course, other header information that needs >> to be considered in the overall buffer size calculation, such as TCP or >> UDP, IP and potentially any lower layer headers. >> >> I just think that this is too much to ask for from an ordinary developer. >> >> Hence, I would suggest to use a different metric so that the developer >> can be certain that at least from a DTLS/TLS layer there are not records >> being sent that exceed the indicated threshold. >> >> If you think that this idea is worthwhile to entertain then I will make >> a proposal. > > yes, I too found the necessary calculation rather complex and thus hard to > get > right > > that being said, if you are ok with "good enough" solutions (for memory > allocation, for verifying correctness of packets it should be exact), the > actual receive buffer for encrypted TLS records has to be only 85 bytes > longer > than the value you send to server: > - max MAC size - 48 bytes > - max IV size - 16 bytes > - header size - 5 bytes ... unless DTLS 1.2 is used where it is 13 bytes. For DTLS 1.3 is most likely different since we are trying to optimize the record layer format. > - max block size for CBC ciphers - 16 bytes > - max padding - 16 bytes ... unless TLS/DTLS 1.3 is used where padding is a different meaning. > since MAC size is the exact multiple of block size, the padding starts in > worst possible place if the MAC size is arranged on block boundary. Thus the > worst case scenario padding length is 16 bytes. Same in case of EtM. Ciao Hannes _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
