Re: [TLS] I-D Action:draft-ietf-tls-rfc4366-bis-09.txt

[Juho Vähä-Herttua <[e-mail]>]

On 12.6.2010, at 17.10, Nikos Mavrogiannopoulos wrote:
>> This document provides specifications for existing TLS extensions. It
>> is a companion document for the TLS 1.2 specification [RFC5246]. The
>> extensions specified are server_name, max_fragment_length,
>> client_certificate_url, trusted_ca_keys, truncated_hmac, and
>> status_request.
> 
> It has been mentioned before, but I think its worthwhile to bring it up
> again. The "Maximum Fragment Length" extension only allows setting a
> fragment length that is lower than 2^14... Why not allow larger sizes
> than that?

I haven't seen any earlier discussion related to this, so consider me as an outsider. However, the document is a companion document for the TLS 1.2 specification and the TLS 1.2 specification says:

      The length (in bytes) of the following TLSPlaintext.fragment.  The
      length MUST NOT exceed 2^14.

I think overriding the specification with this extension would be a really bad idea, and even then the hard limit of 2^16 would apply, since fragment length is an uint16.

I have no exact information about where 2^14 the limit itself is coming from (it dates all the way back to SSL 3.0), but I can imagine it has something to do with values 2^15 and up being negative if signed 16-bit integers are used. Therefore bad implementations might break, in case fragment length is 2^15 or larger and they are using signed integer instead of unsigned. Specifying it as lower than 2^14 is a safe bet, since even with all the headers and extra payload it can't really go over the 2^15 limit.


Juho