Re: [dns-privacy] [Ext] Opportunistic encryption between recursive and authoritative servers

Geoff Huston <gih@apnic.net> Sat, 12 September 2020 21:27 UTC

Return-Path: <gih@apnic.net>
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 813A63A0E28 for <dns-privacy@ietfa.amsl.com>; Sat, 12 Sep 2020 14:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net
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 wstJ9p91z1Cl for <dns-privacy@ietfa.amsl.com>; Sat, 12 Sep 2020 14:27:26 -0700 (PDT)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320055.outbound.protection.outlook.com [40.107.132.55]) (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 1BDD23A0957 for <dprive@ietf.org>; Sat, 12 Sep 2020 14:27:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cnQPixG0h1wXORxjK5PEwNbuQvbALkEwnD/qhuDXqjYR9hA7NOohaZPMQR7wH2x/Ebf8CMHpYBz/kFWYHTkU335uyKhSzpFNPwhjTS81K2kxYM2xaCAMOqJdnW/spW3kqKLBFJIb5ot527hpx8XMMAqqqm3Qd2cnAYKtq/DlGchjf2oR3wRq7msUyZYhTvFC0d3NuBhvGYzbBhhDl0LaeKb4ZTKKJuJzCaQohrPC0Qe0ZV/5PaVs/2U02CWWaEEAYTsmxD5FdQ8mfzjdihFajP8/CRILdPNu9lYYKKQbQ9x6ozb43RxPhewgKCUUDrTHQramthLrmxDdqx4pfQ/FTQ==
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=IA0kgY87Nrom3MOJDN8+qqLmlZ7izuoiWfmUV//sC9g=; b=VMdneRdVz3kdXfvSWBGOFea2pZ1We/q/iiKzdsajapYD/KGX2MkdsLSGXvTA1XZCEstGqg2v1oDHADYOKGRDOe66AX8OlqJ3w5uwmiaMQ4YCrIcLAZ+1Cv4U7K1uVLb4tmhiXxIcIJ+ltMjPlSQuMtLoIyBz8t7OBo8GxRYe/In4q1WSFYbCYQ7c9IACh/8a7ermY/B/2MtZXC5iTNF4em/K3MfeBobGGEg8w7uibTk0UgjrAXw8+A9PGvuvVzaW9lLDneRRs4k6t70CImjYY4YpSSHOAjPwG99TrRp0xjHsQPxJbuPsdgwT7Uj0nHFtSHyacHt055umXpYeqtYnpw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IA0kgY87Nrom3MOJDN8+qqLmlZ7izuoiWfmUV//sC9g=; b=LzwPWpExIVSR1J/L0BQD9AE1lZA5moRqKQK46ptkH1+sdv9O41+SBPjzMmZXwkSmq4e22JVbkQRU18ttZrMIM4QV9/0qkgqv6EmY5a0mgbVarKZSg6o8V+jsfaFa0pMocdTGE8bI4XlLQ7UIuNe00jD4w7+Vd9FIbd/1aP4vN/8=
Authentication-Results: nohats.ca; dkim=none (message not signed) header.d=none;nohats.ca; dmarc=none action=none header.from=apnic.net;
Received: from TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) by TY2PR04MB3886.apcprd04.prod.outlook.com (2603:1096:404:fd::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Sat, 12 Sep 2020 21:27:20 +0000
Received: from TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::51fd:b0f0:1c43:de3b]) by TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::51fd:b0f0:1c43:de3b%7]) with mapi id 15.20.3370.018; Sat, 12 Sep 2020 21:27:20 +0000
Content-Type: text/plain; charset=utf-8
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <8C8C42D7-EC2F-4374-A508-2BE3824B768D@nohats.ca>
Date: Sun, 13 Sep 2020 07:27:14 +1000
Cc: "dprive@ietf.org" <dprive@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <47B5776C-3CCF-4085-8F2A-B917F2102549@apnic.net>
References: <5AB5385A-FE70-4FB0-810A-1EF0762094E2@icann.org> <8C8C42D7-EC2F-4374-A508-2BE3824B768D@nohats.ca>
To: Paul Wouters <paul@nohats.ca>, Paul Hoffman <paul.hoffman@icann.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-ClientProxiedBy: SY4P282CA0016.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:a0::26) To TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from 2001-44b8-110b-5100-0440-191b-b1e3-3449.static.ipv6.internode.on.net (2001:44b8:110b:5100:440:191b:b1e3:3449) by SY4P282CA0016.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:a0::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16 via Frontend Transport; Sat, 12 Sep 2020 21:27:18 +0000
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Originating-IP: [2001:44b8:110b:5100:440:191b:b1e3:3449]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: be651642-8806-4e80-5c2e-08d85762a196
X-MS-TrafficTypeDiagnostic: TY2PR04MB3886:
X-Microsoft-Antispam-PRVS: <TY2PR04MB38868B2109063E209E0D5BB0B8250@TY2PR04MB3886.apcprd04.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: q8VrRUEX/LUnWMBFQKxLN+uhYXxbeXMik92NvS6gLrYIo2v/H2JspQW6ManzBX1RM8rLCMjLwcz/ChWrd//9C4OyYJFastPmbdmia68jGD3oLBbUr2XgMSsbeXHj3oS1fVWALmajtc+TqsjkvYgSVU0GB0IeguQWzHgrqO6B5t/hsN+MfUDyWFNhDAjMccCDEWFsWymcDi139OVarlmuFxdZv8OWoPJEVG69FFPLu5hWzRpxOcirX8Po2OMSsKOq48HLgqAEXtczsHRVrA7FCPjA1Kp3ZDoOdxvHaej6YZluMAvWUD0/VQmkeLztajgzIEp7ZzH/8hN2voJZn+wUmg==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR04MB2286.apcprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39830400003)(136003)(366004)(396003)(346002)(110136005)(66556008)(66946007)(478600001)(66476007)(6666004)(52116002)(16526019)(186003)(5660300002)(2906002)(2616005)(33656002)(6512007)(316002)(86362001)(6506007)(8676002)(6486002)(8936002)(4326008)(83380400001)(36756003)(66574015); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: yfjfrs+ZZmsc1OetmmcWpBxIfLFwTaFMS1yzspcc/SL6ybe8hM8y8RL6ZWBXzfxlSLSpKow5JG127Cg6osVD9paDAlM/iGUddYNTM41PXmohSQXWmEAw87vgPIwuKQA4U+feqEz87EwL/DWsC8SLVBui2M0Vvizm8f8QStvP36Bs5tJnksYI0E1fxRhEKtD/8f5EGUR3WBKapojQXSjpIcaFCJs4sUWz/zG+uUXBOfd35Bv5Iaot9YP/hwDBApS044eRFjB1Ju4mWPkBICgOVu+B9tZM0uWbbfekjVRTmBIbo0r/zdN7Lqu/JzD27tPtS4d3mVkBAFhJzQrO0LDYsviBJZ9MniBWyt+A9UA/aUHhrTqsAjBtoYl72KSouoIXoYGne70/HMBk1GUlNG0piYsyWskMRemGeVZtI+Jvurfo6zEJLk8Mc8XyTXHIVilGJs9+Hu4fCNK+Kqnp5AzBpqkcR+Lntn3X4urSTFWb6o/KxXvos2qinYlDjTaiu2iMiRVH5QoqImUY/F4eW/BUws6SwqZnHOPfbFu94n746F1D/M3AdAe3JcKzeJwN0wQYhbjY6vulplTVfUcnzJSwXDLHlbsCIS8Ism0/Ju38X+jnrKPVrxplg+SOb1Q2cdo9joOH8xTUcAyc7M1MbaisZ6H8VA2ls2o8aSxjnbKwptErjlPoPF5fC5SZsR4f4rRIfoVBhiKDoZGNn/B36mIp0g==
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-Network-Message-Id: be651642-8806-4e80-5c2e-08d85762a196
X-MS-Exchange-CrossTenant-AuthSource: TYAPR04MB2286.apcprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2020 21:27:20.4281 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: cK9fI0Vuo3oQ9cUuMnSWh/DldxYflvoneKYEYPXgOwQtT84bgdz5+LQXmZaMTAC0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR04MB3886
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/i-bnORxxhDFJae_XA6IT5dNL6ng>
Subject: Re: [dns-privacy] [Ext] Opportunistic encryption between recursive and authoritative servers
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: Sat, 12 Sep 2020 21:27:29 -0000

