Re: [saag] Ubiquitous Encryption: content filtering

[Nico Williams <[e-mail]>]

On Mon, Jun 22, 2015 at 03:13:36PM -0700, Ted Hardie wrote:
> On Mon, Jun 22, 2015 at 2:46 PM, Nico Williams <[e-mail]>
> wrote:
> > Authorized MITMing is fundamentally a part of any hierarchical
> > distributed, public key authentication system when the user does not
> > have full control of their user agent. We can detect it in some cases
> >
> when it's unwanted, but if it is "authorized" (by the "owner" of the
> > device) then it's going to happen.
> >
> >
> I'm a little confused by the quotes around both authorized and owner in
> the statement above.  If a user has caused her device to use a proxy for a
> specific protocol by configuration, that user has authorized that proxy's
> activities.  If the user has instead initiated flows with the expectation
> that they are going to the named service, rather than a proxy, then any
> monkey in the middle is not authorized by the user.

I used scare quotes because who the owner is, and whether the unwanted
behavior is authorized may not be obvious at first glance.

The user may not be the device's "owner" in some sense.  E.g., the
device may be locked, thus the user may not have permission to remove
MITM CA certs from the device's trust anchors, and so on.  The user may
have paid for the device and think they are the owner, but effectively
they aren't when the device is locked and the vendor and/or operator are
contractually (or otherwise legally) free to insert MITM CA certs into
the device's trust anchor set.

> > Maybe.  I assume many operators are doing this now, so whatever PR
> > problems might result from starting to filter, they are in the past for
> > many operators.
> 
> As others have mentioned, things change when you shift from intercepting
> unencrypted channels to intercepting encrypted ones, as you are making a
> much larger effort to impersonate the service.  That may be a difference of
> degree, but it looks like a difference in kind.

No doubt!  And I don't disagree.  I was merely pointing out facts.
(Namely: the operators are barking up the wrong tree; they already have
the protocol features that they need and are merely [perhaps] missing
the tools and/or legal framework to do what they think they are being
required to do.)

In any case, I agree with Stephen F. that regulated operators aren't
likely to get more than they already have because the IETF shouldn't be
catering to these needs for all the reasons that Stephen alluded to.
(Among others: regulations in different localities may conflict in such
a way as to leave the IETF with no clear way forward to satisfy them
all.)

Nico
--