Re: [Add] [EXTERNAL] Re: draft-grover-add-policy-detection-00

Hi Ted,

> But, and this is the crux of the matter, that integration requires the cooperation of the endpoint or its control by an organization's system administrators.  If you do not have their cooperation or the right to manage them by tools like those Eric mentions, it is difficult for the endpoint to distinguish a network-level interception by a mandated policy engine and by an attacker.  
> 
> Rather than falling back to the state where the endpoint simple accepts that its traffic is visible to all and possibly intercepted, this new work is an effort to make it easier for you to gain the cooperation required.  I hope you can see that this is in both the interest of policy enforcement bodies and the end users.

So I use DNS filtering in my own house (along with millions of other people as already stated on this thread), provided by my network operator (but it doesn’t have to be - I used to use OpenDNS for example, and I have the capability to run my own resolver if I so desired). I have malware filtering as well as parental controls enabled. I am the de-facto network administrator in my house,  but I don’t have the tools or software that enterprises use so I won’t benefit from the work being done to help enterprises control this. I also have other people coming into my house and using my network, and I also like to control what they can access when they are in my home. All of this works very well for me today. It doesn’t work for me when applications/endpoints start deciding that my network is an attacker because it does filtering, and bypassing that filtering "in the interest of end-users".

> I hope you can see that this is in both the interest of policy enforcement bodies and the end users.

I’d like to ask, ask an end-user, how is this in my interests?

Neil

> On 17 Jul 2019, at 16:25, Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> Hi Vittorio,
> 
> On Wed, Jul 17, 2019 at 1:06 AM Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org <mailto:40open-xchange.com@dmarc.ietf.org>> wrote:
> 
>> Il 17 luglio 2019 07:01 Rob Sayre <sayrer@gmail.com <mailto:sayrer@gmail.com>> ha scritto:
>> 
>> 
>> On Tue, Jul 16, 2019 at 12:30 PM Jim Reid < jim@rfc1035.com <mailto:jim@rfc1035.com>> wrote: 
>> 
>> Whether or not these tools/services work well is another issue entirely. And IMO not something to discuss at the IETF. 
>> 
>> Hi Jim, 
>> 
>> I thought about this email a lot today. 
>> 
>> I think the problem with its sentiment is that whether or not tools/services work on the Internet might be fairly called "engineering", and this is the Internet Engineering Task Force, right?
> But if you have tools that work well enough that millions of people rely on them and that they are encouraged or even mandated in many countries, and you decide to develop and implement technologies to prevent them from working
> 
> The IETF builds building blocks that meet specific needs.  In building DNS over TLS, DNS over DTLS, and DNS over HTTPS, it was adding the protocol functionality to make DNS queries confidential from inspection by network observers.  The energy for that work was the reaction to pervasive surveillance, but it is clear that other attackers had been gathering data for some time.  The IETF was not building these protocols to stop the use of the DNS as a policy enforcement mechanism and it is entirely possible to integrate them into a system which does this by offering the policy enforcing resolver over one of these confidential protocols.  
> 
> But, and this is the crux of the matter, that integration requires the cooperation of the endpoint or its control by an organization's system administrators.  If you do not have their cooperation or the right to manage them by tools like those Eric mentions, it is difficult for the endpoint to distinguish a network-level interception by a mandated policy engine and by an attacker.  
> 
> Rather than falling back to the state where the endpoint simple accepts that its traffic is visible to all and possibly intercepted, this new work is an effort to make it easier for you to gain the cooperation required.  I hope you can see that this is in both the interest of policy enforcement bodies and the end users.
> 
> best regards,
> 
> Ted
> 
> 
> -- 
> Add mailing list
> Add@ietf.org <mailto:Add@ietf.org>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

Neil Cook
neil.cook@open-xchange.com

-------------------------------------------------------------------------------------
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin 
Chairman of the Board: Richard Seibt

European Office: 
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 
Managing Director: Frank Hoberg

US Office: 
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA 
-------------------------------------------------------------------------------------