Re: [TLS] Eric Rescorla's Yes on draft-ietf-tls-record-limit-02: (with COMMENT)

[Martin Thomson <[e-mail]>]

Nits are on the editor's copy.

https://github.com/tlswg/tls-record-limit/commit/8c6307f63d5c3e34d3da1747fcdfbcc54aa290f6

On Sun, Apr 1, 2018 at 5:31 AM, Eric Rescorla <[e-mail]> wrote:
> This text is a bit confusing. Consider a case where a server recognizes the
> extension and has no limit, but the client offers one.
>
> In that case, the server can either:
>
> Return an extension with a max-size limit
> Not return the extension
> I think we want the server to conform to the client's limit in any case, but
> "negotiated" is unclear.

I think that I was operating on the assumption that both endpoints
need to signal that they support the extension, but you are right that
the server could omit the extension, but comply anyway.  That doesn't
seem properly transparent, so, at the cost of 6 octets, I think that
we want everything to be clear.  I've changed later text as follows:

-Clients SHOULD advertise the `record_size_limit` extension, even if
they have no
-need to limit the size of records.  This allows servers to advertise a limit at
-their discretion.  If this extension is not negotiated, endpoints can send
-records of any size permitted by the protocol or other negotiated extensions.
+Endpoints SHOULD advertise the `record_size_limit` extension, even if they have
+no need to limit the size of records.  For clients, this allows servers to
+advertise a limit at their discretion.  For servers, this allows
clients to know
+that their limit will be respected.  If this extension is not negotiated,
+endpoints can send records of any size permitted by the protocol or other
+negotiated extensions.

Note that while a client that sets a limit might be pleasantly
surprised when a server respects its limit, having the extension
"negotiated" means that it can treat overlarge records with an error.