[TLS] the perils of padding

[Benjamin Kaduk <[e-mail]>]

With TLS 1.3 we have this new padding scheme for encrypted records, and
even allow for padding-only records (of nominal internal content type
"application data").  This is generally a good thing, in that it gives a
lot of degrees of freedom to introduce countermeasures to traffic
analysis, but perhaps we are overgenerous.  There doesn't seem to be
anything preventing a peer from sending only padding records and never
any application data, whether that is in the client's early data or in
regular data after the handshake.  Now, in some situations you may want
to do just that, if you want to keep a channel open and it will only
ever send one legitimate signal ("fire the missiles!") but you want to
avoid revealing when that happens via traffic analysis.  In other cases,
it just uses resources without giving an event to the application so as
to let the application say "enough of this".

I first noticed this in the context of early data, where a malicious
client can chew up a server's resources indefinitely at the TLS layer
during the handshake, by negotiating early data and then trickling (or
spewing) 0-length application data records with padding and never
finishing the handshake.  We have the max_early_data_size limit that
intends to limit how much early data can be sent; the original
motivation for this was to limit how much trial decryption a server must
do if it doesn't have the key material needed for it, but it also looks
like it should serve as a bound on finishing the handshake.

In some sense this is not new, as a malicious peer could always string
things out by sending highly fragmented records slowly, but the padding
allows a way to string things out while making absolutely no progress at
all, which seems to be qualitatively different, and worth spending some
time considering whether countermeasures are appropriate.

One simple and easy option is to have a new extension to indicate the
maximum consecutive padding that will be accepted by an endpoint, and
abort the connection if too much padding is received in a row without
any non-padding content.  But that might be too complicated, and we
could just note that implementations may get grumpy if they see too much
padding and abort the connection; peers are basically allowed to abort
the connection at will already, so it's not really a new thing.

-Ben