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

Paul Ebersman <list-add@dragon.net> Tue, 16 July 2019 19:02 UTC

Return-Path: <list-add@dragon.net>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6D9120CFD for <add@ietfa.amsl.com>; Tue, 16 Jul 2019 12:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14lYzytjX0bE for <add@ietfa.amsl.com>; Tue, 16 Jul 2019 12:02:19 -0700 (PDT)
Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0D9120778 for <add@ietf.org>; Tue, 16 Jul 2019 12:02:19 -0700 (PDT)
Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 89519374009B; Tue, 16 Jul 2019 12:02:19 -0700 (PDT)
Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 5DEF4156CDF0; Tue, 16 Jul 2019 13:02:19 -0600 (MDT)
Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 5CB36156CDEF; Tue, 16 Jul 2019 13:02:19 -0600 (MDT)
From: Paul Ebersman <list-add@dragon.net>
To: Rob Sayre <sayrer@gmail.com>
cc: Eric Rescorla <ekr@rtfm.com>, add@ietf.org, "Dixon, Hugh" <Hugh.Dixon@sky.uk>, Alec Muffett <alec.muffett@gmail.com>
In-reply-to: <CAChr6Sxm__NroZ92v4HL_6iCa62fwYgNw9r8ZDAxCdzVwNoDGw@mail.gmail.com>
References: <CAChr6SwEUz9MrdRA0bnv9f-oNi0oUHkfRKjd9-o6jwhuckLXdw@mail.gmail.com> <CAFWeb9LNdT=EYVKTsYDxcBCQKoQFNShKotYtWujt4U9GA-V1mg@mail.gmail.com> <CAFWeb9+eWKSKY9O2JLn9-0+Zq7hrD48F-y+Y4T-iRaaF0vtdOA@mail.gmail.com> <A45F4F74-D6C1-435A-A52F-C2DEA82E2999@sky.uk> <CAFWeb9JVBj+Yehup5q4v9X-7XDY+02frd-04AQGL2HoSLON2qA@mail.gmail.com> <CABcZeBMY9q9vKGse1svzbvXF_dSHA+9q06j4ugDVCZP9VT1koQ@mail.gmail.com> <CAChr6Sz5Rfz=UxOYuPguSvVK2HCX2ZoA1-FytW7+EOUxN8y46Q@mail.gmail.com> <CABcZeBNB7ASu2U3ZMBZ+OOxEhbSnhDXwFN3Lsex1uzVSDv3R=Q@mail.gmail.com> <CAChr6SwEwRRX7BA6ZCeBuC93hFxbfi3d7G_3G3VA7Lm09yuneg@mail.gmail.com> <CABcZeBNa97Vb6Fw-fMhoZnMezGtm3nJODENN4=XXsz7GWxf2Cg@mail.gmail.com> <CAChr6Sxm__NroZ92v4HL_6iCa62fwYgNw9r8ZDAxCdzVwNoDGw@mail.gmail.com>
Comments: In-reply-to Rob Sayre <sayrer@gmail.com> message dated "Tue, 16 Jul 2019 11:49:35 -0700."
X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <45414.1563303739.1@fafnir.local>
Date: Tue, 16 Jul 2019 13:02:19 -0600
Message-Id: <20190716190219.5DEF4156CDF0@fafnir.remote.dragon.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/tZBc4zPD3odEN-To74GTW7sZQRc>
Subject: Re: [Add] [EXTERNAL] Re: draft-grover-add-policy-detection-00
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2019 19:02:26 -0000

sayrer> I think the conflict is that the BCP states that the perceived
sayrer> benevolence of an application (parental controls, malware
sayrer> blockers, etc) doesn't matter, but that seems to be the case
sayrer> being made here.

The point is that the perceived benevolence doesn't matter if there was
no user choice. The use case of parental blocking or enterprise security
policies is made with user choice and cooperation so this BCP isn't
relevant to those use cases.

sayrer> Aside from that seemingly obvious conflict, it doesn't seem like
sayrer> DNS-based solutions would really work very well for these
sayrer> benevolent applications. It's sort of like using a coffee cup as
sayrer> an umbrella--it will catch some rain, yes.

Please stop saying this. Your own personal dissatisfaction is at odds
with literally millions of homes using these parental blocks via DNS and
most of the fortune 500 and many other SMBs using DNS RPZ/firewall. Both
parental and enterprise use are long standing, effective and popular.

Let's move on, please.