Hello, On 12/3/15, Aaron Zauner <a...@azet.org> wrote: > PS: > > Aaron Zauner wrote: >> No it's not. It's a very short presentation from a TLS-WG interim >> meeting. The threat-model concerns Akamai's (and other's) current and - >> possibly - future use of TLS. We're not trying to build an Onion routing >> protocol. Given the FUD on the Tor dev list, this is a good thing. While >> the presentation might have flaws from the perspective of an Onion >> routing protocol developer, it reflects the point of view of a lot of >> people/companies on this list, I assume. >> > > 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. 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. > If > we wanted to circumvent traffic analysis we'd have to introduce noise > and randomness (Pond does a good job there using Tor and other > mechanisms). I don't see how we can engineer a low-latency (now even > 0-RTT) network security protocol that will do that in a performant > manner. When time comes and people have 10-40-100GE at home, maybe. > Infiniband would be nice. But that will still leave out use for 3rd > world countries (which still run on XP anyway). This is a technical list > and we should keep politics and FUD aside as best as possible. The architecture of the network protocol is the politics. There is no separation. RFC1984 and RFC 7258 cover this topic nicely. All the best, Jacob _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
