Subject: [saag] Ubiquitous Encryption: content filtering

From: Natasha Rooney <[email-masked]>
Date: Thu, 18 Jun 2015 07:58:07 +0000

Hi all,

I have a new submission for the Ubiquitous Encryption draft. I must admit, this one is a little controversial, and certainly is not something I believe in. However, I had a good think about it, and figured that this is an "effect" of ubiquitous encryption, and maybe would be beneficial for the draft. I am not expecting anything comes out of adding it past education for members of the IETF community that this is an issue for some organisations, governments and maybe users. Please feel free to tweet me if you want to discuss personal views! Anyway, here we go:

2.3.X Content Filtering
Law agencies may request Service Providers to block access to particular sites such as online betting and gambling, sites promoting anorexia, or access to dating sites. Content filtering in the mobile network usually occurs in the core network. A proxy is installed which analyses the transport metadata of the content users are viewing and either filters content based on a blacklist of sites or based on the user’s pre-defined profile (e.g. for age sensitive content). Although filtering can be done by many methods one common method occurs when a DNS lookup reveals a URL which appears on a government or recognised block-list. The subsequent requests to that domain will be re-routed to a proxy which checks whether the full url matches a blocked url on the list, and will return a 404 if a match is found. All other requests should complete.

Even in encrypted connections transport and lower layer metadata is able to be viewed so for many systems content filtering should be able to continue. Cases when they may not work is when TLS proxies are being used which obscure metadata with the proxy metadata, and future versions in HTTP and TCP may encrypt metadata again stopping content filtering software from working (this is currently not the case and has not been standardised).

Some sites involve a mixture of universal and age-sensitive content and filtering software in these cases may use more granular (application layer) metadata to analyse and block; this will not work on encrypted content.

I do have a few questions about what I have written, maybe someone can answer:
[1] Does HTTP2 multiplexing do anything to content filtering software, i.e. when sending multiple requests for one webpage (loading images in particular). I don’t think it does it’s just that my brain isn’t working this afternoon...
[2] Is it fair to mention future versions of HTTP and TCP when nothing has been standardised yet? I don’t think so in which case maybe this should be removed.

Hope this didn’t ruin everyones morning! Thanks!

Natasha

Natasha Rooney | Web Technologist | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>
Tokyo, Japan

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 19 Jun 2015 09:10:05 -0400

I would at least like this to acknowledge that it's possible to do
filtering at the endpoint. As you can imagine, I would argue another
term for content filtering is censorship. best, Joe

On Thu, Jun 18, 2015 at 3:58 AM, Natasha Rooney <[email-masked]> wrote:
> Hi all,
>
> I have a new submission for the Ubiquitous Encryption draft. I must admit,
> this one is a little controversial, and certainly is not something I believe
> in. However, I had a good think about it, and figured that this is an
> "effect" of ubiquitous encryption, and maybe would be beneficial for the
> draft. I am not expecting anything comes out of adding it past education for
> members of the IETF community that this is an issue for some organisations,
> governments and maybe users. Please feel free to tweet me if you want to
> discuss personal views! Anyway, here we go:
>
>
> 2.3.X Content Filtering
> Law agencies may request Service Providers to block access to particular
> sites such as online betting and gambling, sites promoting anorexia, or
> access to dating sites. Content filtering in the mobile network usually
> occurs in the core network. A proxy is installed which analyses the
> transport metadata of the content users are viewing and either filters
> content based on a blacklist of sites or based on the user’s pre-defined
> profile (e.g. for age sensitive content). Although filtering can be done by
> many methods one common method occurs when a DNS lookup reveals a URL which
> appears on a government or recognised block-list. The subsequent requests to
> that domain will be re-routed to a proxy which checks whether the full url
> matches a blocked url on the list, and will return a 404 if a match is
> found. All other requests should complete.
>
> Even in encrypted connections transport and lower layer metadata is able to
> be viewed so for many systems content filtering should be able to continue.
> Cases when they may not work is when TLS proxies are being used which
> obscure metadata with the proxy metadata, and future versions in HTTP and
> TCP may encrypt metadata again stopping content filtering software from
> working (this is currently not the case and has not been standardised).
>
> Some sites involve a mixture of universal and age-sensitive content and
> filtering software in these cases may use more granular (application layer)
> metadata to analyse and block; this will not work on encrypted content.
>
>
> [1] Does HTTP2 multiplexing do anything to content filtering software, i.e.
> when sending multiple requests for one webpage (loading images in
> particular). I don’t think it does it’s just that my brain isn’t working
> this afternoon...
> [2] Is it fair to mention future versions of HTTP and TCP when nothing has
> been standardised yet? I don’t think so in which case maybe this should be
> removed.
>
> Natasha Rooney | Web Technologist | GSMA | [email-masked] | +44 (0) 7730
> 219 765 | @thisNatasha | Skype: [email-masked]
> Tokyo, Japan
>
>
> This email and its attachments are intended for the above named only and may
> be confidential. If they have come to you in error you must take no action
> based on them, nor must you copy or show them to anyone; please reply to
> this email or call +44 207 356 0600 and highlight the error.
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Fri, 19 Jun 2015 14:07:53 +0000

