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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls