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...@rtfm.com> 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