> I would at least like this to acknowledge that it's possible to do filtering at the endpoint. As you can imagine, I would argue another term for content filtering is censorship. best, Joe

Hi Joe,

Indeed, it is possible to filter at the endpoint. However, a mobile operator utilising licenced spectrum must adhere to regulations set by the government licensor, which include content filtering, or risk fines/licence suspension. The rise in end-to-end encryption may well change this situation; as if the regulators cannot constrain access via the operator network, it is likely they will look to other means. I'm in discussion with our legal and regulatory teams and aim to present on this at the workshop.

> As you can imagine, I would argue another term for content filtering is censorship.

Fair point, but we should focus on the technical options (e.g. endpoint vs. network filters) for the scope of this workshop. 

All best
Kevin

Kevin Smith, Vodafone R&D

-----Original Message-----
From: saag [mailto:[email-masked]] On Behalf Of Joseph Lorenzo Hall
Sent: 19 June 2015 14:10
To: Natasha Rooney
Cc: [email-masked]
Subject: Re: [saag] Ubiquitous Encryption: content filtering

I would at least like this to acknowledge that it's possible to do filtering at the endpoint. As you can imagine, I would argue another term for content filtering is censorship. best, Joe

On Thu, Jun 18, 2015 at 3:58 AM, Natasha Rooney <[email-masked]> wrote:
> Hi all,
>
> I have a new submission for the Ubiquitous Encryption draft. I must 
> admit, this one is a little controversial, and certainly is not 
> something I believe in. However, I had a good think about it, and 
> figured that this is an "effect" of ubiquitous encryption, and maybe 
> would be beneficial for the draft. I am not expecting anything comes 
> out of adding it past education for members of the IETF community that 
> this is an issue for some organisations, governments and maybe users. 
> Please feel free to tweet me if you want to discuss personal views! Anyway, here we go:
>
>
> 2.3.X Content Filtering
> Law agencies may request Service Providers to block access to 
> particular sites such as online betting and gambling, sites promoting 
> anorexia, or access to dating sites. Content filtering in the mobile 
> network usually occurs in the core network. A proxy is installed which 
> analyses the transport metadata of the content users are viewing and 
> either filters content based on a blacklist of sites or based on the 
> user’s pre-defined profile (e.g. for age sensitive content). Although 
> filtering can be done by many methods one common method occurs when a 
> DNS lookup reveals a URL which appears on a government or recognised 
> block-list. The subsequent requests to that domain will be re-routed 
> to a proxy which checks whether the full url matches a blocked url on 
> the list, and will return a 404 if a match is found. All other requests should complete.
>
> Even in encrypted connections transport and lower layer metadata is 
> able to be viewed so for many systems content filtering should be able to continue.
> obscure metadata with the proxy metadata, and future versions in HTTP 
> and TCP may encrypt metadata again stopping content filtering software 
> from working (this is currently not the case and has not been standardised).
>
> Some sites involve a mixture of universal and age-sensitive content 
> and filtering software in these cases may use more granular 
> (application layer) metadata to analyse and block; this will not work on encrypted content.
>
>
> particular). I don’t think it does it’s just that my brain isn’t 
> working this afternoon...
> [2] Is it fair to mention future versions of HTTP and TCP when nothing 
> has been standardised yet? I don’t think so in which case maybe this 
> should be removed.
>
> 219 765 | @thisNatasha | Skype: [email-masked] Tokyo, Japan
>
>
> This email and its attachments are intended for the above named only 
> and may be confidential. If they have come to you in error you must 
> take no action based on them, nor must you copy or show them to 
> anyone; please reply to this email or call +44 207 356 0600 and highlight the error.
>
>

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 19 Jun 2015 11:57:57 -0400

