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

[Bryan Ford <[e-mail]>]

On 02 Dec 2015, at 02:24, Peter Gutmann <[e-mail]> wrote:
> 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).

We have repeatedly stated several relevant threat models here; you just don’t seem to be accepting them as threat models for some reason.  One is the passive eavesdropping attacker, who can monitor flows but cannot easily inject traffic; mass monitoring of tapped fibre optic cables are one specific real-world example of that.  Another is the “partly-active” attacker who can inject packets but cannot readily prevent the legitimate packets from arriving; two very real-world examples of this are XKEYSCORE/QUANTUMINSERT and the WiFi internet cafe snooper.  In each of these real-world threat models the “dribble attack” to sniff out record boundaries via full MITM is not an option for the attacker, and hence there is potential benefit to encrypted record headers even without any other anti-traffic-analysis measures.

> 2. List the various measures that can be used to defend against the threat:
>   Fixed-size packets, padding, quantised packet timing, etc.

We have been doing this as well, repeatedly.  And as I’ve stated repeatedly and you have not refuted, having encrypted packet headers allows us to deploy some of those defense measures in multiple places in the network (e.g., TCP stack and/or middle boxes) rather than just one (TLS implementation).

B