On 30 November 2016 at 05:54, Thomas Pornin <por...@bolet.org> 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.) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
