Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Peter Gutmann <[e-mail]>]

Jacob Appelbaum <[e-mail]> 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.