Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Feb 2018 21:14:54 +1100

(+tls@)

This is a good question Jim and one that I thought through during
implementation, but failed to capture in the doc.

Basically, there is no way to validate the extension if the client
includes an unknown version of TLS or an extension that it doesn't
understand.  A client can know because it should understand the
protocol as negotiated.

The text currently says "an endpoint MUST NOT send a value higher than
the protocol-defined maximum record size unless explicitly allowed by
such a future version or extension"  I think that we should add "A
server MUST NOT enforce this restriction; a client might advertise a
higher limit that is enabled by an extension or version the server
does not understand."

Does that make sense?

On Mon, Feb 19, 2018 at 5:51 PM, Jim Schaad <[email-masked]> wrote:
> I was looking at this document relative to a specific question for Kathleen,
> and I had one thing that I would like you to look at and see if you think it
> is clear enough.
>
> I have a server that is TLS 1.2, a client that is TLS 1.2 & 1.3.   It sends
> a hello w/ and extension value of 2^14+1.  It is not completely clear to me
> that the server should accept this as a legal value and compute the min of
> it and the maximum 1.2 value as the value to use when sending messages to
> the client rather than producing an error message because the value is too
> large.
>
> Jim
>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Feb 2018 09:50:35 -0600

> higher limit that is enabled by an extension or version the server

Mostly.  I am not sure that that exact phrasing is great, though, as we
do want the server to enforce the restriction *as written*, i.e., taking
into account that the client may know better than the server if a newer
version and/or extension is in use.  So, maybe something like "Receiving
a larger value is not necessarily cause for a server to abort the
handshake, given this possibility".

-Ben

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Jim Schaad <[email-masked]>
Date: Mon, 19 Feb 2018 08:31:53 -0800

Martin,

I think that the wording I would prefer would be along the lines of 

A server MUST NOT error on the value of the extension when a higher TLS version is requested.  The server MUST use the minimum of the requested value and the maximum value for the TLS version negotiated.  A server MAY error if a the value of the extension is exceeded for the version of TLS requested.

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Monday, February 19, 2018 2:15 AM
> To: Jim Schaad <[email-masked]>; <[email-masked]> <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Mail regarding draft-ietf-tls-record-limit
> 
> (+tls@)
> 
> Basically, there is no way to validate the extension if the client includes an
> unknown version of TLS or an extension that it doesn't understand.  A client
> can know because it should understand the protocol as negotiated.
> 
> The text currently says "an endpoint MUST NOT send a value higher than the
> protocol-defined maximum record size unless explicitly allowed by such a
> future version or extension"  I think that we should add "A server MUST NOT
> enforce this restriction; a client might advertise a higher limit that is enabled
> by an extension or version the server does not understand."
> 
> Does that make sense?
> 
> 
> > I was looking at this document relative to a specific question for
> > Kathleen, and I had one thing that I would like you to look at and see
> > if you think it is clear enough.
> >
> > a hello w/ and extension value of 2^14+1.  It is not completely clear
> > to me that the server should accept this as a legal value and compute
> > the min of it and the maximum 1.2 value as the value to use when
> > sending messages to the client rather than producing an error message
> > because the value is too large.
> >
> > Jim
> >
> >

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 19 Feb 2018 19:18:27 +0200

On Mon, Feb 19, 2018 at 08:31:53AM -0800, Jim Schaad wrote:
> A server MUST NOT error on the value of the extension when a higher
> TLS version is requested.  The server MUST use the minimum of the
> requested value and the maximum value for the TLS version negotiated.
> A server MAY error if a the value of the extension is exceeded for
> the version of TLS requested.

You need to consider the case where there is some unknown-to-server
extension that happens to alter the limit.

-Ilari

---

From: Jim Schaad <[email-masked]>
Date: Mon, 19 Feb 2018 09:27:14 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, February 19, 2018 9:18 AM
> To: Jim Schaad <[email-masked]>
> Cc: 'Martin Thomson' <[email-masked]>; [email-masked]; draft-ietf-
> [email-masked]
> Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit
> 
> > A server MAY error if a the value of the extension is exceeded for the
> > version of TLS requested.
> 

I am not sure how, as a that server, I could possibly do that.  I can't act on something I don't understand.

Jim

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 19 Feb 2018 19:50:43 +0200

> act on something I don't understand.

Because the server can not know the semantics of unknown extensions, it
has to assume any such can alter the maximum limit. Of course, when it
comes to that, the server could just not error on too large limits
regardless of other extensions.

-Ilari

---

From: Jim Schaad <[email-masked]>
Date: Mon, 19 Feb 2018 09:55:51 -0800

> Sent: Monday, February 19, 2018 9:51 AM
> > > Cc: 'Martin Thomson' <[email-masked]>; [email-masked];
> > > draft-ietf- [email-masked]
> > > > A server MUST NOT error on the value of the extension when a
> > > > higher TLS version is requested.  The server MUST use the minimum
> > > > of the requested value and the maximum value for the TLS version
> negotiated.
> > I am not sure how, as a that server, I could possibly do that.  I
> > can't act on something I don't understand.
> 
> Because the server can not know the semantics of unknown extensions, it has
> to assume any such can alter the maximum limit. Of course, when it comes to
> that, the server could just not error on too large limits regardless of other
> extensions.

But if the server does not understand the new extension, then it would not be returned to the client so that the client would understand how the server decided on what the maximum value that it is going to use for the client is.  The client can then abort the connection if it does not like the new limit.  However, I think that this would only affect the MAY in the proposed text.

Jim

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Feb 2018 12:06:13 -0600

> But if the server does not understand the new extension, then it would not be returned to the client so that the client would understand how the server decided on what the maximum value that it is…

Consider the hypothetical case where we define an extension
my_mtu_is_absurd, that lets you send 2**16-1-byte records, so the client
sends that extension as well as a record_size_limit extension including
the 2**16-1-byte value.  A server that does not know about
my_mtu_is_absurd might say "this value 2**16-1 is way too big; I'm going
to abort", and that's the behavior that we're trying to prevent.

-Ben

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 19 Feb 2018 20:23:43 +0200

On Mon, Feb 19, 2018 at 09:55:51AM -0800, Jim Schaad wrote:
> But if the server does not understand the new extension, then it would
> not be returned to the client so that the client would understand how
> the server decided on what the maximum value that it is going to use for
> the client is.  The client can then abort the connection if it does not
> like the new limit.  However, I think that this would only affect the
> MAY in the proposed text.

Suppose client supports large-records extension that allows records up
to 65535 bytes, but the server does not know about this extension.

Then ClientHello which has record size limit of 65519 and the
extension MUST NOT cause an abort, because such ClientHello is fully
valid.

This would be very unusual requirement. So better to specify that the
server MUST accept overly large values, internally truncating to the
negotiated protocol maximums or implementation maximums, whichever is
smaller.

The server to client direction is different matter. Client always
understands all server extensions (there is a requirement to abort
otherwise) so it knows what is the maximum possible record size for
the negotiated protocol and can check that. However, it must still
internally trunccate that to implementation maximums.

Also, the values are capability advertisments, so the server value can
be larger or smaller than the client value. Following is fully legal
and well-defined in TLS 1.3:

Client: maximum-record-size=1025 (do not send me more than 1024 bytes
of record plaintext).
Server: maximum-record-size=16385 (understood, send me any size you
like within protocol limits).

-Ilari