On Fri, Mar 17, 2017 at 04:37:59PM +0100, Thomas Pornin wrote: > > > 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).
Cookies can indeed be quite large and are required. I don't think session tickets are required (the implementation I did just throws those to trash). > > 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. Ah, I implemented version of record_size_limit extension (grabbing codepoint 0x1053). The value sent is always 16384, but the value received can be different. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