> Indeed, it is possible to filter at the endpoint. However, a mobile operator utilising licenced spectrum must adhere to regulations set by the government licensor, which include content filtering,…

Text that expresses the intent you've described here I think would be
useful if Natasha's text is pulled in.

> Fair point, but we should focus on the technical options (e.g. endpoint vs. network filters) for the scope of this workshop.

Totally understood. (workshop? or I-D?)

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Jun 2015 17:45:55 +0100

Hi Kevin, Natasha,

On 19/06/15 15:07, Smith, Kevin, (R&D) Vodafone Group wrote:
> Indeed, it is possible to filter at the endpoint. However, a mobile
> operator utilising licenced spectrum must adhere to regulations set
> by the government licensor, which include content filtering, or risk
> fines/licence suspension.

Just to note that IETF is not in the same position as mobile operators
here. Please see RFC 2804 for a good example of that kind of difference
(but note 2804 deals with a different topic).

That's not to say what the IETF consensus on such filtering/censorship
might or might not be - I don't think we've asked and I expect there'd
be a robust debate if we do, as there was for 2804.

So even if thing-X is required by some local regulator, that does not
by itself mean that the IETF needs to care about thing-X.

I'm sure this is familiar to many long time IETF participants, but it
may well not be commonly understood by some others who would consider
the argument Kevin makes above as a winning argument.

Cheers,
S.

PS: The mailing list archive for discussion that lead to 2804 is still
around [1] and many of the arguments made then would still be relevant
were we to delve further into this topic, or any other local-regulator
vs. big-I Internet type thing.

[1] https://www.ietf.org/mail-archive/web/raven/current/maillist.html

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Jun 2015 09:34:36 +0900

> a mobile operator utilising licenced spectrum must adhere to
> regulations set by the government licensor

out of range error.  see rfc 2804

randy

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Jun 2015 16:25:28 -0400

Stephen,

> ...
On purely technical grounds, an argument for filtering in the "middle"
is reasonable. It's much easier for a mobile operator, an ISP, or an 
enterprise
IT organization to perform content filtering at an intermediate point 
than to try t
o do so in every end point device. That's a major reason why enterprise 
IT folks
prefer perimeter firewalls over endpoint firewalls. It's very difficult and
expensive to manage (security) software on a large number of user devices,
and it's even worse when those devices are diverse (e.g., Windows vs. Mac
vs. Lunix or iOS vs. Android, vs. ...).

So, from an engineering perspective, the argument about the conflict between
end-to-end encryption and operator (including enterprise IT staff) access to
traffic is a valid consideration, irrespective of the telecom-regulator 
argument.

Steve

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 Jun 2015 16:12:08 -0500

On Mon, Jun 22, 2015 at 04:25:28PM -0400, Stephen Kent wrote:
> is reasonable. It's much easier for a mobile operator, [...]
> 
> So, from an engineering perspective, the argument about the conflict
> between end-to-end encryption and operator (including enterprise IT
> staff) access to traffic is a valid consideration, irrespective of the
> telecom-regulator argument.

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 anyways, operators already get to do this by simply forcing users to
use devices from the operators (modified to have MITM CA trust anchors).
What new technology is being requested here, regardless of whether
we'd publish it (though the current position as to that is clear: no;
but the IETF consensus can always change)?

Nico
--

---

