Text proposal for BERT-related issues about coap-tcp-tls HOT 10 CLOSED

Note: if we change the definition of Max-Message-Size to [options + packet marker + payload] then we obviously have to adjust the description. The advantage of this description is the simplicity; the disadvantage is that it is basically silent on the tough part (namely the unknown length of the options).

from coap-tcp-tls.

To add a remark to the interaction between Max-Message-Size (MMS) and the Record Size Limit (RSL) Extension.

For TLS 1.3 the RSL value is defined to include application content + TLS content type + padding

For TLS 1.2 the RSL value is defined to includes TLS content type + protocol version + length + fragment (=application content)

The application content consists of the CoAP header + options + packet marker + payload

When an application developer configures the MMS value then it has to set the RSL value in such a way that it is larger than MMS by taking the additional fields into account. As such, RSL has to be configured as

RSL = MMS + CoAP header + maximum size of options + packet marker + TLS content type + padding (for TLS 1.3)
RSL = MMS + CoAP header + maximum size of options + packet marker + TLS content type + protocol version + length (for TLS 1.2)

If the value of RSS is set to a value that is smaller then the above-provided formula indicates then there is the risk that the TLS layer will reject the transmission of the packet. Unfortunately for developers some of the fields are of variable length, such as the options. The padding field in the TLSInnerPlaintext structure, which is included in the RSS value, is of variable length but will most likely be determined by the application. In addition to this padding, the cipher may itself require some padding for alignment with the blocksize the cryptographic algorithm operates with. This blockcipher padding is, however, excluded from the RSS calculation.

Note also that the way how RSL is defined in I-D.ietf-tls-record-limit does not take the additional overhead of the ciphers into account. An developer must therefore make the buffers larger than the value indicated in RSL since Authentication Encryption with Additional Data (AEAD) ciphers API requires that an entire record be present in RAM to decrypt and authenticate it.

from coap-tcp-tls.

from coap-tcp-tls.

Carsten, this is not my understanding. When TLS creates a record for transmission then it puts the plaintext into memory and applies the AEAD cipher to it. This will encrypt the payload and add an authentication tag to the end. The receiver has to then put this entire block into memory before applying the reverse operation.

Note that stream ciphers operate differently but their use has been deprecated with TLS.

from coap-tcp-tls.

Carsten, could you actually explain what you mean by "The boundaries of messages are in no way related to the boundaries of TLS records."?

from coap-tcp-tls.

from coap-tcp-tls.

I dropped Martin Thomson a message to ask him about the anticipated relationship.

from coap-tcp-tls.

I got a response from Martin Thomson and here is the story.

Without TLS, an application protocol using TCP can read a byte at a time out of the receive buffer (and control that by keeping the receive window small). With TLS, you can not read a byte at a time because you can only read a record at a time due to the nature of the AEAD ciphers (as explained above already).

Hence, the Record Size Limit extension can help to select a proper size for the TLS fragments. So the text in the Record Size Limit extension that talks about "MUST NOT generate a protected record with plaintext that is larger than the RecordSizeLimit value" should rather be interpreted as a way to guide the size of the TLS fragments.

When a developer wants to set the RSL and MMS to make them fit the available RAM size then they have to know how much overhead gets added (at maximum) throughout the stack to set the values appropriately.

The question for me is whether we should do some of that homework to tell the reader what aspects determine the overhead or not. Of course, being silent would be easier for us and setting the RSL value incorrectly can lead to two consequences:

• If the RSL value is not set or selected too large then the MMS value has essentially no effect since the TLS stack can still combine data and send larger payloads.
• If the RSL value is set too small then the TLS will fragment application data into smaller TLS fragments and the result is an inefficient transfer.

In a nutshell, I don't want to be the developer who has to decide what the appropriate value for RSL and MMS is given a specific hardware platform...

from coap-tcp-tls.

Re RSL: Is this the right place to give guidance to developers of TLS implementations?
This might have been a good discussion to add to RFC 7925.
Maybe we have a place in an LWIG document for this; e.g., lwig-coap.
Re MMS: I'm sure developer for constrained devices will be acutely aware of the issues here.
If we have something helpful to say here, let's put that into lwig-coap.

from coap-tcp-tls.

I spoke with Carsten about this topic and he believes that the CoAP over TCP is the wrong document to offer developer recommendations. He believes RFC 7925bis or an LWIG guidance document might be a better place.

from coap-tcp-tls.