Re: [saag] Ubiquitous Encryption: content filtering

[Christian Huitema <[e-mail]>]

On Monday, June 22, 2015, at 2:12 PM, Nico Williams wrote:

> ..
> But it isn't just a matter of engineering the protocol.  There are security
> problems involved in making this happen (like: how do you express to the user
> that there is one (or more!) middle box filtering and/or modifying their traffic?
> how do users get to opt out?  how is scope limited?  (e.g., how do you prevent
> the device/operator from MITMing the user when the user is NOT using the
> operator's network?)).

And that's a good reason for not engineering a specific hole in our protocols!

> And anyways, operators already get to do this by simply forcing users to use
> devices from the operators (modified to have MITM CA trust anchors).

Except, we really want to close that particular hole, don't we? I don't know which particular combination of caching, logs and third party referrals we will end up standardizing, but we have to assume that the security stack will eventually detect this kind of meddling, and expose it. At a minimum, this is going to be a significant PR issue for any telco playing that game.

Generic content filtering is not compatible with encryption. That's pretty clear. But if I followed the debates correctly, the actual requirement is site blocking, not generic content filtering. The per site filtering can actually be performed without an MITM attack. If the site uses its own IP addresses, then the operators can filter those IP addresses. If the site used a shared address, then the TLS packets contain a clear text SNI, and firewall magic could drop these connections.

I am not very happy about the clear text SNI, but it does not seem to be going away any time soon.

-- Christian Huitema