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")
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
