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

[Thomas Pornin <[e-mail]>]

On Fri, Mar 17, 2017 at 04:44:48PM +0200, Ilari Liusvaara wrote:
> The mere thought of someone implementing streaming processing in
> C scares me. I think BearSSL autogenerates that code.

Yes, actual code is in a custom Forth dialect, which is compiled to
token-threaded code executed by a C interpreter. That's because if you
want to implement streamed processing sanely in an imperative language
(like C), then you basically need coroutines, i.e. the ability to
interrupt the processing, and later on jump back to the processing. You
cannot do that in plain C if you have function calls and thus a "call
stack" to save and recover (and if you do not, then the code becomes
insanely unreadable). You _could_ make a custom stack, but this is
expensive (since the C compiler tends to create local variables at will,
a custom stack would need at least 1 or 2 kB of extra RAM) and it is
awfully non-portable.


> 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.

Streaming processing is ill-supported and on the decline. E.g. even with
TLS 1.2, EdDSA-signed certificates cannot be processed with streaming,
because the hash function computation over the to-be-signed must begin
with hashing the 'R' element (which is part of the signature, and occurs
_after_ the TBS) and the 'A' value (the signer's public key, which is
found in the signer's certificate, that comes _after_ the current
certificate in TLS 1.2 Certificate message).

Since TLS 1.3 also mandates some options that may require considerable
buffering (e.g. the cookies and the session tickets, both ranging up to
64 kB), one might say that, as an evolving standard, TLS 1.3 is moving
away from the IoT/embedded world, and more toward a Web world. This is
not necessarily _bad_, but it is likely to leave some people unsatisfied
(and, in practice, people clinging to TLS 1.2).


> 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.

I know. BearSSL also rejects server extension that do not match client
extensions. It also rejects attempts by the server at trying to
negotiate a different maximum fragment length. It does so because the
RFC says so (even though I agree with Peter that the standard behaviour
is of questionable usefulness).


> You mean maximum handshake message size and maximum record size?

I mean a maximum record size for records sent by the client to the
server, _and_ a maximum record size for records sent by the server to
the client. Since any implementation may use distinct buffers for
sending and for receiving(*), the two sizes need not match.


(*) In particular, if you want to support HTTPS, where pipelining
requests is allowed, an HTTPS-aware server more or less needs to
have two distinct buffers for input and output.


	--Thomas