Re: [TLS] Encryption of TLS 1.3 content type

[Brian Sniffen <[e-mail]>]

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?

I expect closing a connection leaks quite a bit about what came just
before the close.  I expect timing leaks quite a bit---and an adversary
who can be slightly active (e.g., opening his own connection to the
server) can learn about timing differences between alerts and ordinary
data.  I don't see how to keep content-type secret without lock-step
timing---which requires not just padding, but a habit of sending
packets with no application data, just padding, on clock ticks.  That's
extremely expensive for performance, if we make a general practice of it.

-Brian


-- 
Brian Sniffen
Information Security
Akamai Technologies