On Mon, Apr 2, 2018 at 6:21 PM, Martin Thomson <martin.thom...@gmail.com> wrote:
> 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. > This seems like a fine resolution. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
