Re: [Add] Browser Administrative Authority

Tom Ritter <tom@ritter.vg> Fri, 24 May 2019 15:55 UTC

Return-Path: <tom@ritter.vg>
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 58CBA1202FA for <add@ietfa.amsl.com>; Fri, 24 May 2019 08:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg
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 Xx-TAJJ9AUqL for <add@ietfa.amsl.com>; Fri, 24 May 2019 08:55:37 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3847512008A for <add@ietf.org>; Fri, 24 May 2019 08:55:37 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id i3so9893669wml.4 for <add@ietf.org>; Fri, 24 May 2019 08:55:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=trM07rTnZ88U7h+FTB5uU6bhe6BWR6dOqOPXeagFvmc=; b=hPnkc78tePgoaPz9J/jasYsvPzR63m3+cm+oh9xLxrX+bEHXDwP2HAer5YTPzpahKn xkenEOAaAww5vm6nphYQPyE+gPMo4THKdeoEjeC9Ao4vYlpCIUb0ritFj2KUQSkgPFD3 HbZZdCG/R9WGhfycsvHIFeynIZrxXLiaL+N2Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=trM07rTnZ88U7h+FTB5uU6bhe6BWR6dOqOPXeagFvmc=; b=qHR6Q9EwS99TH9lyQT75YYVGeImFZzwk37Oifh7WwSdGVHdKe0td3EQ4yGxQ0Rf80w hWKyI5dQ2KNjRb4lWiRuOExZEHcphhok7eOsqo7hhu4fwUt/Usv6FzTT8F9TlkPOBIda Hrs1NCF9kA30rpSEN2uvm5QvQdyGEfUwDrcoO/HbRyv/VqCk2MwzckcmakV1vhtKuX5F tTFiX7KW5AzXgXzyRtzb726K1VZPXti2RRGrHo6oi4MlUbFMP5oSRDKLM0bunosL09gw 2jWKAOdP1KM3xRxj72/oTVOob4hLtQW1kB+WJ6du2QKcKur+wUsThJniSqDMhmEJWERP olcQ==
X-Gm-Message-State: APjAAAVxyqBpxwxqX4Ge0YP0HiDgehIeS4BxpCQU8iy64q4tjtiRh3Gr ZSf8x1A2Ns3Q3udPZYIjPvmDvqQZ+8A7nK1c26N+Tg==
X-Google-Smtp-Source: APXvYqwPMVkfqrbbDhDzX23fVHHZtidzDx29wuoQfSup28lzcy+CfqIiA5sv1NMxoh09rvptnSQBFDfTgzcHaPm5yFI=
X-Received: by 2002:a1c:2109:: with SMTP id h9mr16835601wmh.68.1558713335300; Fri, 24 May 2019 08:55:35 -0700 (PDT)
MIME-Version: 1.0
References: <182C9119-59F9-43FA-B116-4D45649B74B5@nbcuni.com>
In-Reply-To: <182C9119-59F9-43FA-B116-4D45649B74B5@nbcuni.com>
From: Tom Ritter <tom@ritter.vg>
Date: Fri, 24 May 2019 10:55:23 -0500
Message-ID: <CA+cU71nddStL11ZXDqRn_3aqDw6my3A5p1SU82yuT2JK7qDFLA@mail.gmail.com>
To: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
Cc: add@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a85d250589a43a98"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/LQUSfe49tj0VbMoF1P4QyUuj4Yk>
Subject: Re: [Add] 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 15:55:40 -0000

What about the device administrator configuring the browser the way they
want it to behave? As far as I know administratively configured browsers
cannot be overridden by a local user.

-tom

On Fri, May 24, 2019, 9:49 AM Deen, Glenn (NBCUniversal) <
Glenn.Deen@nbcuni.com> wrote:

> HI everyone,
>
>
>
> I’ve been thinking though some of the issues with the proposal DoH
> deployment in browsers.
>
>
>
> A big part of the tug of war here is  the authority precedence for
> advanced security and network settings that should be followed.
>
>
>
> Historically, it’s been at the device level – which meant the device
> administrator, which could choose delegate choices to a specific DNS
> resolver operator, or to the Network DHCP provided settings.
>
>
>
> Now the browser is seeking to adding itself into the authority chain for
> those settings. The trouble being that this is a major change to the
> administrative trust model.
>
>
>
> To date, browser settings have been limited to rendering options, some
> basic certificate options, addons, and scripting language choices.
>    Advance security and trust has remained with the device administrator.
>     Adding the browser to the administrative chain so that it can control
> advanced security and network settings introduces a problem because the
> browser does not have an administrative level authority that is as high as
> the device administrator.
>
>
>
> Current hierarchy (top has more authority)
>
>
>
>               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
>
>
>
>
>
> The problem is that some of the browser makers proposals are now changing
> this administrative authority hierarchy, but they haven’t done the extra
> work of establishing administrative trust and working through the
> consequences of that such as a child being able to change the browser DNS
> settings and bypass both resolver, Network, and even OS based restrictions.
>
>
>
> So they are changing it to:
>
>
>
>               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
>
>
>
>
>
>
>
> The path to fixing this maybe to see if there is a way to express the
> administrative hierarchy that respects the intentions of the device
> administrator on what hierarchy they want to accept/delegate decisions to.
>
>
>
> It maybe that what’s needed is a means to communicate to the browser what
> authority the device administrator wants it to follow, since in the end the
> device owner should be in charge.
>
>
>
>
>
> -glenn
>
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>