Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Peter Gutmann <[e-mail]>]

Bryan A Ford <[e-mail]> writes:

>The idea of encrypting TLS record headers has come up before, the most
>important purpose being to hide record lengths and boundaries and make
>fingerprinting and traffic analysis harder.

Argh, no!  I sent the following to the SSH list a few days ago in support of
someone else's suggestion to finally abandon this misguided idea:

-- Snip --

SSL/TLS have used unencrypted lengths for twenty years without there being any
(known) attack or weakness based on this.  OTOH SSH has used encrypted lengths
for nearly the same period, and there have been several attacks/weaknesses
based on that.  Security-wise, it has the opposite effect of the one intended,
it makes the protocol weaker, not stronger.

My real issue with it though is that, as you've pointed out, it makes it
impossible to create an efficient streaming implementation.  With TLS you read
the length at the start, stream the rest into the target memory location, and
decrypt in place.  With SSH you have to read a single block, decrypt it, make
sure you're not providing an oracle for the attacker, copy what's left around,
read more encrypted data onto the end, decrypt the remainder, ugh.

-- Snip --

Encrypting the length information is a serious step backwards both in terms of
security and processing efficiency.

Peter.