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

[Martin Thomson <[e-mail]>]

Hi Hannes,

I appreciate that the way that you calculate the available space is
difficult, but I did think very long and hard about this.

The current approach makes it easier for someone to *comply* with the
size limit and I'd like to retain that property as much as possible.
I want people to implement and deploy this extension in every stack
even if they don't have a way to set a limit lower than 16k.

The only alternative metric I can think of is the size of the
ciphertext.  The other overheads are either fixed or hard to measure
at the (D)TLS layer.  Other measures are too situation-dependent, such
as whether you need to count TCP headers, and leads to other problems
like what you do about TCP header extensions.

A change to the length of ciphertext makes it more difficult to
implement at the point when you fragment messages generically.  And
that means more testing.  As it is, I replaced a constant
(MAX_FRAGMENT_LENGTH) with a variable (recordSizeLimit) and the code
was basically done.  Requiring calculations here adds risk and you
want as many people who are NOT building an implementation for
constrained devices to implement this as possible.

Yes, if you want byte-accurate numbers, the configuration calculation
is going to need:

* information about the lower layers of the stack (TCP/UDP/IP) and how
much space they need
* information about TLS versions for the explicit IV
* information about enabled cipher suites and their maximum expansion

The good news is that if you use TLS 1.3, all the AEADs have an
expansion of 16 octets (unless you are using the truncated CMAC suite,
which I have never seen myself) and records add 5 octets.  The whole
CBC EtM/MtE business is a mess for sure, but I think that we're
putting the costs in the right place.

As Hubert observes, you can always assume the worst case expansion,
which is safe and relatively easy.

Note that TLS 1.3 padding is covered, so no concern there.

On Thu, Sep 14, 2017 at 12:17 AM, Hannes Tschofenig
<[e-mail]> wrote:
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls