[tls] Centralise pseudorandom data generation

[tls] Centralise pseudorandom data generation

TLS version 1.3 has a formal key schedule based on HKDF, and requires
the client to be able to recall ephemeral secrets at multiple points
within the connection lifecycle.  For example: the ephemeral private
key for X25519 key exchange may be required when constructing
ClientHello (for a TLS version 1.3 key share) or when constructing
ClientKeyExchange (if subsequently falling back to use TLS version
1.2), and again when parsing a ServerHello key share or a
ServerKeyExchange.

Some ephemeral private keys may be large (e.g. for ffdhe4096).  Avoid
the need to store these large (and variably sized) private keys by
instead instantiating a standalone HKDF instance that we seed with
per-connection random data and subsequently use to generate ephemeral
private keys on demand.  (Note that this instance is unrelated to the
HKDF instance defined in the formal key schedule for TLS: we are
choosing to reuse HKDF for this purpose simply because supporting TLS
version 1.3 will already require HKDF support to be present.)

We use the key exchange algorithm name (e.g. "x25519") as additional
information to ensure separation between keys used for different
purposes.  Since the initial random seed is generated afresh for each
connection, and since there can meaningfully be only one ephemeral
private key per key exchange algorithm per connection, this is
sufficient to ensure separation.

Having instantiated this HKDF, we then also use it to generate the
client random bytes (with the label "client random"), to generate the
random portion of the pre-master secret for classic RSA key exchange
(with the label "classic pre-master"), and to generate the random
portion of record IVs (using the authentication header structure,
which is already guaranteed to be unique per record within a
connection).  Doing this allows us to eliminate all other calls to the
RNG, and removes some potential failure paths.

We reset the HKDF on a connection restart and on connection close, to
preserve the property of forward secrecy.

Signed-off-by: Michael Brown <mcb30@ipxe.org>