This affects TLS1.3 client and server sessions.  It does not
affect TLS1.2 sessions.

Discussion
==========

RFC8446 says of the "Middlebox Compatibility Mode" feature:

  Either side can send change_cipher_spec at any time during
  the handshake, as they must be ignored by the peer

This unnecessary flexibility meant we can't weave an
optional receipt of a CCS into our state machine (like we did for TLS1.2),
so we just drop CCS messages received after negotiating TLS1.3.

That's a problem, though: CCS messages are 6 bytes long, and many
can be delivered in a single TCP segment.  Each one results in a
small but non-zero amount of processing.

However, this code path is fast: in benchmarks rustls can drop ~4 million
CCSs per second, per core.  In the PoC code graciously provided by the
reporter, ~168Mbps of traffic needs to pass over lo to saturate a single
CPU core (you'll note these measurements agree with each other, to an order
of magnitude).

It's really likely that a better overall DoS vector is *just sending ClientHellos*,
where each core can only process ~thousands per second, for the cost of ~200 bytes;
ie 250Kbps (as an order of magnitude) to saturate one core.  This is especially
powerful if TFO is supported by both hosts.  But it's also more noisy.

So while this vulnerability is not thought to be serious, we can fix it
at negligible cost: only allow a maximum of one CCS per TLS1.3 handshake.

Thanks to Lenny Wang of Tencent Security Xuanwu Lab for the report.