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