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

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

Hi Peter,

On 11/28/15 12:15 PM, Peter Gutmann wrote:
> Bryan A Ford <[e-mail]> writes:
> SSL/TLS have used unencrypted lengths for twenty years without there being any
> (known) attack or weakness based on this.  

Leaving all headers in the clear (and in particular record lengths) is a
huge side-channel, and historical experience is that attackers are
getting better and better at exploiting side-channels in surprising
ways.  The CRIME attack, for example, applied to a close relative of TLS
(namely SPDY), and exploited the attacker's ability to learn precise
information about (compressed in this case) record lengths.  I'm not
saying that hiding TLS/SPDY record lengths in particular would
necessarily address the CRIME attack (there were many factors involved
and a combination of weaknesses), but it is certainly an attack in which
the attacker's ability to see fine-grained length information was a
factor.  The general lesson is simply that lengths do represent
sometimes-exploitable side-channels.

> 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.

You're conflating the goal (hiding TLS headers) with one particular old,
broken approach to achieving that goal (namely SSH's). I am not
proposing to hide TLS headers in the same way SSH did, and just because
one historical approach to hiding headers was broken doesn't mean that
the goal itself is a bad idea, or that all possible ways to achieve that
goal are broken, or that my proposal in particular is broken. Feel free
to attack my proposal but then please attack *my* proposal, not the old
broken SSH approach.

I already addressed one specific weakness the SSH approach had and
explained why that's not an issue in my proposal.  You allude to
"several attacks/weaknesses" SSH had: if there were several, can you
summarize or point me to information about the others?  And can you say
whether and in what way any of those past weaknesses in SSH might
conceivably apply to my proposed approach?  I claim you won't be able to
(but would be happy to be shown wrong), because there appears to be a
rather trivial "security proof" that my proposed hiding approach can't
possibly create any new security weaknesses that weren't already in TLS
1.3 as currently specified.  I already outlined that reasoning in my
proposal but will expand on it a bit more below.

> 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.

How exactly does my proposal make it "impossible to create an efficient
streaming implementation"?  Again, it sounds like you're attacking SSH's
broken approach while ignoring my proposal itself.  With my proposal you
can still perform exactly the same optimization just as before:

1. Read the 5-byte TLS header at the start, and decrypt it by XORing
with the output of the stream cipher as my proposal specifies, so you
now have the length.

2. Stream the rest into the target memory location, and AEAD-decrypt in
place.

I don't see how my proposal in any way makes life more difficult for
such streaming optimizations, because my proposal keeps
encryption/decryption of TLS headers separate from encryption/decryption
of the body.  What *might* make this optimization a bit more difficult
is the MAC that the AEAD wants to attach to each ciphertext, but if
that's a problem it's caused by TLS's use of AEAD and has nothing to do
with my proposal.  (That problem can in principle be worked around if
the AEAD cipher implementation has a simple "scatter/gather" capability
so it can put the MAC elsewhere, but that's a completely separate and
orthogonal topic.)

Now, returning to your concern about TLS header hiding creating security
weaknesses: my claim is that all that my proposal introduces is a change
of encoding of the 5-byte TLS header, which cannot possibly introduce
any new security weaknesses because it is not affecting in any way the
actual information content transmitted or received in the protocol or
the way it is processed outside of that header encoding change.

Consider this example:  Suppose we decided we wanted the 2-byte length
field in the TLS header to be transmitted in little-endian rather than
big-endian.  A useless change, yes, but could it create a new security
vulnerability that TLS 1.3 doesn't already have as specified?  Obviously
not; this would yield a perfectly (and provably) equivalent protocol.

Similarly, what if we decided for whatever reason it would be nice to
XOR the 5-byte length field with the constant five-byte sequence
[0x55,0x55,0x55,0x55,0x55]?  Could that create a new security
vulnerability?  Again, obviously not.

What if we decided that the TLS headers of odd-numbered records should
be XORed with [0x55,0x55,0x55,0x55,0x55], and the even-numbered records
should be XORed with [0xaa,0xaa,0xaa,0xaa,0xaa].  Could that create a
new security vulnerability?  No, it's still just an encoding change -
just one that happens to depend dynamically on record number.

What if we decided that the TLS headers should be XORed with an MD5 hash
of the record number?  Again, useless from a security perspective, but
not harmful either: it's still just changing the TLS header encoding
without changing anything else about how the protocol works - and in
particular doesn't change anything about how the record is
AEAD-protected or how the protocol behaves if an attacker flips any bits.

What if we decided that the TLS headers should be XORed with an
HMAC-SHA256 of the record number, keyed with a shared secret used only
for TLS header hiding?  This is now (finally) potentially useful from a
security perspective, and is basically isomorphic to my proposal - but
even if the attacker could break HMAC-SHA256 tomorrow or could learn the
shared secret used for TLS header protection, we would just be back to
the same security level as TLS's current cleartext-header design
achieves; we would still not be introducing any new security weaknesses
that TLS 1.3 doesn't already have.

Again, if you believe my reasoning is in any way flawed here, please
point out how you think my proposal (*not* the old SSH approach) could
conceivably introduce any new security weaknesses that TLS 1.3 doesn't
already have.

Thanks
Bryan