Re: [secdir] Secdir review of draft-ietf-tls-record-limit

[Hannes Tschofenig <[e-mail]>]

My 5 cents. We currently only have a very basic implementation of the Maximum Fragment Length extension and have been waiting for the RSL extension to complete before we add the functionality to the Mbed TLS stack.

The problem we have with IoT devices is that they are quite limited in terms of available RAM*. Additionally, public key crypto requires a lot of RAM when performance optimizations are enabled. Hence, there is not much left for the message buffers.

Hence, we want to let the other communication party know what limits there are. As pointed out in this discussion thread there is an interworking between the MTU/PMTU and the MFL/RSL mechanisms when a stack decides about fragmenting (or combining) messages into records.

My thinking was that the relationship between MTU/PMTU and MFL/RSL is actually fairly easy, namely something like max_fragment_size=min(MTU/PMTU, MFL/RSL)

Of course, implementations are going to be complex since they cannot just look at the fragment size alone. Instead you also have to consider what the stack or the application should do with the received data.

For example, imagine a certificate message that may contain multiple certificates that then need to be processed one by one by the recipient. Here the stack needs to be "smart" enough to send enough data that the recipient can actually do something with it (like one complete certificate) but also not too much so that it still fits into the buffer. For application data it may be less complicated since the application developer who had set the RSL limit is most likely aware of what to do when the stack cannot send all the data.

In my earlier review I pointed out that setting reasonable values by the developer may actually be complicated since the size of transmitted messages in DTLS/TLS depends very much on the selected ciphersuite and various other parameters (key size, padding of the algorithm, padding for avoiding traffic analysis, authentication tag size, use of certain extensions). Additionally, there are higher layer protocols (such as CoAP) that also add header information. A developer therefore has to know quite a bit to pick the values appropriately when they are using a constrained device.

FWIW: The draft currently says that "unprotected messages - handshake messages in particular - are not subject to this limit.". I am not sure whether I fully understand that sentence. Does it mean that the limit does not apply to handshake messages at all or only to handshake messages that are unprotected? In either case I am not sure whether that scoping makes sense since handshake messages can become fairly large.

Ciao
Hannes

PS: The RAM limitation is obviously independent of whether you use TCP or UDP. Hence, I expect this extension to be applicable to both. Of course, with TCP you additionally have a layer in there that offers fragmentation...


-----Original Message-----
From: Martin Thomson [mailto:[e-mail]]
Sent: 26 February 2018 02:32
To: Benjamin Kaduk; Hannes Tschofenig
Cc: Alan DeKok; [e-mail]; IESG; [e-mail]
Subject: Re: Secdir review of draft-ietf-tls-record-limit

On Sat, Feb 24, 2018 at 6:17 AM, Benjamin Kaduk <[e-mail]> wrote:
> The record size limit is a cap, not a mandatory record size.

That's right.  Alan, does that address your primary concern?

> On Fri, Feb 23, 2018 at 09:49:11AM -0500, Alan DeKok wrote:
>>   RFC 6347 Section 4.1.1.1 gives some guidance, but I think not enough.  Exposing the MTU to the application is good, but what does the application *do* with this information?

In many cases, nothing.

My understanding of DTLS implementations is that the size of a write determines the size of the packet that is ultimately sent.  Say I write 100 octets to the socket, so DTLS writes out a record of 128 octets.

What stacks do when a write exceeds PMTU differs.  The same applies to this new limit:

* The stack I work on splits records based on its understanding of the MTU, but it only learns that during the handshake and so relies mostly on the application making smaller writes.  (There is currently no way to set the MTU, which is an open bug.)  It also sends a single record in each packet for application data, so the net effect of a large write is multiple UDP datagrams with one record each.

If your stack operates like this, then the information is pretty much just advisory.  The only thing you might contemplate is changing any coalescing rules you might have to compensate.

* If a stack did automatic splits, but then put multiple records in the same datagram, that's the same for a using application.

* If a stack rejects large writes and forces the application to write within its constraints, then that stack needs to be clear about what limit was in force, such as through the use of specific error codes.
Such stack that adds this feature would need to be careful about introducing this feature.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.