Jacob Appelbaum <ja...@appelbaum.net> writes: >I think the only thing that comes close is when I've named a classified US >government surveillance program (XKeyscore) that would probably have trouble >with it.
Why would XKeyscore have trouble with it? Standard off-the-shelf routers, not even specialised USG surveillance gear, does fairly sophisticated flow tracing, packet reassembly, connection analysis, and so on. It's built into the router. Encrypting the headers is, at best, a minor speedbump to attackers (while being a major headache for implementers, particularly SSH's way of doing it), because they can use the native capabilities of the routing hardware to sidestep the need to decrypt headers. If people really want to address this then they need to do the following: 1. Define a threat model. What are we supposed to be defending against? (Note: The Inside-Out Threat Model, "this is the defence, anything that it prevents is what we're defending against", is not a threat model). 2. List the various measures that can be used to defend against the threat: Fixed-size packets, padding, quantised packet timing, etc. 3. Decide on which ones are necessary to defend against an actual threat, and which ones aren't, taking into account cost/benefit tradeoffs (is the effort/overhead involved worth the gain?). 4. Provide guidance for TLS and SSH developers on how they can implement these. Once that's done (and in particular #1 and #2), we have a framework within which we can decide whether encrypting lengths is worth the annoyance it creates for implementers. Without this, the debate over encrypted lengths is, to quote Linus, nothing more than "people wanking around with their opinions" (and yeah, that includes me). Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
