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

[Ilari Liusvaara <[e-mail]>]

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