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

[Eric Rescorla <[e-mail]>]

On Mon, Apr 2, 2018 at 6:21 PM, Martin Thomson <[e-mail]>
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-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.
>

This seems like a fine resolution.

-Ekr