Re: [TLS] Encryption of TLS 1.3 content type

[Yoav Nir <[e-mail]>]

On Jul 28, 2014, at 6:35 PM, Brian Sniffen <[e-mail]> wrote:

> Yoav Nir <[e-mail]> writes:
> 
>> On Jul 28, 2014, at 11:55 AM, Nikos Mavrogiannopoulos <[e-mail]> wrote:
>> 
>>> Are there any pointers to these attacks? Will these attacks be countered
>>> with such a change? I believe not as alert messages consist of only two
>>> bytes and will be distinct from any other higher protocol messages
>>> transferred by the TLS record protocol. Unless TLS 1.3 intended to
>>> include a length hiding mechanism I see this change as unnecessary and I
>>> agree with Watson on that.
>> 
>> While no definite decisions were made, there was a positive response
>> to the idea of allowing arbitrary length padding to the plaintext in
>> all encrypted records, which can be used to hide alert messages.
> 
> It's not clear to me that it can be used to hide alert messages, or the
> structure of the interaction at that level at all.  Can you show me a
> model of a TLS 1.3 client state machine and a TLS 1.3 server state
> machine such that they both do padding, send messages on a clock, and
> otherwise take best-understood precautions against passive
> analysis---and then don't leak when there are alert messages?

Challenge accepted

Assume that the path is deemed wide enough to carry 3 MB/s. We will limit ourselves to slightly less than that, so let’s say 2000 records of 1400B plaintext a second in each direction.

The sender (whether client or server) has two buffers, a system buffer and a data buffer. The application writes to the data buffer. If there’s an error, or the application wishes to close, an alert is placed in the system buffer.

Every half millisecond, the TLS stack performs the following:

* if the system buffer is not empty, retrieve an alert, pad to 1400 bytes, encrypt, and send.
* else if the data buffer is empty, generate a record with 1400 pad bytes, encrypt and send.
* else if the data buffer contains at least 1400 bytes, create a 1400-byte record, remove 1400 bytes from the buffer, encrypt and send.
* else create a record with all remaining data, pad to 1400 bytes, encrypt and send.

This is assuming that the attacker can’t distinguish the number of “ifs” you ran through. Otherwise, don’t send the record, but store it and send it the next time the timer expires. That also takes care of any timing side-channel you have in your encryption function.

Note that I’m not advocating doing this with TLS. IPsec has this feature and to my knowledge nobody uses it.

Yoav