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

Paul Hoffman <paul.hoffman@icann.org> Tue, 29 October 2019 15:26 UTC

Return-Path: <paul.hoffman@icann.org>
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 C8E50120872 for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 08:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 tng3QAo050Nj for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 08:26:53 -0700 (PDT)
Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (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 1C797120827 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 08:26:53 -0700 (PDT)
Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa5.dc.icann.org (8.16.0.27/8.16.0.27) with ESMTPS id x9TFQpVe018886 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 15:26:51 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 29 Oct 2019 08:26:49 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.000; Tue, 29 Oct 2019 08:26:48 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [Ext] Re: [dns-privacy] ADoT requirements for authentication?
Thread-Index: AQHVjmga3hOFgpcEaUaTnLbqPKqzSKdyLFsAgAAGvAA=
Date: Tue, 29 Oct 2019 15:26:48 +0000
Message-ID: <edf53c16-3be9-786c-dcb1-0edc9fd9711c@icann.org>
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>
In-Reply-To: <CA+9kkMBZUPfWov6B+pgLYuFmZh10dTzwF2PdKs5Vozzssqvzjw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.2.0
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: text/plain; charset="utf-8"
Content-ID: <BC086679A6EAE240826F6E8C0B59982E@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-29_05:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/8VNVmg80rsazMQX3Rr-7FJ80NXk>
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 15:26:55 -0000

On 10/29/19 8:02 AM, Ted Hardie wrote:
> To be sure I understand you correctly, in the second case, the connection would be made to some IP address (e.g. NASA's 198.116.4.181).  The recursive resolver logs the details of the certificate, but it continues with the connection even if the CA NASA uses for the certificate is not known to the resolver?  What does it do in the face of other certificate errors like expired certificates or certificates presenting a different name?

It continues. This is exactly how opportunistic encryption is defined.
  
> 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?

--Paul Hoffman