Re: [Add] [EXTERNAL] Re: Browser Administrative Authority
"Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com> Fri, 24 May 2019 19:55 UTC
Return-Path: <Glenn.Deen@nbcuni.com>
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 1EB5B1200E9 for <add@ietfa.amsl.com>; Fri, 24 May 2019 12:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 T8XDbpi-SBIk for <add@ietfa.amsl.com>; Fri, 24 May 2019 12:55:53 -0700 (PDT)
Received: from mx0a-00176a04.pphosted.com (mx0b-00176a04.pphosted.com [67.231.157.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C0312008B for <add@ietf.org>; Fri, 24 May 2019 12:55:53 -0700 (PDT)
Received: from pps.filterd (m0048208.ppops.net [127.0.0.1]) by m0048208.ppops.net-00176a04. (8.16.0.27/8.16.0.27) with SMTP id x4OJmIct036774 for <add@ietf.org>; Fri, 24 May 2019 15:55:50 -0400
Received: from usaoamgip001.mail.tfayd.com ([173.213.212.135]) by m0048208.ppops.net-00176a04. with ESMTP id 2sjcq5tfq6-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT) for <add@ietf.org>; Fri, 24 May 2019 15:55:50 -0400
Received: from unknown (HELO potemwp00028.mail.tfayd.com) ([10.40.78.204]) by usaoamgip001.mail.tfayd.com with ESMTP; 24 May 2019 15:54:36 -0400
Received: from potemwp00030.mail.tfayd.com (100.124.56.54) by potemwp00001.mail.tfayd.com (100.124.56.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Fri, 24 May 2019 13:55:47 -0600
Received: from potemwp00029.mail.tfayd.com (100.124.56.53) by potemwp00030.mail.tfayd.com (100.124.56.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Fri, 24 May 2019 13:55:46 -0600
Received: from potemwp00029.mail.tfayd.com ([100.124.56.53]) by potemwp00029.mail.tfayd.com ([100.124.56.53]) with mapi id 15.01.0669.032; Fri, 24 May 2019 13:55:46 -0600
From: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
To: Tom Ritter <tom@ritter.vg>, Tommy Jensen <Jensen.Thomas=40microsoft.com@dmarc.ietf.org>
CC: "Cook, Neil" <neil.cook=40open-xchange.com@dmarc.ietf.org>, Adam Roach <adam@nostrum.com>, "add@ietf.org" <add@ietf.org>, "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
Thread-Topic: [EXTERNAL] Re: [Add] Browser Administrative Authority
Thread-Index: AQHVElduUVk23xOP3E+l0RWVAVU0xKZ7DDuA//+Tq4A=
Date: Fri, 24 May 2019 19:55:46 +0000
Message-ID: <03CDC9F1-4F00-449A-B07D-C77380D2F758@nbcuni.com>
References: <182C9119-59F9-43FA-B116-4D45649B74B5@nbcuni.com> <07A89E54-2DFC-4B5A-9784-610BBE7D2BB2@nostrum.com> <125917581.1152.1558717017241@appsuite-gw4.open-xchange.com> <MN2PR21MB1213868D0BC3575C2589B670FA020@MN2PR21MB1213.namprd21.prod.outlook.com> <CA+cU71mw77uS-BROWrFsGg9OSPEfAVk71UnzgL_5wWdM_znHnw@mail.gmail.com>
In-Reply-To: <CA+cU71mw77uS-BROWrFsGg9OSPEfAVk71UnzgL_5wWdM_znHnw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.19.0.190512
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [100.126.25.31]
x-exclaimer-md-config: 47edc00f-f2d6-45ef-be83-8a353bd47e45
Content-Type: text/plain; charset="utf-8"
Content-ID: <1CC16D32E3591A4B83CCD72BBA97B75E@NBCUNI.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-24_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905240129
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/ZdJfpUkJ99Qr5TQwYRaLm2txcWI>
Subject: Re: [Add] [EXTERNAL] Re: Browser Administrative Authority
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: Fri, 24 May 2019 19:55:56 -0000
On 5/24/19, 12:23 PM, "Tom Ritter" <tom@ritter.vg> wrote: "imagine a parent who configures content controls through their ISP" Okay; but then this isn't a device administrator. This is a network administrator. (And whether it's enterprise or not isn't really relevant, no feature is restricted to enterprise use.) The network should be considered hostile until configured otherwise because... the network usually is hostile. Or at least it's untrusted. Every cellular connection; every coffee shop, every store's free wifi, every friend's network you connect to, every AirBnB wireless, every hotel... Percentage-wise, the number of untrusted networks the average user connects to dwarfs the number of trusted networks (even if the percentage of time spent on untrusted networks is dwarfed by the percentage spent on trusted networks.) [GD] The reason why I put it as a hierarchy isn't to make any judgement on the network's hostility or trustworthiness. It's all about the device owner making the choice on if they accept, and thus are choosing to trust, settings from the network. [GD] in the case of "imagine a parent who configures content controls through their ISP", they parent is making a choice to accept the their ISP as trust worthy. It's not that the network is imposing that upon them, they are making the choice to accept and trust. [GD] Control Hierarchy Classic: Device Administrator -- device authority for security, network, trust settings Network Administrator -- provides recommend network settings to devices Resolver Administrator -- can provide filtering Browser Maker -- provides core trusted certificate list Browser User -- can set rendering options, can make limited certificate choices, plugins. – Impact is limited to the browser sandbox Control Hierarchy Being Proposed by Some: Browser Maker -- provides default DNS resolver and DNS Protocol choices. Browser User -- can set DNS resolver and DNS protocol Device Administrator -- device authority for security, network, trust settings Network Administrator -- provides recommend network settings to devices Resolver Administrator -- can provide filtering [/GD] On 5/24/19, 12:23 PM, "Tom Ritter" <tom@ritter.vg> wrote: Device administration is the appropriate answer here - it's the appropriate trust boundary for users. An administrator of a device is a person or organization the user of that device knows and understands controls it. For the network to be able to override and disable users' security and privacy controls is inappropriate - for example we don't allow networks to strip TLS. UNLESS, of course, the device is configured to allow such activity. [GD]. I don't hear anyone proposing that the network should be in the role of overriding or disabling a device's security or privacy controls. Likewise, neither should browsers be overriding or disabling the device's security or privacy controls.. It's the device Administrator that should have final authority in such things. The entire past 30+ years of OS and security architecture is built on that model. Yet, some of the public plans have proposed doing just that. [GD] The question is how to respect the hierarchy when introducing new protocols so as to avoid introducing undesired side effects Such as children being able to trivially bypass parental and school choices. [GD] This could also be solved by doing it at the device/OS layer instead of inside the browser, because then it would integrate with the device Administration hierarchy. Making DNS resolver and protocol choices in the application is a major change to the traditional role of DNS as an OS/device level choice. [GD] In the end , doing it in the browser creates 2 DNS behaviors: (1) One for the OS and apps; (2) another that's different in each browser that overrides the device. [GD] Perhaps DoH settings could be a device setting done at the OS level that the browsers could look to in order to understand the device administrators intent? This could even be a setting the device administrator can choose to inherit from a network, if again they choose to. -glenn
- Re: [Add] Browser Administrative Authority Tom Ritter
- [Add] Browser Administrative Authority Deen, Glenn (NBCUniversal)
- Re: [Add] Browser Administrative Authority Adam Roach
- Re: [Add] Browser Administrative Authority Cook, Neil
- Re: [Add] Browser Administrative Authority Tommy Jensen
- Re: [Add] Browser Administrative Authority Tom Ritter
- Re: [Add] Browser Administrative Authority Tommy Jensen
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Deen, Glenn (NBCUniversal)
- Re: [Add] Browser Administrative Authority Melinda Shore
- Re: [Add] Browser Administrative Authority Cook, Neil
- Re: [Add] Browser Administrative Authority Stephen Farrell
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Deen, Glenn (NBCUniversal)
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Stephen Farrell
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Deen, Glenn (NBCUniversal)
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Deen, Glenn (NBCUniversal)
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Melinda Shore
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Paul Ebersman
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Erik Kline
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Stephen Farrell
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Paul Wouters
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Paul Wouters
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Christian Huitema
- Re: [Add] Browser Administrative Authority Vittorio Bertola
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Vittorio Bertola
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… tirumal reddy
- [Add] publication of DoH Resolver policies Jim Reid
- Re: [Add] publication of DoH Resolver policies tirumal reddy
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Deen, Glenn (NBCUniversal)
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Paul Wouters
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Neil Cook
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… tirumal reddy
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Paul Wouters
- Re: [Add] publication of DoH Resolver policies Livingood, Jason
- Re: [Add] publication of DoH Resolver policies Winfield, Alister
- Re: [Add] publication of DoH Resolver policies Petr Špaček
- Re: [Add] publication of DoH Resolver policies tirumal reddy
- Re: [Add] publication of DoH Resolver policies tirumal reddy
- Re: [Add] [EXTERNAL] Re: publication of DoH Resol… Winfield, Alister
- Re: [Add] [EXTERNAL] Re: publication of DoH Resol… tirumal reddy
- Re: [Add] Browser Administrative Authority Livingood, Jason
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Livingood, Jason
- Re: [Add] [EXTERNAL] Re: Browser Administrative A… Livingood, Jason
- Re: [Add] [EXTERNAL] Re: publication of DoH Resol… tirumal reddy