On 11/29/15 12:29 PM, Henrick Hellström wrote: > On 2015-11-29 10:48, Bryan A Ford wrote: >> In short, leaving TLS headers in cleartext basically hands any >> eavesdropper a huge information side-channel unnecessarily and precludes >> anyone*but* the TLS implementation itself from adding any traffic >> analysis protection into the system. Encrypting TLS headers appears to >> cost practically nothing (at least if done as I've proposed), and it >> allows traffic analysis protection (whether weak or strong, intentional >> or unintentional) to be introduced at multiple points: e.g., by TLS >> itself, or by the TCP stack, or by middleboxes. > > Thank you for the explanation. A few points: > > The only way to completely thwart traffic analysis, is to always send > data with the exact same amount-frequency pattern. The middleboxes you > describe will *not* be able to achieve this, unless the TLS sender is > adapted for such processing anyway.
Very true. But perfect traffic analysis protection isn't the only goal of interest, and is usually impractical anyway. A less ambitious but still worthwhile goal is simply to make sure that in imperfectly-protected connections, transmission bursts leak as little of their internal structure as possible even though the timing and burst of the (whole) burst will still inevitably risk leaking something. Even when it's impractical to leak nothing, it's still worthwhile to leak less. A fairly important common-case example of this, I think, is Web page loads in which the client submits a bunch of requests in parallel over the same connection. This was never widely enabled in HTTP/1.1 due to compatibility concerns but will probably become the norm quickly with HTTP/2.0. A TLS implementation designed without much concern for traffic analysis will probably send those multiple small requests/replies in separate TLS records, giving eavesdroppers a nice fine-grained fingerprint of what all is in that transmission burst. If TLS 1.3 hides its headers, then either the TLS implementation, the TCP stack, or a middlebox could readily scrub that internal structure and at least make life harder for the attacker (e.g., reduce the bandwidth of the side-channel). That seems worthwhile to me if it doesn't cost much. Cheers Bryan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
