Re: [secdir] Secdir review of draft-ietf-tls-record-limit

[Martin Thomson <[e-mail]>]

Thanks Hannes,

On Tue, Feb 27, 2018 at 9:27 PM, Hannes Tschofenig
<[e-mail]> wrote:
> For example, imagine a certificate message that may contain multiple certificates that then need to be processed one by one by the recipient. Here the stack needs to be "smart" enough to send enough data that the recipient can actually do something with it (like one complete certificate) but also not too much so that it still fits into the buffer. For application data it may be less complicated since the application developer who had set the RSL limit is most likely aware of what to do when the stack cannot send all the data.

Yeah, if you are so constrained that a single datagram is all the
scratch space you have, then big certificates can be nigh on
impossible to manage.  My understanding is that raw public keys are
more common in this context.

> FWIW: The draft currently says that "unprotected messages - handshake messages in particular - are not subject to this limit.". I am not sure whether I fully understand that sentence. Does it mean that the limit does not apply to handshake messages at all or only to handshake messages that are unprotected? In either case I am not sure whether that scoping makes sense since handshake messages can become fairly large.

This was written with two things in mind.  TCP makes it easy to apply
back pressure and thereby enable progressive reads for larger
cleartext messages, assuming that you can read it all without holding
everything in memory at once.  More critically, a ClientHello will be
sent in ignorance of any preferences on a server, so a server has to
cope somehow.

If you remain concerned about constrained *clients*, maybe we can
change the requirement and have it apply immediately for the server's
handshake messages.  In TLS 1.2, it would then also apply to the
client Certificate, which I suppose is something.  It's definitely
possible to make this change. (Now that I think on it, my
implementation may already do this.  I should check.)