Re: [Add] Browser Administrative Authority

"Cook, Neil" <neil.cook@open-xchange.com> Sat, 25 May 2019 08:39 UTC

Return-Path: <neil.cook@open-xchange.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 8E413120162 for <add@ietfa.amsl.com>; Sat, 25 May 2019 01:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
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 wPBxEoPBG4CB for <add@ietfa.amsl.com>; Sat, 25 May 2019 01:39:36 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 AA58712018F for <add@ietf.org>; Sat, 25 May 2019 01:39:35 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 303206A299; Sat, 25 May 2019 10:39:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1558773573; bh=jZ7UsS17SB7P6ofHqIALqdOwrK7id/KYI9p+q1VUPHg=; h=From:Subject:Date:References:To:In-Reply-To:Cc:From; b=CmD+pNcgM4nqbA8YzA6V7pjJi7X0BEqVD7Cx3coLakA1sxPC8FULyxu9GmRqo7lp5 0V4yzr8vjVYNSyHt6f5o4YeFK0V8QFBcHxeZATZ9jtBGRIeSd15Mxy7PgnFpiiG74w JAZ7/byI8YH79Jl0HkLAE10VmoaPrCoAeu10ln8iZi0XIYk/6pHu5zFBJkJbY5l+Sl EEhFwqgmujCGaM3JBxrP0osvTsB6/OUEQ8ysMdptJQ7kvLI3L9qb9QILC0GtDz93B7 Pl+kKT/uQsXWgLuib8MMSwVU7GyOfeObCqsijLTPFWV2gpW2nTlCkoqT2zrvMYKzzH vw29+OuPGhDbw==
Received: from appsuite-gw4.open-xchange.com (appsuite-gw4.open-xchange.com [10.20.28.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 23B4A3C0185; Sat, 25 May 2019 10:39:33 +0200 (CEST)
X-Header: Open-Xchange USM Mailer (USM Version: 7.10.2-2, EAS Version: 7.10.2-1, Build d17f7426766e7d3851e61d3f8794f10d65e74221)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: "Cook, Neil" <neil.cook@open-xchange.com>
Mime-Version: 1.0
Message-ID: <1210679252.1299.1558773573082@appsuite-gw4.open-xchange.com>
Date: Sat, 25 May 2019 09:39:32 +0100
References: <182C9119-59F9-43FA-B116-4D45649B74B5@nbcuni.com> <410f4e4d-aee0-d679-b454-6576de90b21a@nomountain.net>
To: Melinda Shore <melinda.shore@nomountain.net>
In-Reply-To: <410f4e4d-aee0-d679-b454-6576de90b21a@nomountain.net>
Cc: add@ietf.org
X-Mailer: Open-Xchange Mailer v7.10.2-Rev4
X-Originating-Client: USM-EAS
Autocrypt: addr=neil.cook@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFY4uCMBCACanbgJRs8WrxZZmtPZEe1xEEaVXz2g4rs6H898mQ2bsSa3NmeyfHrY/C7cy9iVpOE Al5GQBmKnTx0mYe0Fm8KZYBh895lpGz1OkV8z4N+7fvYpkeiYSUrwmdxGyWm4/Ol4rWieBXUqSpQl1a O9dRC9YUDx6wE2kvUcT35y9PpsYOgZvmzNZ61NsQNemLeVnWCk2dWvF8BC63vRPzKNnnS1KSj7yY12X FiVFqyuuWC4U0w8xgmkw1QEGXi9lEjnq5nh2LP3+MhSS0SQUg4K/NQEFXxoe4Yi9WghC37Yfl58EGxy JSGNHruwJuHTTWjC0xPN6tL/iEg2u8wy7blFSqAlABEBAAG0J0Nvb2ssIE5laWwgPG5laWwuY29va0B vcGVuLXhjaGFuZ2UuY29tPokBQAQTAQIAKgQLCQgHBhUIAgkKCwUWAgMBAAKeAQIbAwWJEswDAAUDAA AAAAWCVji4IwAKCRCqPocTiyIWJ8ifB/4r81q323KtGT/g3UpKXd+WIo5g6P5LRvaHcY0gWaT9RbRlg JfvbjXN2oY9HFE0PQBPpFozBvEVe9dtt0MROW5wWRygntyI5ROvEsD9I91xOIqcrEBpkCEFFeyqbq8+ +Yw5k8+IFIEFduopookBbmO3/gbMxkXFJ/cIh+OUWCIxV/kphlgJCGavwJq00Zo42SzMF42u5C63yHn kfT6zSQU0Y9z26FW/tyq6O1eI9aUAcaiMxLCAyR8pD+Dl8jaFPxbS7hyAk3srrA9dXvuL3mw4w6uEiW FUkuZ6onolSXQhZCUQ6+7y51f2XfbEH/gwWl8uDMc6IlunyZPZljvzEx9buQENBFY4uCMBCACbgNhut /V5nDmAh1sD1fyg1NBK8/NBuv24HhrdlEYuupU0ByS5Y4qhi+8ptu7d5vYNgGTbptZuob8Y4QEZS1BR EI7shZozYjsJjSzmHtnM+A+G0dSsXCaSKoTppsYL67sM1Cs5goZjsHnbIXDJi8SuvXtnTYxgxgGPLpU Rtci4LGKYksGEGy7q+hGvMA3KNSSZAu1OOwwLE71/E12VgXWWW7NuaJs67qLBtXcc3XiyEn2tCHdyTx yIl8ucMieNhkZt0jAkXgH+wAV71OyrjHBOWdsm+giHH70aLeZyz+x5D+FEOgh3inwYnIXASdwEDXT+2 lb+IbqjLhkYx7MoKfajABEBAAGJATEEGAECABsFAlY4uCMCGwwECwkIBwYVCAIJCgsFCRLMAwAACgkQ qj6HE4siFid2cQf9G6sstAGA9CBNOWujVe/8YEFYNOSut5upwIRe50/GcBhEoh6p6sMIesaGEwsvwyh V212cpXyi7pLO//jN+swOjVGazz68CRyFLAx8Z6Uyyp5kbj/tnlC5mqoa6KZL36VZTNF3ow0fEm5qNq VD59BxCpOei8r9mMeM4b7rji0lBJC3f6d5hZos9xmCx9Z6ynvWM8nD/bk6XMUKTUEuXr0ESMTkSIXUe O2RYsDHHyrkolWfrJ3npSFaZ4YI7/vSfsTVKgbcVqGZ7Oz3cGeR4vT+9V2MySL9dJr5TFmubPxCVzyw iFyqDh51hDl/oTgzn0OJ2A98hvdCWJODbATdQzExVQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/Hj9nfLPzRaVx_ZR8dqYj0srIZ14>
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: Sat, 25 May 2019 08:39:45 -0000

Melinda,

The specific example that’s been referred to is users (e.g. head of household) who have chosen to enable malware filtering and/or parental control on their broadband connection (this also applies to mobile or indeed other types of network).

This isn’t so much about what ISPs want, this is about what users want (and in the specific case of families, about what the responsible adult wants).

Suggesting that application manufacturers in this case are “closer to the user’s intentions” is clearly not true, in fact it is quite the opposite.

For devices that have a layered admin model, the admin for that device should surely take precedence over individual applications (this becomes trickier with devices like iPads and smartphones which only have a single user/admin).

Neil 

Sent from my iPhone

> On 25 May 2019, at 06:01, Melinda Shore <melinda.shore@nomountain.net> wrote:
> 
> To be honest I think the framing is perhaps not particularly
> correct.  Right now browser vendors are mediating trust, anyway,
> through their root programs and other security policy enforcement
> mechanisms that are not being explicitly chosen by the user or
> the ISP.  I'm really not sure what to make of
> 
>    "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"
> 
> given the current state of the web PKI.  (Allowing, of course,
> that the current state of the web PKI may be the strongest
> argument against allowing browser vendors to own trust for
> name resolution.)
> 
> I think the notion that they may be choosing a DNS resolver for web
> applications is not that much of a change from current practice.  I
> don't really love this but it's where we are at the moment.
> 
> I do, however, think that application authors understand their
> own security requirements better than ISPs do, and in that sense
> may be closer to the user's intentions than ISPs are (and indeed,
> user needs and ISP desires are often in conflict).  In the
> absence of some standard way of allowing applications to discover
> their security environment I'm pretty good (with reservations) with
> them choosing their own DNS resolver and DNS transport.
> 
> Melinda
> 
> -- 
> Melinda Shore
> melinda.shore@nomountain.net
> 
> Software longa, hardware brevis
> 
> -- 
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add