Re: [Add] [EXTERNAL] Re: Browser Administrative Authority

Paul Ebersman <list-add@dragon.net> Sat, 25 May 2019 19:26 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 40C531200FD for <add@ietfa.amsl.com>; Sat, 25 May 2019 12:26:09 -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 ES7l8smWJtol for <add@ietfa.amsl.com>; Sat, 25 May 2019 12:26:08 -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 32683120021 for <add@ietf.org>; Sat, 25 May 2019 12:26:08 -0700 (PDT)
Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 313B0374022A; Sat, 25 May 2019 12:26:07 -0700 (PDT)
Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id AEB7913B68F1; Sat, 25 May 2019 13:25:41 -0600 (MDT)
Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id AA2CF13B68F0; Sat, 25 May 2019 13:25:41 -0600 (MDT)
From: Paul Ebersman <list-add@dragon.net>
To: Melinda Shore <melinda.shore@nomountain.net>
cc: add@ietf.org
In-reply-to: <9ad7aa89-d751-e4c6-dede-e9c22faf6d20@nomountain.net>
References: <182C9119-59F9-43FA-B116-4D45649B74B5@nbcuni.com> <410f4e4d-aee0-d679-b454-6576de90b21a@nomountain.net> <76EF5603-618C-4A73-A4F9-7489B73B0757@nbcuni.com> <9ad7aa89-d751-e4c6-dede-e9c22faf6d20@nomountain.net>
Comments: In-reply-to Melinda Shore <melinda.shore@nomountain.net> message dated "Sat, 25 May 2019 11:17:07 -0800."
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: <9387.1558812341.1@fafnir.local>
Date: Sat, 25 May 2019 13:25:41 -0600
Message-Id: <20190525192541.AEB7913B68F1@fafnir.remote.dragon.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/ol4auO_hDRGrZ7KZGlp80jRF0m0>
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: Sat, 25 May 2019 19:26:09 -0000

melinda> I do think part of the problem here is that for whatever reason
melinda> our community (the IETF) hasn't come to consensus on problems
melinda> related to trust in the DNS.  If you don't have a trustworthy
melinda> name resolution system you can't trust much else, either.  This
melinda> relates to both being able to get a correct answer that hasn't
melinda> been mucked with by a third party, and to privacy protection of
melinda> queries and responses.  It seems unsurprising to me that
melinda> browsers (and other application vendors) would respond to the
melinda> default unprotected DNS situation by doing something about it
melinda> themselves.

If you are worried about full end to end data integrity, DoH/DoT isn't
it. It's a point to point encryption with no way to know if that
recursive you're talking to actually got valid DNS data.

DNSSEC solves that problem (end to end data integrity).

DoT/DoH solves the confidentiality (snooping the wire) problem but
that's all it solves.

If you want privacy and validated data, you need both.

But that's the technology piece. That still doesn't address user consent
vs network policy.

Let's not conflate several problems into one big hairball. Glenn laid
out some policy and consent issues. That seems something useful to at
least enumerate and define clearly so we at least know what problem
we're trying to chew on first.