Re: [TLS] RFC 6066 - Max fragment length negotiation

[Thomas Pornin <[e-mail]>]

On Fri, Mar 17, 2017 at 05:24:09PM +1100, Martin Thomson wrote:
> I'd even go so far as to specify it:
> 
> https://martinthomson.github.io/tls-record-limit/
> 
> I'll submit an I-D once the blackout ends if people are interested in this.

I like this proposal. One comment, though: I think the wording in
section 4 should mandate that the value sent MUST NOT exceed the maximum
record size -- i.e. if an implementation supports records up to 16384
bytes, then it should put 16384 here, not a bigger value suc as 65535.

Rationale: last time this was discussed on this list, some people
expressed the wish to ultimately support records with more than 16384
bytes of plaintext. If such an extension ever comes to fruition (it is
certainly easy enough to do with CBC and GCM cipher suites), then
sending a record_size_limit with a limit of, say, 60000 bytes, would
serve as indication that the implementation indeed supports such larger
records. This holds only as long as no implementation sends a value
larger than 16384 if it does not really accept records of more than
16384 bytes.

Therefore, I propose to replace this paragraph:

    An endpoint that has no limit on the size of data they receive can
    set this value to any value equal to or greater than the maximum
    possible record size, such as 65535. A larger value does not allow
    the endpoint to send larger records than the protocol permits. An
    endpoint that receives a value larger than the maximum defined in
    the protocol MUST NOT exceed protocol-defined limits. For TLS 1.3
    and earlier, this limit is 2^14 octets.

with the following:

    An endpoint that supports all sizes that comply with the
    protocol-defined limits MUST send exactly that limit as value for
    maximum record size (or a lower value). For TLS 1.3 and earlier,
    that limit is 2^14 octets. Higher values are currently reserved for
    future versions of the protocol that may allow larger records; an
    endpoint MUST NOT send a value higher than 2^14 unless explicitly
    allowed by such a future version and supported by the endpoint.

    When an endpoint receives a maximum record size limit larger than
    the protocol-defined limit, that end point MUST NOT send records
    larger than the protocol-defined limit, unless explicitly allowed by
    a future TLS version.


Of course, larger-than-16384 records are not meant for constrained
systems, but for big systems. Overhead for 16384-byte records with
ChaCha20+Poly1305 is 21 bytes (for AES/GCM in TLS 1.2, this is 29
bytes), i.e. less than 0.2%, which seems small enough to me; but there
still is some demand for larger records, so it makes sense not to
prevent them from ever happening with tighter wording.

---------------

Another point which was made is that CBC cipher suites have a
variable-length padding, up to 256 bytes (length byte + padding), which
is not fully negligible: an endpoint with a 500-byte buffer would have
to send a "maximum record size" of 223 bytes only, in order to fully
support AES/CBC+HMAC/SHA-256 in all cases, while in practice most if not
all endpoints will stick to minimal-sized paddings. Maybe there should
be some extra wording saying that when a "maximum record size" was
received, with a value less than the protocol-defined limit, then an
endpoint SHOULD strive to use minimal-sized padding in cipher suites
that have a variable-sized padding. Or maybe something more convoluted
that says:

    An endpoint MUST NOT generate a protected record with plaintext
    larger than the RecordSizeLimit value received from its peer. An
    endpoint MUST NOT either generate a protected record such that the
    encrypted record length (TLSCipherText.length) exceeds the length of
    the smallest possible encrypted record that would contain exactly as
    many plaintext bytes as the received RecordSizeLimit value, in the
    currently active cipher suite.

This would be only for the benefit of CBC cipher suites with TLS 1.2 and
earlier, not for TLS 1.3, because recent AEAD cipher suites have
predictable (and small) overhead.

Arguably, pre-TLS-1.3 versions also have problem with compression, which
should be in all generality avoided, just like CBC cipher suites should
also be avoided. Maybe this is not a problem after all, and constrained
systems that are recent enough to implement this new extension will also
"naturally" avoid CBC cipher suites anyway. (In any case, if an endpoint
requires small records, then it cannot really talk with peers that don't
support the proposed maximum_record_size extension, so it needs recent
implementations that _should_ already implement at least TLS 1.2 and
some AEAD cipher suites.)


	--Thomas Pornin