Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

Shumon Huque <shuque@gmail.com> Thu, 19 November 2020 02:29 UTC

Return-Path: <shuque@gmail.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 CD5B83A09AC for <dns-privacy@ietfa.amsl.com>; Wed, 18 Nov 2020 18:29:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 lQcqlE00gqCt for <dns-privacy@ietfa.amsl.com>; Wed, 18 Nov 2020 18:29:12 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396313A0995 for <dprive@ietf.org>; Wed, 18 Nov 2020 18:29:12 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id y4so4206309edy.5 for <dprive@ietf.org>; Wed, 18 Nov 2020 18:29:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jnWSz9iUIDAYL1pPShUIBVP+N8SS7Zh1IUWHj8iQC7o=; b=a+BFyw65fvU2/gjOULu5f9L6e4Z8JaUUN21F0MRVWjD8/fTTqLEhFOCalED/AhA+Eb oX702oe2mGEbD6Nk7tV1H4CwpWrOXgoq4yU7Mk/m1lw1zekG7wFwYL/R/UeYryP5xpbp eHWT/TcWiM7t8r9KEMTT9OmKv9trt7UEtpdKyidf7tADFHNIaf6zHzshhYFQErWuzAHZ HLV5OIvZSv+v5PtSCnBkw32lJChKl1/jmavJoQih54/GJmKRk74qOA5xgT8bl31//nNT kvKNtJD5OLL+90gbSN7T7oiCZUmeTpUwEYqoJgKl8YXIC5+YQLErtnKdU//Djq+jrkT3 g2+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jnWSz9iUIDAYL1pPShUIBVP+N8SS7Zh1IUWHj8iQC7o=; b=quzRrJBuXCMvCESegQ1mCxLKj0qGT2nLUzRbDNq1HLRZIoll86iTcwSjgw0By1id8Q 5TKq8rbI+fQvcq/VVbk6jqrASNQTdG9W0ymTftuZm92tXajxccEl1AzwP+zWIUU4J/a1 FTyPm4SF9isrmtrfUkzEfeSdtqZi2jKPjaUHJXhQNeLEcDg9kClESC0o6MqBxanAAneK 5RQ0f6SbwA8x0lLCUVWYiemAjwMdwvi6mjVJEstlIZ1PVtY17oDDbz71R02ikLvqH++S fPYAuYnFt2nOQKwNsx/CF373HsHFhtEqQgryTiso35Ui5yb4BWJYJP62hddcWQdCreZX tp0g==
X-Gm-Message-State: AOAM531YC/50EeYQ3M7ETHlP+cTWlAIKwpdb35qyyhEer0TMxeOxthe1 Q+H+W5cIE+2laEAZbHtjUxAzkUs0rF5cDMJN+hDSn4v1QDA=
X-Google-Smtp-Source: ABdhPJz2cfDJfmEwUD7L6ER5PxJ44DRgp5XWsPMkOngrdTNAZqgRjeU0YQpOawcsKDlWhBg68dvo5wbw3PbUvKf/804=
X-Received: by 2002:a05:6402:16d6:: with SMTP id r22mr29344878edx.246.1605752950686; Wed, 18 Nov 2020 18:29:10 -0800 (PST)
MIME-Version: 1.0
References: <C0CBEBC5-D28A-46C0-AE50-078710015466@icann.org> <alpine.LRH.2.23.451.2010301202350.2587497@bofh.nohats.ca> <2444B21B-9465-4A5B-97CC-AF809309300A@icann.org> <CABcZeBPZFY9aQ5Nb0q_4uTMFRbY3-S2rus4vaeLaUmvU+h_ftg@mail.gmail.com> <2D07CBD0-30CE-418E-AD05-02E0A5EDB79F@icann.org> <CABcZeBNdNnyjzk0mOtfix=OvVTEpPzegEw_V5QfKvYtkFV+zOw@mail.gmail.com> <CAH1iCirz27EoahrYE8z9AV=Cf=A-i=iPP1deOYPWO8_k1mL+XA@mail.gmail.com> <27ddd3bde1ea11c857a96346b6f4ba5aa8b1d92f.camel@powerdns.com> <alpine.DEB.2.20.2011172300480.9850@grey.csi.cam.ac.uk> <4dda183c1fa079816b79d04ed7d1ca23f1412382.camel@powerdns.com>
In-Reply-To: <4dda183c1fa079816b79d04ed7d1ca23f1412382.camel@powerdns.com>
From: Shumon Huque <shuque@gmail.com>
Date: Wed, 18 Nov 2020 21:28:58 -0500
Message-ID: <CAHPuVdWOF-7LU3BxKsqpbVhkO5Dz-76dx741D0+JDbnZ4C38wg@mail.gmail.com>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: "dprive@ietf.org" <dprive@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003907e205b46c7e8c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/jrwP1prvuxdd0oG0TiGacLYSUmo>
Subject: Re: [dns-privacy] [Ext] Revised opportunistic encryption draft
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: Thu, 19 Nov 2020 02:29:14 -0000

On Wed, Nov 18, 2020 at 3:42 PM Peter van Dijk <peter.van.dijk@powerdns.com>
wrote:

> On Tue, 2020-11-17 at 23:30 +0000, Tony Finch wrote:
> [...]
> > If (big if) we think it's worth upgrading the DNS delegation model (and
> > EPP, and all the registries and registrars, and all the IPAM databases
> and
> > user interfaces, and documentation and textbooks), can we also tackle the
> > scalability problem? By "scalability" I mean the need for a hosting
> > provider to update NNNNN delegations when a server cert changes. And
> there
> > are decades old problems keeping delegation NS and glue and DS records
> > correct. (A large chunk of the "it's always DNS" meme comes from how hard
> > it is to understand delegations and update them correctly.) This whole
> > area is a massive pain in the arse sorely in need of universal
> automation.
>
> +100. I've referred to this in other threads - if CloudFlare had gotten
> anywhere with their attempts to solve the operator / registrant /
> registrar / registry disconnect problem, all of this would be so much
> easier.
>

At ICANN69's DNSSEC Workshop last month, Steve Crocker issued a
challenge to DNS Operators to organize and become an officially
recognized constituency within ICANN. If that were to happen, then it might
be able to address and solve some of these issues over time, given
adequate engagement.

> Any serious attempt at improving delegations needs to deal convincingly
> > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so
> > appallingly bad.
>
> Yes, or in the broader sense, my previous paragraph.
>

At the same workshop, Jim Galvin spoke about some of the structural reasons
why it's challenging for the contracted gTLDs to make progress on supporting
these (and also likely why there has only been adoption at a small number of
ccTLDs, who are non-contracted parties). This was in relation to CDS and
CDNSKEY. As far as I can tell, no-one has shown any interest in CSYNC to
date.

Shumon.