Subject: [TLS] the perils of padding

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 7 Apr 2017 12:05:42 -0500

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

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Apr 2017 12:25:35 -0500

> the connection at will already, so it's not really a new thing.

Or, you know, just close the connection.  Give them a fatal record to
tell them why.  No need to tell them up fron how much naughtiness you'll
allow.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 7 Apr 2017 12:28:20 -0500

> tell them why.  No need to tell them up fron how much naughtiness you'll

Right.  But it might be worth adding to the list of things to check
about your implementation in Appendix <mumble>.

-Ben

---

From: Hubert Kario <[email-masked]>
Date: Mon, 10 Apr 2017 13:49:28 +0200

On Friday, 7 April 2017 19:05:42 CEST Benjamin Kaduk wrote:
> regular data after the handshake. 

While this indeed may be a possible attack, it's a symmetric attack - the 
attacker will have to encrypt as much data as the server will decrypt. If he 
or she doesn't do that, the server will reject the records as having incorrect 
mac.

That's a big difference between it, and ealy data, where to server there's no 
difference between correct ciphertext encrypted with unknown key and string of 
random data.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic