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 - max block size for CBC ciphers - 16 bytes - max padding - 16 bytes 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. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
