On 12/2/15, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > 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?
My point was that we're hearing a lot of concern trolling for vendors and the only "vendor" that has been explicitly named is XKeyscore: a "vendor" that is without a doubt one that we want to protect against. > 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. Absolutely and this proposal will do nothing to change that for on path TLS 1.3 with TCP and probably for TLS 1.3 DTLS. > 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 they are only a partial observer, I think Bryan's suggestion changes the game for TLS and DTLS to leak less information. If they are a full on path observer, they will have the full leaks of information made possible from TCP. Thus when composed with an anonymizing service, we'll find that these changes contribute to a full solution. > > 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. A global passive adversary with a partial view is already harmed by the changes that have been proposed. A global active adversary with a partial view would be stymied too. Bryan has already said it in the thread and replied but I'll agree with him: we've done it and you're seemingly ignoring it. Furthermore some people are concerned about surveillance vendors that are not *opt-in* by the user - rather than treating that concern as abstract, I'd like to see what specific vendors we should help to weaken the security properties of TLS 1.3. > > 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. > I think this is better left in the part of the thread where Bryan responded - so I'll follow up there next. > 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). It is not an opinion that TLS is a metadata leaking protocol and it is seems that Bryan has found a way to reduce that leakage. With DTLS and UDP - a surveillance vendor will have very little metadata comparatively once Bryan's solution is part of the spec. All the best, Jacob _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
