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

[Hannes Tschofenig <[e-mail]>]

Hi Martin,

A short remark below:

-----Original Message-----
From: Martin Thomson [mailto:[e-mail]]
Sent: 28 February 2018 02:01
To: Hannes Tschofenig
Cc: Benjamin Kaduk; Alan DeKok; [e-mail]; IESG; [e-mail]
Subject: Re: Secdir review of draft-ietf-tls-record-limit

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.

[Hannes] There are indeed ways to reduce the over the wire transmission overhead and raw public keys are a useful approach.

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

[Hannes] I am not sure I fully understand the approach. Even if someone uses TCP a RAM limitation will not go away. TCP is likely to make the situation worse since it requires some amount of RAM as well even with the best possible configuration. (There is this work in LWIG on TCP implementation guidance where the authors are supposed to provide some information about the actual RAM usage of various TCP features and settings.)

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

[Hannes] I am convinced that we have to apply the RSL limit also the handshake message. In most cases today clients are constrained but the way some communication models work they may also see constrained servers.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.