From: Christian Huitema <[email-masked]>
Date: Mon, 22 Jun 2015 21:24:04 +0000

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 Jun 2015 16:46:51 -0500

On Mon, Jun 22, 2015 at 09:24:04PM +0000, Christian Huitema wrote:
> > problems involved in making this happen (like: [...]
> 

Or at least being very careful about it.

> Except, we really want to close that particular hole, don't we? I

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.

All the more reason to ask why we're even discussing this.

> 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.

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.

Nico
--

---

From: Ted Hardie <[email-masked]>
Date: Mon, 22 Jun 2015 15:13:36 -0700

> 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.

Those activities are taking place to further the interests of other
parties.  For interception devices in a wireless network, those interests
might include inspection of the traffic type so that QoS may be assigned;
transcoding; content deletion; content insertion; and so on.

> problems might result from starting to filter, they are in the past for
​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.​

​regards,

Ted​

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 Jun 2015 17:41:27 -0500

On Mon, Jun 22, 2015 at 03:13:36PM -0700, Ted Hardie wrote:
> I'm a little confused by the quotes around both authorized and owner in

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.

> As others have mentioned, things change when you shift from intercepting
> 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
--

---

From: Randy Bush <[email-masked]>
Date: Tue, 23 Jun 2015 13:36:08 +0900

> enterprise IT organization to perform content filtering at an
> intermediate point than to try to do so in every end point device.
> That's a major reason why enterprise IT folks prefer perimeter
> firewalls over endpoint firewalls. It's very difficult and expensive
> to manage (security) software on a large number of user devices, and
> it's even worse when those devices are diverse (e.g., Windows vs. Mac

and that is working out so well, see OPM disaster

can you say soft gooey inside?

randy

---

From: Tom Ritter <[email-masked]>
Date: Mon, 22 Jun 2015 23:44:10 -0500

On 22 June 2015 at 16:24, Christian Huitema <[email-masked]> wrote:
> If the site used a shared address, then the TLS packets contain a clear text SNI, and firewall magic could drop these connections.
>

Many of us aren't, as it's been used at the nation level for
censorship. We're working on TLS 1.3, and our hope now is that it will
have the capability to do encrypted SNI through the use of pre-shared
keys provided over (e.g.) DNS or a prior connection.

DNS leaks it also, but it's already possible to configure a local
unbound instance to talk to a remote resolver over TLS; so that
protocol a way forward for DNS Privacy (which is also being worked on)
that already has some running code.

-tom

---

From: Natasha Rooney <[email-masked]>
Date: Tue, 23 Jun 2015 08:47:13 +0000

Thanks guys for this - and sorry for the on-list tech check: but, isn’t SNI configured by the content server. So, if I have run https://evil.com, can’t I just, not use SNI?

Natasha

On Jun 23, 2015, at 6:44 AM, Tom Ritter <[email-masked]<mailto:[email-masked]>> wrote:

On 22 June 2015 at 16:24, Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:
If the site used a shared address, then the TLS packets contain a clear text SNI, and firewall magic could drop these connections.

-tom

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 23 Jun 2015 04:59:03 -0400

Thanks for the discussion on this, it's helpful to get this right for
documentation purposes.  I'd split out MiTM activities of this sort for
enterprises vs. the same done at the service provider level because of
employee agreements.  I also choose not to go to many sites from behind a
firewall and hope others do too when signaled that there is a certificate
mismatch.

On Tue, Jun 23, 2015 at 4:47 AM, Natasha Rooney <[email-masked]> wrote:

>  Thanks guys for this - and sorry for the on-list tech check: but, isn’t
> SNI configured by the content server. So, if I have run https://evil.com,
> can’t I just, not use SNI?
>
> Natasha
>
>
> Natasha Rooney | Web Technologist | GSMA | [email-masked] | +44
> (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]
> Tokyo, Japan
>
>
>  On Jun 23, 2015, at 6:44 AM, Tom Ritter <[email-masked]> wrote:
>
> If the site used a shared address, then the TLS packets contain a clear
> text SNI, and firewall magic could drop these connections.
>
> This email and its attachments are intended for the above named only and
> may be confidential. If they have come to you in error you must take no
> action based on them, nor must you copy or show them to anyone; please
> reply to this email or call +44 207 356 0600 and highlight the error.
>

-- 

Best regards,
Kathleen

---

From: Yoav Nir <[email-masked]>
Date: Tue, 23 Jun 2015 12:20:40 +0300

> On Jun 23, 2015, at 11:59 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Thanks for the discussion on this, it's helpful to get this right for documentation purposes.  I'd split out MiTM activities of this sort for enterprises vs. the same done at the service provider level because of employee agreements.  I also choose not to go to many sites from behind a firewall and hope others do too when signaled that there is a certificate mismatch.

I’m not sure if that distinction is meaningful. The technology for interception is the same whether it is used to scan downloaded files for malware or to scan Facebook posts for insufficient appreciation of our Dear Leader.

Employees in a corporate environment are supposedly informed, but corporate computers and devices may come pre-installed with the interception certificate. Even as a conscientious vendor, there is no way I can enforce that corporate IT properly informs the employees. 

Similarly, we’ve seen interception used at service providers at the behest of governments. In some countries devices come pre-installed with the government interception certificate. This makes it transparent to the citizens. Again, it would be nice if citizens at least knew this was happening, but those governments tend to not be “nice”.  At least ISPs don’t have the power to manipulate the endpoints (though in the early days of broadband they would ask you to install a “dialer” - if I were a more suspicious person…), but they do when they work for the government. 

Ideally a solution would reveal the presence of a MITM to both client and server. All solutions discussed thus far can reveal things to the client, but do nothing for the server. I would like to have servers such as financial institutions and medical services be able to enforce a policy where they don’t provide a service through a middlebox. Doing it now requires installing their own client on the user’s machine, which seems to be a trend in mobile, but is not something we should require.

Yoav

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 23 Jun 2015 05:48:44 -0400

On Tue, Jun 23, 2015 at 5:20 AM, Yoav Nir <[email-masked]> wrote:

> I’m not sure if that distinction is meaningful. The technology for
> interception is the same whether it is used to scan downloaded files for
> malware or to scan Facebook posts for insufficient appreciation of our Dear
> Leader.
>

Sure, I'm aware the same technique is sometimes used for both scenarios,
but not always.  It's easy for a company with an agreement to set up a
proxy that has 2 TLS sessions, one between the user and proxy and the other
from the proxy to the destination site.  Other techniques have been used
(see UTA's TLS attack RFC - 7457) at the service provider level, including
stopping the STARTTLS negotiation.

Some have used techniques that are less visible to the user.  As problems
are fixed in the protocol, what is done shifts of course.

> Employees in a corporate environment are supposedly informed, but
> corporate computers and devices may come pre-installed with the
> interception certificate. Even as a conscientious vendor, there is no way I
> can enforce that corporate IT properly informs the employees.
>

I'm sure this varies between regions.  I just think enterprises can be more
deliberate about it with user agreements and not worry about error
messages.  Sure, the sam thing can be done in a pre-installed way, but a
user can check the certs if they know enough.

>
> Similarly, we’ve seen interception used at service providers at the behest
> of governments. In some countries devices come pre-installed with the
> government interception certificate. This makes it transparent to the
> citizens. Again, it would be nice if citizens at least knew this was
> happening, but those governments tend to not be “nice”.  At least ISPs
> don’t have the power to manipulate the endpoints (though in the early days
> of broadband they would ask you to install a “dialer” - if I were a more
> suspicious person…), but they do when they work for the government.
>

Yes and that's scary.  I think the distinction is acceptability of the
approach in environments like work, since your time is paid for.
Documenting this in two stages would be good as approaches to resolve may
be different.  The TLS 1.3 work to use pre-shared keys negotiated via DNS
should certainly help on this angle.  Enterprises may choose to block
access to some sites, where other options might be used by governments or
others trying to MiTM traffic.

>
> Ideally a solution would reveal the presence of a MITM to both client and
> server.

That would be good.

> All solutions discussed thus far can reveal things to the client, but do
> nothing for the server. I would like to have servers such as financial
> institutions and medical services be able to enforce a policy where they
> don’t provide a service through a middlebox. Doing it now requires
> installing their own client on the user’s machine, which seems to be a
> trend in mobile, but is not something we should require.
>
> Yoav

Thanks,
Katheen

-- 

Best regards,
Kathleen

---

From: Natasha Rooney <[email-masked]>
Date: Tue, 23 Jun 2015 12:32:23 +0000

Hi all!

Thanks for the comments on this. I rewrote some items given some feedback I received (Joe: I am worried that I didn’t expand on your points enough, please let me know if I should add something!):

2.3.X Content Filtering
Service Providers may, from time to time, be requested by law agencies to block access to particular sites such as online betting and gambling, sites promoting anorexia, or access to dating sites.*1 Content Filtering can also happen at the endpoints.

Content filtering in the mobile network usually occurs in the core network. A proxy is installed which analyses the transport metadata of the content users are viewing and either filters content based on a blacklist of sites or based on the user’s pre-defined profile (e.g. for age sensitive content). Although filtering can be done by many methods one common method occurs when a DNS lookup reveals a URL which appears on a government or recognised block-list. The subsequent requests to that domain will be re-routed to a proxy which checks whether the full url matches a blocked url on the list, and will return a 404 if a match is found. All other requests should complete.

Even in encrypted connections transport and lower layer metadata is able to be viewed so for many systems content filtering should be able to continue. Cases when they may not work is when TLS proxies are being used which obscure metadata with the proxy metadata, and future versions in HTTP and TCP may encrypt metadata again stopping content filtering software from working (this is currently not the case and has not been standardised). *2

I wanted to add two more sentences, but an IETFer gave me some advice today to say that I should only state facts, and not any leading or presumptive items, in such a submission. In which case I removed these two sentences, but you may find it benefit to include them:

  *   "Some mobile operators utilising licenced spectrum must adhere to regulations set by the government licensor, which include content filtering, or risk fines/licence suspension" at *1
  *   "Regulators that impose these censorship rules may look for other means if current methods stop working." at *2.

Also, I am happy in knowing that IETF won’t work on mitigating any sort of censorship, just that this exists as a reference. I also liked the idea of returning information to the user about what is happening so they can make decisions about their browser, provider, or who they’re voting for! Comments always welcome - thanks for the responses so far!

Natasha

On Jun 23, 2015, at 11:48 AM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jun 23, 2015 at 5:20 AM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:

> On Jun 23, 2015, at 11:59 AM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
>

Sure, I'm aware the same technique is sometimes used for both scenarios, but not always.  It's easy for a company with an agreement to set up a proxy that has 2 TLS sessions, one between the user and proxy and the other from the proxy to the destination site.  Other techniques have been used (see UTA's TLS attack RFC - 7457) at the service provider level, including stopping the STARTTLS negotiation.

Some have used techniques that are less visible to the user.  As problems are fixed in the protocol, what is done shifts of course.

I'm sure this varies between regions.  I just think enterprises can be more deliberate about it with user agreements and not worry about error messages.  Sure, the sam thing can be done in a pre-installed way, but a user can check the certs if they know enough.

Yes and that's scary.  I think the distinction is acceptability of the approach in environments like work, since your time is paid for.  Documenting this in two stages would be good as approaches to resolve may be different.  The TLS 1.3 work to use pre-shared keys negotiated via DNS should certainly help on this angle.  Enterprises may choose to block access to some sites, where other options might be used by governments or others trying to MiTM traffic.

Ideally a solution would reveal the presence of a MITM to both client and server.

That would be good.
All solutions discussed thus far can reveal things to the client, but do nothing for the server. I would like to have servers such as financial institutions and medical services be able to enforce a policy where they don’t provide a service through a middlebox. Doing it now requires installing their own client on the user’s machine, which seems to be a trend in mobile, but is not something we should require.

Yoav

Thanks,
Katheen

--

Best regards,
Kathleen

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Jun 2015 14:47:30 -0400

Nico,

> MITMing the user when the user is NOT using the operator's network?)).
I didn't say that there were god/easy solutions here. I just noted
that, from an engineering (not regulatory) perspective, there were
legitimate concerns that should be noted.
> but the IETF consensus can always change)?
Not all "operators" have the ability to impose such constraints. In
my work environment the parent company is very much a Windows shop.
But, they have been persuaded that forcing Mac users to adopt their
preferred OS is not a viable solution (i.e., valuable personnel would
likely depart).

Steve

---

From: Nico Williams <[email-masked]>
Date: Tue, 23 Jun 2015 14:16:12 -0500

> legitimate concerns that should be noted.

OK.

> preferred OS is not a viable solution (i.e., valuable personnel would

The differences between a commercial network operator and a corporate
network are mostly about scale and policies to be enforced.  A corporate
network typically has stringent policies about exfiltration of data that
a commercial network operator does not.  But ignoring those differences,
you're right that there are great similarities.  As I said, hierarchical
PK authentication schemes permit MITMing by authorized entities, which
makes me wonder: what else is desired?

I can think of some things, such as lighter-weight key exchange and
authentication [of authorized proxies to clients], and perhaps making
authorized MITMs work with channel binding.  But I've asked and no one
mentioned any such things.  Also, using PKIX has some benefits, such as
allowing a proxy to present as close to the real thing to user agents as
possible, with only subject public keys and issuers being different
(this allows user agents to correctly diagnose issues such as expired
certs).

Options for your corporate network:

 - Give the personnel company-owned Macs with the companies trust
   anchors.

   The empolyees will have to carry these in addition to any personal
   devices, and they'll complain, but look, these options are quickly
   become de rigeur, so if they want to decamp for less secure pastures,
   *let them*.

 - Make the personnel use RDP-type remote access solutions and stop
   caring what they use as a client.

   Conversely, don't let them use personal devices on corporate
   networks.  Provide a corporate wifi for guests and employee devices
   where you won't MITM but might still filter and/or log sites visited
   and so on.  Employees can bring their own network where available
   (e.g., LTE); they'll probably be paying for that regardless.

 - Make the personnel use SSH/mosh jumpservers, with keystroke and
   screen logging, and output rate limits (to slow down exfiltration).

This is fairly standard fare, but also mostly outside the scope of what
IETF participants are likely to care to standardize.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Jun 2015 15:32:05 -0400

Responding to various parts of the thread:

Q: What is the difference between filtering and censorship?
A: The person who decides to impose it.

Filtering is actually an essential tool for use of the modern Internet.
Without filtering there is no mechanism to control abuse.

Today I received five junk calls. The time is rapidly approaching when I
get rid of the telephone line completely. There is simply too much spam.

The fact that the Russian Business Network has put a machine on the net
does not mean that any machine I own need be able to connect to it. I don't
want their IP address to be reachable, I don't want their DNS names to
resolve.

So the ability to perform filtering is an essential part of every
end-to-end encryption mechanism. But giving control over that filtering to
the government is not. When I was at university there was a club for thugs
who went round smashing up restaurants for fun. One of the members of that
club is now the UK Prime Minister. I am damned if I am going to let the
likes of him decide what anyone can access.

The question is who has control and who is empowered.

I am firmly of the opinion that ubiquitous end-to-end encryption is only
viable if it is accompanied by a robust and easy to use mechanism that
allows for a gap in the stack. If I publish a key for [email-masked]
it will be the key of a service in the cloud that performs anti-malware
filtering. Use of the end-to-end key will be reserved to people who are
expressly authorized to use it.

---

From: Tom Ritter <[email-masked]>
Date: Tue, 23 Jun 2015 17:08:38 -0700

On 23 June 2015 at 01:47, Natasha Rooney <[email-masked]> wrote:
> Thanks guys for this - and sorry for the on-list tech check: but, isn’t SNI
> configured by the content server. So, if I have run https://evil.com, can’t
> I just, not use SNI?

No.  While you can indeed disable SNI on your server, that will make
no difference if clients send your name in the SNI.  What you need to
do to protect against filtering is configure clients to not send SNI.
Which would never be done (because the connection would fail) unless
the client knows the connection to the server in question will succeed
without it.

-tom