Re: [dns-privacy] [EXTERNAL] Re: [Ext] Re: DPRIVE Interim: 10/29

"Livingood, Jason" <Jason_Livingood@comcast.com> Wed, 30 October 2019 18:10 UTC

Return-Path: <Jason_Livingood@comcast.com>
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 928EB12013C for <dns-privacy@ietfa.amsl.com>; Wed, 30 Oct 2019 11:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=0GWY0tuK; dkim=pass (2048-bit key) header.d=comcast.com header.b=5JzTeDGC; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=KAHM45dR
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 3tOc7HJry_Zy for <dns-privacy@ietfa.amsl.com>; Wed, 30 Oct 2019 11:10:17 -0700 (PDT)
Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (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 D4A2D120013 for <dns-privacy@ietf.org>; Wed, 30 Oct 2019 11:10:16 -0700 (PDT)
Received: from pps.filterd (m0184891.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9UI67LL021561 for <dns-privacy@ietf.org>; Wed, 30 Oct 2019 14:10:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=936Lte+tn2Ng4fO+Hrs5q/3wFk6Giv0H1TDjccrABXI=; b=0GWY0tuK1KUzH2YY3rpxU0C8PTqi6t16yVpEmlXWc4JJE8ZWV1Sv9fO+a0jfVOso/hq4 E3OadsA9ZhyzNq23vTmC6qJ2DieNIeJ+C8rpZsbBnAmfJ/DAduoW4W2JFO3A00JvVRF8 QGHyx33TJe5rF6cqnOHLnv7dwL8K98xOeEspG8FlZFxrHqT82b5me8tR3/UeGZE79E4L nfARAHbRgRkyr1BWFC0w6/WprCz9BcHbsHGiDES+ixnub2T1CocFqBk0A20A/AeKREj0 8U4ULkT4rfmc4HbuOYEgG2KOa2+/g2saUnV0AP3b19hezXdVEOtu+s3ghIVXjIiXCcGb aw==
Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0b-00143702.pphosted.com with ESMTP id 2vxwf2xt3q-65 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dns-privacy@ietf.org>; Wed, 30 Oct 2019 14:10:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1572459014; x=2436372614; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=936Lte+tn2Ng4fO+Hrs5q/3wFk6Giv0H1TDjccrABXI=; b=5JzTeDGCeeFzuTsw1wf4w5hlHpc40h0qTkMXH+u0ZPljqNzEoQxqxyoWvKi7sI2B TB+TIzG4tYzNjz/MJo1rMYyXy95LweyJqfa058kQTWShBCRJXhplU9vSJhkyKOgr FWFl/vFEk6ZrGq32v7ha3jlIMvn3V6WigGK/DZhTa59BzeXX6gbLDAx2z/uWvxSP jmuKlGQwrg7LKz1Bl+iRzy53Kp+43pdq15LMytxqZ6Z0vmzzLpfdLZ6/9bhTDQZb e4FyuOmngbGqcWQ9wVckpJr0P9XJT6q8fu9FiWRPKXWk7iZyEN0zObbp5KpGtX8y 8LyFzjMCss3ZqkzGKRgzpQ==;
X-AuditID: 60729ed4-065ff7000000a7f4-51-5db9d205cbfd
Received: from COPDCEX22.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 82.87.42996.502D9BD5; Wed, 30 Oct 2019 12:10:14 -0600 (MDT)
Received: from COPDCEXC41.cable.comcast.com (147.191.125.140) by COPDCEX22.cable.comcast.com (147.191.124.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 12:10:13 -0600
Received: from COPDCEXC42.cable.comcast.com (147.191.125.141) by copdcexc41.cable.comcast.com (147.191.125.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 30 Oct 2019 12:10:12 -0600
Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEXC42.cable.comcast.com (147.191.125.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Wed, 30 Oct 2019 12:10:12 -0600
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.52) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 14:10:17 -0400
Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB4322.namprd11.prod.outlook.com (10.255.89.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.24; Wed, 30 Oct 2019 18:09:54 +0000
Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a%7]) with mapi id 15.20.2387.025; Wed, 30 Oct 2019 18:09:54 +0000
From: "Livingood, Jason" <Jason_Livingood@comcast.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>, Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com>
CC: Brian Haberman <brian@innovationslab.net>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [EXTERNAL] Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29
Thread-Index: AQHVi0WfYqbHJiFemk+Ch448iK5zmKdrcuQAgARqJQCAATGMAIACMkaA
Date: Wed, 30 Oct 2019 18:09:53 +0000
Message-ID: <2FCF49E6-F46E-42EA-835E-E833C9A136BF@cable.comcast.com>
References: <943e3973-f6a7-9f6e-a66a-33aff835bd5e@innovationslab.net> <503df6fb-b653-476f-055f-15c1a668ba36@innovationslab.net> <29aabefd-e02b-56cd-e1bd-77d44071920a@icann.org> <9f7a71e0-ff3e-0199-9f4d-c931d752f54c@innovationslab.net> <88948CDC-288C-4EB1-8419-5525F0EA601D@cable.comcast.com> <CAHXf=0o0=FrEPf0AKeMvOY=Bjprhu7byxPGZfoh99i39YFTMyw@mail.gmail.com> <CAH1iCioxBQQQQBzgKxOb7ktE4TiRfGCbhinKiuMih1FsGzNf8w@mail.gmail.com>
In-Reply-To: <CAH1iCioxBQQQQBzgKxOb7ktE4TiRfGCbhinKiuMih1FsGzNf8w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
x-originating-ip: [2001:558:1438:aa::4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d54e7a0e-4950-4a2e-a2d7-08d75d645d56
x-ms-traffictypediagnostic: BY5PR11MB4322:
x-ms-exchange-purlcount: 8
x-microsoft-antispam-prvs: <BY5PR11MB4322C369EA7F0EA00FF2E437C7600@BY5PR11MB4322.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4941;
x-forefront-prvs: 02065A9E77
x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(39860400002)(346002)(376002)(136003)(366004)(396003)(199004)(189003)(486006)(6436002)(99286004)(46003)(81166006)(33656002)(8676002)(25786009)(8936002)(606006)(71190400001)(71200400001)(6486002)(81156014)(54896002)(229853002)(236005)(6512007)(316002)(966005)(11346002)(446003)(5660300002)(476003)(2616005)(6306002)(256004)(54906003)(14454004)(53546011)(6506007)(14444005)(58126008)(110136005)(186003)(102836004)(66476007)(66556008)(64756008)(66446008)(478600001)(66946007)(76176011)(7736002)(6246003)(76116006)(4326008)(91956017)(2906002)(6116002)(80792005)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB4322; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MyqmeceQ0AJnQuU/jgys8ypcvM4YgafnRbae8fnOBZG17TEjOeCBUDiLGKTX4LoYHtdoX9s604OWPDtKq0d58iG+7fSQYVSPWLAtiCHMALWlo4xefK8rtQyAIEUrSj7GvkTcupHAWghMk4g76nD59GQoJXkS1eA9JOP1hNkdelXjWoMTlkRy2deoCMMJGFD2lwa5BaPXWKgZs1XXLUmdGjxko7uq47HoORZK6JqNFi/kxaq90n8rn6sVRoD3bojMQCp99lPs4l8uqSjHqtPrtV1FHwVeHW0jIAHOgDOzyHRZcHMIPZGxwes8SUkXBGEPLJ52kb1J6je6ui/AEkH/gySZc2gF0HMu5rceRk0JNqmPz9LB+5t9TLJW544OdD8f+9AaVQ7nXySTJBnfzjvIH91mGkM9z2aXQBtTZOKhBSId68uV5idyKPl3aCGRRTb7TSTZWPO0e3wMvGsZK/9ar0tX5pXvo3nWVKYnhBKQY8hyTycAflXJBmItPOX24jV6rEo9PrqL5A4WJahD+hZ6tQ==
x-ms-exchange-transport-forked: True
arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b9/C2+NjFjJPfek634j4oe0kXzzWbiXIyY9JVJKzmMyldDJmYxCjbLkJO3OVFOz3aEvWW3TC6u7gd8okZQY40XQYoyfg1jevDNG3fwMNDzx9W49gZ8YNIdkJmbHaFDzCIpiDJdWN2LsSIzBWymv4ZzGQ9CkfgLLmDfnGAKVGBBLUSENB6Mlx9dEWHMr21nh/JClVpIjdFTMdBy59tvOVWwd3B257s1AnS0sxzwx48rzxWEJouJTnjI/yE3sZ5Riplaco9rJXH5IOdZ16leNbKgiUUzz7iEXF361DfqnIL9lNhNIqEIgp0D490uY1qk6a671s/3iaLRxYDXPxPHI4PQ==
arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e0XstSH8IijC2dF+FPYrPFJIDOjhpNyfAOH2TN7Lkx0=; b=Ls/xmWReyq5ZPnBv2eSuHfombanoLlka3Nk/bVc3ShjWoU+Vz2FUtKTTD8OkzWZNe5kAPNzKvlKn5ndOkG1Dr6FM8T4t095q2jZVYyXXFrKHe/w9nvMMBKDcDduvrjHP4EYezXpp4DAlHIJGS9knAQzlIPBNRz6hw2yd84WpiUVwoOs/3A38KBeFc4KHF3OLxC29UqJSvOI8XM8uv+3s73YbGToSIh92C0kWvdBYNt94m4DwaJZArOnvgWzX+VxWHVRs+ZRjtGudJVhu1gHwKQXAPPuQIqpiF4ASwX7dMtXW6WRNOyu1/FwkMOdvb8jLPQN0agzqp7FroAPd+pfpDA==
arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none
dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector2-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e0XstSH8IijC2dF+FPYrPFJIDOjhpNyfAOH2TN7Lkx0=; b=KAHM45dRqNwkAbnUJxjOXsn2kq8uzZVPjxwKTEZ7RXUIO/La05NdA9HBrBea02BA303cabRNMkHm9xm+qOgqOutefSLxHHgyNEBigiccM82KJdvvbtUcQWXgRdu/oTu4wc3XtZ+LbL0eOsqDJjpNnK6dfP4AVuXIxGobEMhGlq0=
x-ms-exchange-crosstenant-network-message-id: d54e7a0e-4950-4a2e-a2d7-08d75d645d56
x-ms-exchange-crosstenant-originalarrivaltime: 30 Oct 2019 18:09:53.7777 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa
x-ms-exchange-crosstenant-mailboxtype: HOSTED
x-ms-exchange-crosstenant-userprincipalname: 4cE7NXj1c8a7amUri574tZh+hvNmrpdSAsJgHGMwb0kNqmkz2rF4OByn2XoRiqkRcfc1WOmm50rxafeqKqdPrMIb2XiYCd+Z+r+Q8iY6BGE=
x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4322
Content-Type: multipart/alternative; boundary="_000_2FCF49E6F46E42EA835EE833C9A136BFcablecomcastcom_"
MIME-Version: 1.0
X-OriginatorOrg: cable.comcast.com
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA22SaUhUURSAue89Z57S2G1yOZiGDe2RNqIyokSY1rQIWWgQuTybq2NOKm/U tF8iauaYiUmhuFUWaUlhJo4Zlrm0CJJOYC6VZmabtmjSouSbN4KQ99d3zvnuOefCZWl5ncSJ jY1PInw8p1NIbJhIvvT8VkmPMWxbkZFR3e3NQKrsIVZVnDeHVLezGq12MGpjyZBUXVX1i1IX d04xB+gj6cgvScsTLimARJN4Pdlu4/rf8Ysi0Qk8CeR4XdpBoiPc0ppgaoguNoXw7ku2cV+y T6SJ0g7/eUcllp6jUpue9aN0ZMihcpE1C9gTOifa5tmGleNHFGScbqQtAYKuuU5LkElBzv12 i1ZGwVx5ryV4jGDsxqCV0EyOCymYGXAVCyMIOs4VmgsS7A1Dl0zzvVjWDmvh9UCykKZxOGQW 5ZuVlXgP1H18Tgtsh/dC99l6RuRd8PFvn5kZvA76Ox9IBZbhADC1C3lhlpGG67UPzZI1DoZP fX/NjLADzDy9SYnDHKF/tMLyagxVzd20yPbw4e2clbCbPXaHh7NB4lUNXMm9bNE3QMerbxZ2 gZ4KAxJ0wEGQ9clJxM2QN+EsGk5gOL1wMw6yXlQhkdfD1erbEpGdoS7/Dl2AvEsW7SZyDFyb NUlKzI9cAU+KR5mS+Qk03gS3mtxFZQ0UGYalIm+ErNIyC6thsvm8dLFTidgaZOvj7aZUerop vVRuHkqPOmT+yeWmRtR7Ud2KMIsUy2TJ3cYwuRWXok870YqApRV2sp9+8ymZhks7RfiECD5Z R/StaBXLKBxltrWVYXIcwyWROEISCb9QpVhrp3TkEhzqb0PJ92X83nJMdfJ4dEvDe83qkd37 hx+FGr0K9o6Xs6TgzXjx0Zf+HjuWf//8deqHYme+95ipejpCavAdGbwXkpqtlZy5dTgw4X5z dPqhq9NG2se+TRM3eOFLZn2Fa0SNVJLhENXAX9w1uZbzhT8ts/GDa1Z4aOO6BkK0IeEKRq/l lJtpXs/9Aw0qBvPFAwAA
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-30_08:2019-10-30,2019-10-30 signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/z7YuIlBOsVYX85GcFIjUPxL5KVo>
Subject: Re: [dns-privacy] [EXTERNAL] Re: [Ext] Re: DPRIVE Interim: 10/29
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: Wed, 30 Oct 2019 18:10:21 -0000

Great detailed feedback, thanks. Have flagged in https://github.com/alex-nicat/ietf-dprive-phase2-requirements/issues/11

From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tuesday, October 29, 2019 at 12:37 AM
To: Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com>
Cc: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>, Brian Haberman <brian@innovationslab.net>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29

Hi, everyone interested in ADoT,
I'm planning on being on the call, although given the early hour for me I can't be sure I'll be on my game as much as usual...

In the interests of getting all the ideas I have after reading the -00 draft, I thought I'd send them to the list, and maybe they can be discussed on the call, time permitting.

Simple notion up front: add an EDNS flag or OPT code to signal ADoT support (or a bit field of all the supported transport types) on a given IP (analogous to the RA flag), and possibly include the canonical name(s) of the server at that IP, if the query include EDNS. This limits downgrades to on-path adversaries who block port 853 and modify port 53 traffic. Maybe SIG(0) or TSIG can further prevent downgrades by on-path attackers who would modify UDP/TCP port 53?

Certificates for DoT and DoH should really be DANE/TLSA entries. We're literally talking DNS here, so it would be particularly shortsighted not to standardize on this. It also potentially decouples from any hard dependency on particular CA support matrix, notwithstanding that the authoritative server might be using a CA-issued certificate. Having the ability to validate without needing to unilaterally trust some particular set of CAs is a feature not a bug.

State exhaustion protection mechanism, optionally use TCP cookies during handshake, regardless of TLS or not. This limits the TCP impact of needing established connections to do the TLS stuff to legitimate TCP connections only. Servers can limit the number of connections doing TLS handshakes, and prioritize those. The, use of aggressive timers on those prioritized connections protects against deliberate DOS via "slow transaction" attacks. Handshake-complete connections can be resumed, so making them lower priority and having aggressive connection dropping on those has comparatively low impact (since session resumption is cheaper than redoing the handshake). Experimentation is needed to establish recommendations on all the appropriate values (timeouts, number of sessions to support in each state, etc.)

The rest of the ideas mostly relate to the question "when is using DoT really optional, vs strongly desirable?".

I have a few suggestions along that line, as well as a few additional observations.

First, there is a strong correlation between the first time any client queries a given name, the visibility of the corresponding R2A query (presuming no ADoT), and the subsequent client data traffic (even with HTTPS).
The R2A (recursive to authoritative) query is a strong indicator that the name isn't cached (and may never have been cached).
This correlation may not be that important per se, but identifying it as somewhat distinctive means there's a reason to potentially look at the implications of that (from the perspective of ADoT being "strongly desirable").

In contrast, very popular domain names (and qtypes) are likely to be heavily served from the cache. If cache refresh (what was once identified in the HAMMER draft) is done for popular cache entries, there would no longer be any identifiable query triggering the R2A lookup, and in particular no timing side channel for identifying even a single DNS client.

What I'm suggesting is, using ADoT predominantly (or even exclusively) for "cold cache" lookups, and doing "cache refresh" lookups without ADoT, is one way to minimize the TLS overhead, which incurs a cost on the authority server (mostly CPU) and a penalty on the recursive (mostly latency, and maybe some CPU). Refresh without TLS would have lower latency, IMHO.

IMHO, the same rationale for "cold cache" also applies to "ECS" (EDNS client subnet). First instance (of a particular ECS parameter value), use ADoT; refresh, ADoT is optional.

The other question (observation?) is that ADoT is a poor substitute for DNSSEC. I.e. unsigned zones might seem like attractive reasons to force DoT for transport, but doing so would basically amount to "security theater". It would also discourage, rather than encourage, use of DNSSEC validation. It would be justifiable for an authority operator to respond "REFUSED" for ADoT queries doing "refresh cache" queries on unsigned domains, at least during periods of heavy load. Or maybe some new error code or EDE to signal "retry on non-TLS connections".

It remains an open (and perhaps interesting) question of the relative overhead of DNSSEC validation when compared with TLS transport. It might be interesting to compare those based on crypto algorithms (for negotiated TLS connections, and for DNSSEC zones), and based on various TTL values.

Having validation of DNSSEC signed zones, on popular domains being refreshed without ADoT, would potentially be the "sweet spot" for security and privacy. Security, by having cryptographically signed zone data, and privacy by the aforementioned "cold cache" and "cache refresh" distinction.

This might be where the EDNS signaling available directly between the recursive and authoritative, would allow the authoritative server to make the informed decision to reply with UDP instead of over the ADoT connection, if/when it experiences significantly increased load. The recursive could always try to use ADoT, but get signal(s) from the authority server to limit ADoT to "cold cache" queries only in response to load problems.

Finally, I'd like to announce the following:
GoDaddy now has four ADoT servers in its OTE environment.
They are ns01/ns02, and pdns01/pdns02 in ote.domaincontrol.com<https://protect2.fireeye.com/url?k=dcb1e45753111730.dcb1c3e3-d1a47abc06098c89&u=http://ote.domaincontrol.com>, with domains dnsczar.com<https://protect2.fireeye.com/url?k=f4b2d6351b8051c8.f4b2f181-57184a53d0f219a2&u=http://dnsczar.com> and sheldns.com<http://sheldns.com> on those respective nameserver pairs.
The TLS certificate names match the NS names for those domains.
The test domains are also DNSSEC signed.
(The domaincontrol.com<http://domaincontrol.com> zone is not yet signed, so no DANE/TLSA for the certs just yet.)

Please feel free to test against those domains, and feedback on that testing is being actively solicited. Send feedback to bdickson1@godaddy.com<mailto:bdickson1@godaddy.com> please.

All credit for the DoT goes to my colleague Michael Sheldon (as do all the GoDaddy DNS software kudos.)
We are supported by our excellent ops team including Brian King, Jason Lynch, Frank Even, and Tyler Stanton.

Brian Dickson

On Mon, Oct 28, 2019 at 3:24 AM Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com<mailto:alex.mayrhofer.ietf@gmail.com>> wrote:
I've just posted the -00 individual submission version:

https://tools.ietf.org/id/draft-lmo-dprive-phase2-requirements-00.txt

Sorry for the delay, but i hope that people still have some time to
look through that draft.

best,
Alex

On Fri, Oct 25, 2019 at 8:59 PM Livingood, Jason
<Jason_Livingood@comcast.com<mailto:Jason_Livingood@comcast.com>> wrote:
>
> I just submitted my final changes to Benno and Alex and put the ball in their court to send something over the weekend or on Monday morning in Austria or the Netherlands. It is a very early -00 and so intended to mostly spur WG discussion.
>
> Jason
>
> On 10/25/19, 11:05 AM, "dns-privacy on behalf of Brian Haberman" <dns-privacy-bounces@ietf.org<mailto:dns-privacy-bounces@ietf.org> on behalf of brian@innovationslab.net<mailto:brian@innovationslab.net>> wrote:
>
>     Hi Paul,
>
>     On 10/25/19 10:27 AM, Paul Hoffman wrote:
>     > On 10/25/19 6:25 AM, Brian Haberman wrote:
>     >> https://datatracker.ietf.org/doc/agenda-interim-2019-dprive-01-dprive-01/
>     >>
>     >> On 9/25/19 10:45 AM, Brian Haberman wrote:
>     >>> All,
>     >>>       We are going to hold a DPRIVE virtual interim meeting on Oct. 29th
>     >>> at 4:00pm CET / 11:00am EDT / 8:00am PDT. The three agenda items are:
>     >>>
>     >>> - Review updates to the BCP based on WGLC comments,
>     >>> - Review updates to 7626bis based on WGLC comments,
>     >>> - Discuss recursive-to-authoritative requirements (-00 draft forthcoming).
>     >
>     > Will we be able to review the forthcoming recursive-to-authoritative requirements draft before the interim meeting?
>
>     I have asked the authors to post either a -00 draft or a doc on GitHub
>     before the interim.
>
>     Brian
>
>
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org<mailto:dns-privacy@ietf.org>
> https://www.ietf.org/mailman/listinfo/dns-privacy

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org<mailto:dns-privacy@ietf.org>
https://www.ietf.org/mailman/listinfo/dns-privacy