Re: [TLS] RFC 6066 - Max fragment length negotiation

[Peter Gutmann <[e-mail]>]

Martin Thomson <[e-mail]> writes:
>On 17 March 2017 at 10:45, Peter Gutmann <[e-mail]> wrote:
>> In which case it might be time to update the RFC, since there's no obvious
>> reason why you can't send it from the server.  Can any of the original authors
>> provide a reason why it shouldn't be done by the server?
>
>Most clients will explode if the server sends an extension that the client
>didn't offer.

Is that from actually trying it with clients, or just assuming that
implementations will do what the spec says?  It's another one of those bits of
TLS 1.2 that make no sense, so I've ignored the requirement in my code, you
have to add a whole pile of code to perform the check (more attack surface)
and the best possible outcome is that it has no effect, while the worst is
that it breaks things if a buggy server drops in an extension the client
wasn't expecting.  In other words implementing it has negative utility.

There's also the escape hatch of "server-oriented extensions", all you'd need
to do is define one that tells the server that the client will accept any
extensions the server cares to send, thus negating the "no server extensions"
requirement.

Given that this looks like an embedded-only sort of thing, I could even add it
to -LTS, since a primary target of that is embdded/SCADA/etc.

Peter.