Paul and Paul (and the WG),

> 
>> Primarily because that is only of value to resolvers that are validating, and that's the small minority of resolvers.
> 

Whats “a resolver”? Is Google’s DNS service one resolver or hundreds? Of Cloudflare’s 1.1.1.1 farm? What about Chinanet’s service where thousands of IP addresses all act in remarkably similar ways? Frankly, any statement about “the majority of” or “the minority of” resolvers is a pretty meaningless statement from such a perspective. Is my recursive resolver at home that answers queries for just me equal in any way to Google’s service which is used by one quarter of the Internet’s users? Yeah they are both resolvers, but thats about it.

> 
> Which of large resolver operators is not validating ?


well we have a good idea of the answer to that question:

Open DNS resolvers that do not perform DNSSEC validation:

114dns (VERY large in China)
dnspai (again, big in China)
onedns
opendns (some instances of Opendns’s cloud, but by no means the entirety)

> Which of the stock opensource resolvers is not validating with a default configuration ? 

I believe there are a few that require the local admin to enable it and the distro has it disabled by default.


> 
> Arguably the only ones left not validating are phones and we are busy giving them DoH and DoT to servers that do that for them.


um, not really. In the US the ISP resolvers that don't validate include AT&T, Cellco, T-Mobile, UUNET, Charter,... It's probably easier to list the major ISPs in the US that do DNSSEC validate : Comcast. In Canada the ISPs resolver systems that don't include BACOM, Rogers, Shaw,…  Further afield, some of the extremely large ISP resolvers in India validate (Reliance Jio), but in China, not.


> 
> I think your argument does not hold.

I find it hard to agree with either assertion about the prevalence of use of DNSSEC validation here.

The argument that DNSSEC is just a minority corner case does not hold water these days - 25% of the world’s users pass their queries through DNSSEC validating resolvers and will not get an answer if the validation fails. A further 10% of users also use DNSSEC validation and then fail over to non-validating resolvers in the event of validation failure. 1/3 of the total user base of today’s Internet use DNS recursive resolvers that perform DNSSEC validation. Thats not a small minority. There is a lot of DNSSEC validation out there for users and a lot of large resolver systems serving these users.

But 2/3 of users do not use DNSSEC validating resolvers. So it's by means the default case for the DNS.

But DNSSEC validation continues an upward trend and given the standard lifetime of IETF work (2 years and 17 days on average for a draft these days) then the numbers for DNSSEC use will only grow. Accordingly, I have far more sympathy with Paul Wouter’s assertion that bringing in yet another mechanism of opportunistic encryption is one more straw-like adornment to the DNS camel (to use my own interpretation of Paul W’s comments) while a TLSA record could perform the same role, obviating the need for opportunistic encryption to authoritative servers.

regards,

Geoff