[dns-privacy] ADoT requirements for authentication?

Paul Hoffman <paul.hoffman@icann.org> Tue, 29 October 2019 14:49 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 ACE3012006A for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 07:49:49 -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 EERzwBEkF4hc for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 07:49:48 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.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 F2DD312001E for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 07:49:47 -0700 (PDT)
Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa3.lax.icann.org (8.16.0.27/8.16.0.27) with ESMTPS id x9TEnloI017691 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 14:49:47 GMT
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 Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 29 Oct 2019 07:49:45 -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 07:49:45 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: ADoT requirements for authentication?
Thread-Index: AQHVjmga3hOFgpcEaUaTnLbqPKqzSA==
Date: Tue, 29 Oct 2019 14:49:44 +0000
Message-ID: <5fe86408-35a8-16ea-d22a-9c6c4a681057@icann.org>
References: <943e3973-f6a7-9f6e-a66a-33aff835bd5e@innovationslab.net> <503df6fb-b653-476f-055f-15c1a668ba36@innovationslab.net>
In-Reply-To: <503df6fb-b653-476f-055f-15c1a668ba36@innovationslab.net>
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: <651BF2BBA0454545ABAC15EEC0E53ADF@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_04:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/8YjnBJlqFSjcCxBfKt293Ih9kOQ>
Subject: [dns-privacy] 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 14:49:50 -0000

Greetings again. I was surprised, but happy, to not see a requirement in the list for authentication of servers in the list. However, I suspect that this might have been an oversight, and the endless debate on authentication requirements will start as soon as there is a proposed protocol document.

My preference would be that the core requirement is that ADoT servers use either IP address or DNS name authentication in their certificates, but that the certificates can be issued by any CA, including being self-issued. The core requirement could also go on to say that resolvers be able to authenticate servers for logging purposes, but not be required to break TLS connections if the server's identity cannot be authenticated against the resolver's set of trust anchors.

--Paul Hoffman