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

[Ted Hardie <[e-mail]>]

Hi Neil,

On Wed, Jul 17, 2019 at 8:38 AM Neil Cook <[e-mail]>
wrote:

> 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?
>
>
I am sorry if I was not clear,  The point of the draft is to enable the
network operator to signal this:

   If the user agent can check for the presence of a policy, this could be
   used as a signal that the network operator wishes its resolver to be
   used as a condition of using the network, and that DoH or DoT should
   be disabled.

That permits your guests to know of your network policy and to abide by it
if they choose; presumably you would not provide network access if they
chose not to.

regards,

Ted Hardie

Neil
>
> On 17 Jul 2019, at 16:25, Ted Hardie <[e-mail]> wrote:
>
> Hi Vittorio,
>
> On Wed, Jul 17, 2019 at 1:06 AM Vittorio Bertola <vittorio.bertola=
> [e-mail]> wrote:
>
>>
>> Il 17 luglio 2019 07:01 Rob Sayre <[e-mail]> ha scritto:
>>
>>
>> On Tue, Jul 16, 2019 at 12:30 PM Jim Reid < [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>
>
>
> Neil Cook
> [e-mail]
>
>
> -------------------------------------------------------------------------------------
> 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
>
> -------------------------------------------------------------------------------------
>
>