[Doh] Authoritative DoT or DoH

"Henderson, Karl" <KHenderson@verisign.com> Thu, 14 March 2019 19:18 UTC

Return-Path: <KHenderson@verisign.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F44130DC0; Thu, 14 Mar 2019 12:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 CXoDs1hZqTCD; Thu, 14 Mar 2019 12:18:16 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 9452B12DF72; Thu, 14 Mar 2019 12:18:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=7001; q=dns/txt; s=VRSN; t=1552591095; h=from:to:subject:date:message-id:mime-version; bh=POeX1bcpfsfWFVsO//z7n3Jxv0XQGDaA0N6w9/EPvVg=; b=BLwZfjGul19JKNqg2fsMPqLjvQS9unjrbJltcxKP+u2xsPvJC6NOwnDn hc+RxLe+/zI/Tz7QR457nKxXxtIi3quChpHAEj1oJ1ogYrvBgw8RRFo5s 2VPsomgN7LHSkSmkhPc5BV/dMxe944ooYtsw+KClSxhK3WJLlRfzNKseT Wit1bE+WJ0kZNVHyr2RAIcqhWah7YU3n7U6O7VJ+zzGeasmiG78k0HWOm 3MN/2AZLqt+0DMG0iI8rEww/5tuUUrmh5FcM+KaesSSPD5QiHYir80F6o 1tYDnp+kk7vA66tbp7vyf9xC0P25uwiw9ShSH8dYjsekC+n+qm+swNLpH w==;
X-IronPort-AV: E=Sophos;i="5.58,479,1544504400"; d="scan'208,217";a="7163827"
IronPort-PHdr: =?us-ascii?q?9a23=3AzRqJJRNoVON6cA3Ry/Ml6mtUPXoX/o7sNwtQ0K?= =?us-ascii?q?IMzox0I//5rarrMEGX3/hxlliBBdydt6sczbKP+4nbGkU4qa6bt34DdJEeHz?= =?us-ascii?q?Qksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPER?= =?us-ascii?q?vjKwV1Ov71GonPhMiryuy+4ZLebxhUiDanfb9+MQi9oBnMuMURnYZsMLs6xA?= =?us-ascii?q?HTontPdeRWxGdoKkyWkh3h+Mq+/4Nt/jpJtf45+MFOTav1f6IjTbxFFzsmKH?= =?us-ascii?q?w65NfqtRbYUwSC4GYXX3gMnRpJBwjF6wz6Xov0vyDnuOdxxDWWMMvrRr0yRD?= =?us-ascii?q?+s7bpkSAXwhSkHKTA37X3XhMJzgq1VoRKuuxNwzpXOb42JMfpzZL/RcMkYSG?= =?us-ascii?q?dHQ81fVzZBAoS5b4YXAeYPP/hXr4/gqFQQtxu+Hg6sBOX3xjRVg3H5x7c60+?= =?us-ascii?q?AvHQrb2wEuGtAAv2rSrNroKqgSS/u1zK7OzTjYcfNZxy396InTchAgrvGMW6?= =?us-ascii?q?h8ftbWyUkqDg7IiEibp4/9Pz6Ny+gBr3KX4/diWO+hkWIrtgF8rza1ysojjo?= =?us-ascii?q?TFnp8Zxkze+Slkwos5Oce0RFN0bNOnCpdcqiKXO5N4Qsw8QGxkpCM3x7gEtJ?= =?us-ascii?q?GnYCQF0pEqywPDZPObdoWF4g/sW/ifITp9gH9qZa+wiAi0/EO90OPzTNO030?= =?us-ascii?q?xPriddl9nMsW0C2ALL58icT/t94l+h2TGS1wDP8u1EIV47la7cK5M537M+io?= =?us-ascii?q?IdvVnDESHul0v5jbOaels+9ui29+vnZa/mpoeGO4Bulw7yKLoumtakAeQ+KA?= =?us-ascii?q?QBQ2+b+eGk2L3i+032XqlKg+UrnqXFqpzWOMYWq6CjDwNI0osu5QyzAjii3d?= =?us-ascii?q?gAmHkINlNFeBaJj4jzPFHOJej1A/K9jVuyljdk2u7JPqf6ApXKKHjOi6nhcq?= =?us-ascii?q?hn605d0wozzN9f55ROBr4dJ/LzX1f9tMbEAR8hLwy03+HnBc1g2YMYQmKDG7?= =?us-ascii?q?eZMLnTsV+W/O0gP+mNaZQUuDnjN/gl6eTijXgjmV8SZaOpx4cYaGikHvR6JE?= =?us-ascii?q?WUeWfjgtABEWoRvwoxUvDqiFOYXT5UfXayUPF02jZuQo6gFsLbXIGzibeQ9C?= =?us-ascii?q?a2ApMQYXpJQBjYHXHzMp2eWukFYzO6I8J9nHoDT7f3D8dr2RaunA7317QhKf?= =?us-ascii?q?DbsGVMuZXj/Nl4++OVkgs9o29aFcOYhiutQmd4k3kTQDlylIN2u0g3ggOg8a?= =?us-ascii?q?V+j/FCDttVz+1ESAYhNJHaied9DoahCUr6Yt6VRQP+EZ2dCjYrQ4dpzg=3D?= =?us-ascii?q?=3D?=
X-IPAS-Result: =?us-ascii?q?A2GOCACXqIpc/zGZrQpkH4F4gQ6BWRGBNIQBkxCGFZRWF?= =?us-ascii?q?IFnDAEThHKEXDQJDQEBAwEBAQgBAwIBAQKBEYI6IoMZaAFKAgQwJwQBJoMOA?= =?us-ascii?q?YERrjWBL4VGhG2BL4EKh1qEIT6BOB+HESaDIDGCJgOMUoQMHpNEAwYCi1WHY?= =?us-ascii?q?ZNMin+SaAIEAgQFAhWBR4IPcHoBgkKCFReOHpAagR8BAQ?=
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 14 Mar 2019 15:18:13 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1713.004; Thu, 14 Mar 2019 15:18:13 -0400
From: "Henderson, Karl" <KHenderson@verisign.com>
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "doh@ietf.org" <doh@ietf.org>
Thread-Topic: Authoritative DoT or DoH
Thread-Index: AQHU2pqrpJ4BZOcvCk2kB7Aw5+rcZw==
Date: Thu, 14 Mar 2019 19:18:13 +0000
Message-ID: <C8284F2D-F46A-484E-A145-99C0D8ADBC58@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.7.190210
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_C8284F2DF46A484EA14599C0D8ADBC58verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/7FVBckYW75mojFc36Od86NwxePA>
Subject: [Doh] Authoritative DoT or DoH
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 19:18:18 -0000

In the last couple of days there has been a lot of activity concerning DNS over HTTPS (DoH) - Hoffman and Alibaba presentations at ICANN and IETF drafts: draft-reid-doh-operator/draft-livingood-doh-implementation-risks-issues/draft-betola-bcp-doh-clients.

These discussions have focused on DoH for client (typically web browser) communication with recursive resolvers, and its comparisons with DoT for this purpose.

Is there any compelling reason at this point to be considering DoH for recursive resolver-to-authoritative name server communications?

As I noted at the DPRIVE interim meeting, the working group needs empirical studies looking at performance and attack vectors for authoritative DNS encryption.

Unless there are compelling reasons to consider Authoritative DoH, I propose the working group focus its authoritative DNS encryption assessments around Authoritative DoT.

In support, I am willing to co-author an Authoritative DoT operational consideration draft in order to outline the operational challenges the community needs to address - similar to the draft-reid-doh-operator draft between client and recursive.