Re: [TLS] Maximum Fragment Length negotiation

[Martin Thomson <[e-mail]>]

On 30 November 2016 at 05:54, Thomas Pornin <[e-mail]> wrote:
> Any comments?

I'm ambivalent on this generally: though I think that the general
notion is OK, I'm not sure about the details.

In particular, you need to be clearer in your motivations: the point
is to ensure that little things (really little things) can talk to any
other TLS implementation.  That seems inherently good, but it might
pay to dig into that some more: why is that good?

I would be opposed to having an implicit extension in the way you
describe.  If you are going to require this, then you need to require
the client to send the extension.  I would also be opposed to a new
extension when the existing one is adequate - or it could be made to
be adequate.

I agree that the current extension semantics are not good.  Ideally we
would want 2^13 and 2^14, and an agreement to use min(client_mfl,
server_mfl) rather than having the server dictate.  That might mean a
new extension, but I'm not sure.

> I can try to write the corresponding text for inclusion in the TLS 1.3
> draft. What is the process for submitting such text?

The spec is on github: https://github.com/tlswg/tls13-spec  You can
create a pull request.

However, I am going to suggest that this is a pretty big change.  It's
already late.  It might be better to create a new draft that revises
the maximum fragment length extension (or defines a better
replacement).

(As an aside, the success rate for RFC 6066 is pretty low in
retrospect, maybe there's an object lesson there.)