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

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 4 Mar 2018 15:57:24 +0000

Hi Martin,

A short remark below:

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

Thanks Hannes,

On Tue, Feb 27, 2018 at 9:27 PM, Hannes Tschofenig <[email-masked]> 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.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Mar 2018 09:02:33 +1100

> [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…

Let me try to explain more.

An endpoint that can't handle a big packet (whether that be a big TCP
segment or a big UDP datagram) can always pretend that this is a link
issue and send the appropriate ICMP message.  That limits the size of
packets they receive, at least to the point that the minimum for the
IP version in use is reached (576 for v4, 1280 for v6).  I'm not sure
what fragmentation does here, other than make things far worse.

If there are multiple packets arriving and no space for more than one,
then the endpoint can pretend that it didn't receive the packet.  TCP
also has ACKs, which the endpoint can withhold until it has space.

Thus, the endpoint can hold as little as a single MTU of data at once.
Given that it is not encrypted, my understanding is that there is no
need to constrain how it is turned into records.

Note that a constrained server has to handle a full ClientHello - the
client won't know the limit at the server.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 5 Mar 2018 16:51:58 +0000

I believe we are on the same page with regards to this issue.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]]
Sent: 04 March 2018 23:03
To: Hannes Tschofenig
Cc: Benjamin Kaduk; Alan DeKok; [email-masked]; IESG; [email-masked]
Subject: Re: Secdir review of draft-ietf-tls-record-limit

On Mon, Mar 5, 2018 at 2:57 AM, Hannes Tschofenig <[email-masked]> wrote:
> [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.)

An endpoint that can't handle a big packet (whether that be a big TCP segment or a big UDP datagram) can always pretend that this is a link issue and send the appropriate ICMP message.  That limits the size of packets they receive, at least to the point that the minimum for the IP version in use is reached (576 for v4, 1280 for v6).  I'm not sure what fragmentation does here, other than make things far worse.

If there are multiple packets arriving and no space for more than one, then the endpoint can pretend that it didn't receive the packet.  TCP also has ACKs, which the endpoint can withhold until it has space.

Thus, the endpoint can hold as little as a single MTU of data at once.
Given that it is not encrypted, my understanding is that there is no need to constrain how it is turned into records.

Note that a constrained server has to handle a full ClientHello - the client won't know the limit at the server.
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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 6 Mar 2018 19:41:47 +1100

Just to follow-up. I think that removing the "especially handshake
messages" will help resolve this.  This implies that handshake
messages are always unprotected, which is not the case.

The change that I propose:

-RecordSizeLimit value it receives from its peer.  Unprotected messages -
-handshake messages in particular - are not subject to this limit.
+RecordSizeLimit value it receives from its peer.  Unprotected messages are not
+subject to this limit.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 6 Mar 2018 09:07:36 +0000

Thanks, Martin!

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]]
Sent: 06 March 2018 09:42
To: Hannes Tschofenig
Cc: Benjamin Kaduk; Alan DeKok; [email-masked]; IESG; [email-masked]
Subject: Re: Secdir review of draft-ietf-tls-record-limit

Just to follow-up. I think that removing the "especially handshake messages" will help resolve this.  This implies that handshake messages are always unprotected, which is not the case.

-RecordSizeLimit value it receives from its peer.  Unprotected messages - -handshake messages in particular - are not subject to this limit.
+RecordSizeLimit value it receives from its peer.  Unprotected messages
+are not subject to this limit.

On Tue, Mar 6, 2018 at 3:51 AM, Hannes Tschofenig <[email-masked]> wrote:
>> even with the best possible configuration. (There is this work in
>> LWIG on TCP implementation guidance where the authors are supposed to