Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

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

On 12/2/15 4:45 PM, Watson Ladd wrote:
> On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum <[e-mail]> wrote:
>> On 12/2/15, Eric Rescorla <[e-mail]> wrote:
>>> It's not really clear to me what the anti-traffic-analysis benefit of your
>>> proposal
>>> is over and above just padding everything to a fixed size. That's certainly
>>> far
>>> easier for the implementation to do, especially in typical stacks where the
>>> application just calls SSL_Write (or whatever) and so there's no obvious
>>> API point to provide the "next length", so as a practical matter the stack
>>> will very often if not always be in "last block" mode.
>>>
>>
>> I think that it eliminates all static distinguisher in the protocol
>> for all data covered by the encryption. That is a fantastically
>> wonderful benefit.
> 
> What's a "static distinguisher"? Padding solves this problem as well,
> but it also solves problems resulting from TCP segmentation down the
> stack, which header encryption doesn't. What does header encryption
> offer that padding does not?

Once again (for the n'th time in this thread):  Padding is great and we
should encourage implementations to do it, but it may be impractical to
mandate (a) that *every* TLS 1.3 implementation use padding all the
time, and (b) that *every* implementation that does use padding uses the
*same* padded record size as every other TLS implementation.

If TLS 1.3 did mandate that all implementations always pad to the same
standard-defined record length (to echo Viktor Dukhovni, GO ATM! GO ATM!
:) ), then it might be arguably the case that encrypting headers
wouldn't add any further benefit.

But short of that, encrypting TLS headers makes it strictly harder for a
passive adversary - or an active adversary who can only inject but not
block traffic - to distinguish between padded or unpadded TLS 1.3
streams, or to distinguish between TLS 1.3 streams padded to different
block sizes.

In particular, with encrypted records, we get a guarantee that nothing
in the transmitted TCP stream content itself leaks information about the
internal pattern of records, even if it's un-padded or differently
padded from other streams.  The attacker has to use other side-channels
to perform such distinguishing attacks, and other side-channels are
often lower-bandwidth (e.g., the total length of whole streams or bursts
rather than individual records), and/or more noisy (e.g., the lengths
and timings of TCP segments, which may get retimed and/or resegmented by
all sorts of activities both at the endpoints and in the network).

B

> 
> Sincerely,
> Watson
>