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
- [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] DPRIVE Interim: 10/29 Allison Mankin
- Re: [dns-privacy] DPRIVE Interim: 10/29 tjw ietf
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Paul Hoffman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Livingood, Jason
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Alexander Mayrhofer
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Dickson
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Rob Sayre
- Re: [dns-privacy] DPRIVE Interim: 10/29 Eric Vyncke (evyncke)
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Paul Hoffman
- [dns-privacy] ADoT requirements for authenticatio… Paul Hoffman
- Re: [dns-privacy] ADoT requirements for authentic… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Hoffman
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Wouters
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Christian Huitema
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- [dns-privacy] DoT at the DNS root Jim Reid
- Re: [dns-privacy] DoT at the DNS root Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Watson Ladd
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Alexander Mayrhofer
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ralf Weber
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Wouters
- Re: [dns-privacy] ADoT requirements for authentic… Tony Finch
- Re: [dns-privacy] [EXTERNAL] Re: [Ext] Re: DPRIVE… Livingood, Jason
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Livingood, Jason
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Livingood, Jason
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- [dns-privacy] ADoT deployment at the root Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] ADoT deployment at the root Ted Hardie
- Re: [dns-privacy] ADoT deployment at the root Warren Kumari
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] ADoT deployment at the root John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Stephen Farrell
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Hollenbeck, Scott
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman