Re: [TLS] draft-ietf-tls-record-limit-01

[Hannes Tschofenig <[e-mail]>]

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