[erlang-patches] Make SSL max plaintext size configurable

[Roger Lipscombe]

We've discovered that the SSL/TLS application in Erlang assumes a max
plaintext size of 2^14 (16384) bytes.

We're communicating with an embedded device that, due to constrained
resources, can't handle plaintext fragments larger than ~2Kb.

In OpenSSL, the maximum plaintext fragment size can be configured by
using the (barely documented) SSL_CTRL_SET_MAX_SEND_FRAGMENT control.
We're converting our back-end server to Erlang, and we'd like to be
able to do the same from Erlang.

I asked about this here: http://stackoverflow.com/q/19276598/8446,
where it was also suggested that we look at implementing the relevant
section of RFC 6066, which defines a mechanism for negotiating this
parameter. We've discarded that option because (a) RFC 6066 only
allows for a limited set of values for this parameter; and (b) our
embedded device currently only supports TLS 1.1, and RFC 6066 is an
extension to TLS 1.2.

I have a patch that implements this functionality, from the server
side, at least:
https://github.com/rlipscombe/otp/tree/rl-ssl-fragment-size

To use this feature, simply specify {max_plain_text_length, N} in the
Options passed to ssl:listen/2, as follows:

    {ok, LSock} = ssl:listen(17120,
        [{max_plain_text_length, 2000}, {certfile, "server.crt"},
{keyfile, "server.key"}]).

If you don't specify the option, it defaults to 2^14.

I've tested this with Wireshark, and can clearly see that the SSL
message is broken into roughly 2Kb-sized fragments (allowing for some
overhead).

I'd like to:

(a) get some comments on how it can be improved.
(b) see if I can shepherd this patch upstream into a future release of
Erlang/OTP.

Things I am aware of:
- Too many magic numbers. I attempted to put these values in
ssl_record.hrl, but then discovered that not everything that needed
the magic number included this file. In particular, I ended up needing
it in ssl_internal.hrl. I'd appreciate suggestions for where the
definitions of the magic numbers and types ought to go.
- No documentation. I'm happy to add to the relevant docs as appropriate.

I'd appreciate advice on how to proceed from here.

Thanks,
Roger.