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

[Jacob Appelbaum <[e-mail]>]

On 12/2/15, Watson Ladd <[e-mail]> wrote:
> On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum <[e-mail]>
>>
>> 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?
>

Fixed parts of a protocol are often considered as static
distinguishers - most are unavoidable unless you take the Scramblesuit
design approach and have a keyexchanged out of band. Elligator is
another useful design in this direction.

In the case of TLS, we've seen a specific Oakley group used as the
distinguisher that selected all related (TCP) flows for disruption.
Changing that to a (well formed) randomly selected value allowed
traffic to flow freely again. Other static values like a site specific
plaintext name are used much more commonly.

I could imagine for example that all records with a given length can
be selected and dropped, for example. Common VoIP applications that
use fixed lengths are thus even easier to censor with an exposed
length field. With that value hidden and with *random* padding, I
think the ease of selecting specific flows would be reduced and the
cost would be much higher. No everyone needs padding but many people
will want that value hidden without a useful way to do it unless the
protocol supports it by default.

All the best,
Jacob