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

[Ilari Liusvaara <[e-mail]>]

On Fri, Mar 17, 2017 at 02:33:44PM +0100, Thomas Pornin wrote:
> On Fri, Mar 17, 2017 at 11:21:12AM +0000, Peter Gutmann wrote:
> > However, this then leads to a problem where it doesn't actually solve
> > the constrained-client/server issue, if a client asks for 2K max
> > record size and the server responds with a 4K hello then it's going to
> > break the client even if later application_data records are only 2K.
> > So it would need to apply to every record type, not just
> > application_data.

> Fragmentation of messages is another issue, which is correlated but
> still distinct. Note for instance that it is customary, in the case of
> TLS 1.0 with a CBC-based cipher suite, to fragment _all_ records
> (application data records, at least) as part of a protection against
> BEAST-like attacks. Also, having very small buffers does not necessarily
> prevent processing larger handshake messages, or even larger unencrypted
> records. Here I may point at my own SSL implementation (www.bearssl.org)
> that can do both: it supports unencrypted records that are larger than
> its input buffer, and it supports huge handshake messages. It can
> actually perform rudimentary X.509 path validation even with
> multi-megabyte certificates, while keeping to a few kilobytes of RAM and
> no dynamic allocation.
>
> Now that does not mean that a "don't fragment" flag has no value.
> Indeed, streamed processing of messages is not easy to implement (I
> know, since I did it), and having some guarantees on non-fragmentations
> may help some implementations that are very constrained in ROM size and
> must stick to the simplest possible code. But it still is a distinct
> thing. Moreover, maximum handshake message length needs not be the same
> as the maximum record length. For instance, OpenSSL tends to enforce a
> maximum 64 kB size on handshake messages. Maybe we need a "maximum
> handshake message length" extension.

The TLS implementation I did has 128kB limit. Also, unfragmented
handshake messages are subject to zerocopy processing. No
streaming processing.

The mere thought of someone implementing streaming processing in
C scares me. I think BearSSL autogenerates that code.

Also, in TLS 1.3, certificate messages are considerably more
complicated. I don't think streaming processing of recommended-to-
support stuff is even possible.

My own implementation won't implement all of that, but the parts
it implements (still took a few security issues because of the
complexity beyond what TLS 1.2 REQUIRED) still require considerable
back and forth. Most of the memory is borrowed from the message, but
still not streamable.

> In order to "fix" RFC 6066, the following would be needed, in my opinion:
> 
>   - Allow the server to send the extension even if the client did not
>     send it.

TLS architecture does not allow this. Sending any extension in server
hello that wasn't in client hello causes loads of implementations to
just blow up (my implementation is certainly one of those). In fact,
clients are REQUIRED to.

 
>   - Allow the server to mandate fragment lengths smaller than the
>     value sent by the client (a client not sending the extension would
>     be assumed to have implicitly sent an extension with a 16384-byte
>     max fragment length).

I think allowing server to give lower limit for client records was
one of the key improvments over max_record_length.

I also think with the proposed extension, client could send 4096 and
server could send 16384. Meaning server->client only supports records
up to 4096, but client->server supports records of any size.

>   - Preferably, change the encoding to allow for _two_ lengths, for
>     both directions, negociated separately.

You mean maximum handshake message size and maximum record size?



-Ilari