Weird size of data transmitted in SSLv3
You won't find the answer in the RFC; instead, here's what your SSL implementation is doing: when you send a single byte of data, it actually generates two records.

The first record is empty; so it consists of the 5 byte record header, and the encryption of the 20 byte HMAC tag (which, after encryption padding, is 32 bytes long); this is a total of 37 bytes.

The second record consists of the actual data; so it consists of the 5 byte record header, and the encryption of the data (1 byte) and the 20 byte HMAC tag (which after encryption padding, is 32 bytes long); this is a total of 37 bytes.

This totals to 74 bytes, which is exactly what you're seeing.

Also note that if you send more than 11 characters (and less than 28) of data, then the data along with the 20 byte HMAC data would require 64 bytes; this would extend the total data sent to 90 bytes (again, exactly what you see)

Now, why might an implementation choose to do this?  Well, it's a defense against the BEAST attack.  By including a dummy record up front, it makes the IV used to encrypt the actual data unpredictable (and hence foiling that attack); because the dummy record isn't sent until we actually have the data, the attacker cannot use it's IV value to select the data to encrypt.