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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Sep 2017 14:30:48 +0200

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.

Ciao
Hannes

---

From: Hubert Kario <[email-masked]>
Date: Tue, 12 Sep 2017 20:11:09 +0200

> If you think that this idea is worthwhile to entertain then I will make

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2017 16:17:54 +0200

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:

>  - max MAC size - 48 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
... unless TLS/DTLS 1.3 is used where padding is a different meaning.

Ciao
Hannes

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Sep 2017 12:12:09 +1000

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
<[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 Sep 2017 13:01:06 +0200

On Monday, 25 September 2017 04:12:09 CEST Martin Thomson wrote:
> was basically done.  

my understanding of this draft was that the TLS1.3 ContentType is included in 
the record limit while it is not included in the TLS 1.3 maximum payload size

> Requiring calculations here adds risk and you
> >> yes, I too found the necessary calculation rather complex and thus hard
> >> to get right
> >> 
> >> actual receive buffer for encrypted TLS records has to be only 85 bytes
> >> longer>> 
> >> 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
> >

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Sep 2017 07:20:31 +1000

> the record limit while it is not included in the TLS 1.3 maximum payload size

That's right, I forgot this detail. I subtract 1 for TLS 1.3 when I
set the variable.