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

[Aaron Zauner <[e-mail]>]

Hey,

Jacob Appelbaum wrote:
>> I don't think traffic analysis is in the treat model for TLS proper.
> 
> I'm confused by what you mean by traffic analysis. We encrypt content
> in TLS because we know that we want confidentiality. We want that
> because we know people do basic traffic analysis looking for sensitive
> data in plaintext.

I don't work in SIGINT nor for commercial networking vendors so I always
have used jargon I picked up from Wikipedia:
```
Traffic analysis is the process of intercepting and examining messages
in order to deduce information from patterns in communication. It can be
performed even when the messages are encrypted and cannot be decrypted.
In general, the greater the number of messages observed, or even
intercepted and stored, the more can be inferred from the traffic.
``` -- https://en.wikipedia.org/wiki/Traffic_analysis

My example, Pond, counters this with padding, randomized traffic
patterns and - of course - Tor [0]. I'm just saying this is unpractical
for a low-latency protocol such as TLS. I think we all agree there.

> 
> There are many kinds of traffic analysis adversaries. I think TLS
> isn't trying to beat a global active adversary, for example, while
> also providing anonymity. It seems that TLS is trying to beat a global
> passive adversary from violating the confidentiality of the protocol.
> 
> A lack of confidentiality in many cases allows for attackers to do
> better traffic analysis and selective denial of service attacks.
> Failure to deal with very simple traffic analysis leads to much more
> serious attack vectors being actively exploited in the wild.

See my last message, I'm absolutely for encrypted-SNI. If it's feasible.
If we end up with some compromise, maybe. But what we have now is
nowhere near ideal.

BTW, I played with SNI DoS a few months back (not too much though as it
wasn't worth a paper), seems not to be as bad as it used to be because
implementations nowadays have at least some counter-measures.

> The architecture of the network protocol is the politics. There is no
> separation.
> 
> RFC1984 and RFC 7258 cover this topic nicely.

Bashing on random companies won't get us anywhere. I agree with you, but
it's off-topic here. Most of the participants here do not represent
their employer and even though some might have made a bad employment
choice, it's up to them. They mostly speak for themselves and bring
valuable implementer opinion to the table. Some break TLS on a massive
scale and this is a problem (we have a vendor-nickname for a certain TLS
extension after all). See also RFC7624, RFC7696.

Aaron

[0] -  https://pond.imperialviolet.org/tech.html
       (Ctrl+S "traffic profile")