Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

Paul Wouters <paul@nohats.ca> Tue, 29 October 2019 17:10 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8B8120888 for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 10:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 BB4VK2H2TnVF for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 10:10:08 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 205B91208B8 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 10:10:08 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 472dPT5BShzG5d; Tue, 29 Oct 2019 18:10:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1572369005; bh=IUSBwV18DZqkA8zVR985RjxIvxYtjWamLaQ6g9HqPqQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hSssNqt1uMc7U3UvlMiY337hHEUAzcXWoMdh1s4KXKcds0bWdoT1htK+gamnQCT4O Q6DutXSEapnOY7q9bG9R1XBIuYJSZSIvJBxHR0PNpm8i2nsvLJDM8Ye0tKams3E+vc bhKKet4Ska6/xdLWjW1IdsRcCnQ3Dd6X5zrTkRxc=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id OSUohcGuFdFq; Tue, 29 Oct 2019 18:10:04 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 29 Oct 2019 18:10:04 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8C6F46007C4F; Tue, 29 Oct 2019 13:10:03 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8B41465F01; Tue, 29 Oct 2019 13:10:03 -0400 (EDT)
Date: Tue, 29 Oct 2019 13:10:03 -0400
From: Paul Wouters <paul@nohats.ca>
To: Paul Hoffman <paul.hoffman@icann.org>
cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
In-Reply-To: <edf53c16-3be9-786c-dcb1-0edc9fd9711c@icann.org>
Message-ID: <alpine.LRH.2.21.1910291236170.17764@bofh.nohats.ca>
References: <943e3973-f6a7-9f6e-a66a-33aff835bd5e@innovationslab.net> <503df6fb-b653-476f-055f-15c1a668ba36@innovationslab.net> <5fe86408-35a8-16ea-d22a-9c6c4a681057@icann.org> <CA+9kkMBZUPfWov6B+pgLYuFmZh10dTzwF2PdKs5Vozzssqvzjw@mail.gmail.com> <edf53c16-3be9-786c-dcb1-0edc9fd9711c@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/kgDYMEcpl3m3dTFHuzK8ADS4xqo>
Subject: Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2019 17:10:11 -0000

On Tue, 29 Oct 2019, Paul Hoffman wrote:

>> I have to say that I'm pretty surprised by the idea that TLS in this context should behave any differently than TLS in application layer contexts, and I'm a little concerned about having configuration options for this that amount to "ignore errors of types $FOO".
>
> TLS in application layers can specify that opportunistic encryption, yes?
>
>>   Accepting self-signed certificates is a known configuration, so I get that, but if someone has configured roots of trust, accepting other certificates outside the roots of trust in the configuration is pretty odd practice.
>
> Do you feel that there is a requirement that all recursive resolvers use the same set of trust anchors? If not, and if you are against the use of opportunistic encryption in this case, who will decide what set of trust anchors all resolvers in all jurisdictions will use?

Ideally, with TLSA records involved, DNS resolvers wouldn't need any
webpki based external CA trust anchors, and things would have valid
verification chains using DNSSEC. If you don't, then all the same issues
from mozilla and apple and windows having a different set of trusted
CA's will affect encrypted DNS between resolvers and auth servers. And
likely means a restricted artificial market with only a few accepted
CAs. Which is all irrespective of the Opportunisitc behaviour.

Paul