Re: [dns-privacy] [Ext] Revised opportunistic encryption draft
Brian Dickson <brian.peter.dickson@gmail.com> Thu, 19 November 2020 03:43 UTC
Return-Path: <brian.peter.dickson@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 8C1DA3A083F for <dns-privacy@ietfa.amsl.com>; Wed, 18 Nov 2020 19:43:54 -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 4zuCda4k9Nev for <dns-privacy@ietfa.amsl.com>; Wed, 18 Nov 2020 19:43:53 -0800 (PST)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 EC50D3A0829 for <dprive@ietf.org>; Wed, 18 Nov 2020 19:43:52 -0800 (PST)
Received: by mail-vs1-xe34.google.com with SMTP id f7so2272255vsh.10 for <dprive@ietf.org>; Wed, 18 Nov 2020 19:43:52 -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=WKwj7jKVeVWHeCVqkvMgW/jW46FrA8MKq7eV5/Fzn/o=; b=VAj9A8WMQESsO2+ZNz4F5IRENf5tboQGLJ9BU889mtqpgn8y2Quv2WI95bD01VH9iZ V9hiINIy1rqN83RiU3ApUeNwlB86zKSZ0BK+7am2A3c19y3C6/MHtaQYjuzPFK4R5FiJ KzWo/AwC6PnUeEu1b0csOSkb8yxBpmCGQYiE5G0LvD+qG9KS861WRX9xRNqMwJgycMpq 6UpLCZBBtZwTPMPeUtUUXlhZGHzg3XZY8CTGaUobPdba0AMrOqrI9ciTO3sVmK87jJXj M2k6yIolUhtnQX9Q5+cFTNIhnmrDVPTUX7TTp20VCyxdH4f3nNJe8WJHYfOZJiBhtiXp IsMQ==
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=WKwj7jKVeVWHeCVqkvMgW/jW46FrA8MKq7eV5/Fzn/o=; b=MExcbEN1sCnDkGJu3MWIOJomEmERKYIjTPmqiNqfkC4o9FNP5Zh4QWFONyPbZF3B9S ttLdd+hid7F/TDqzWB9/OhCLjnNMgMqunTE5f2Bt7nJzUOrkdzGuKGGSarlNCSlvXCp3 RUzKi+XRv4gaxIYnm93x6pzNE5IUgHNhaZI/LkcEU1e4R2knokKfeJmh1xZhjKeCQLea Oi+rGMJJ3sb52J+Wo3vg3RT8XiuJQQqatqa2eY8tdSXy4rh39gqeqROAGQxyL1VopUkY 4kaErkJ+X0oGGOXJ1v6F5dHJEGxzAYy3XE5vSZnk1b10MyzTbL0GLJ56ndcFeTZRN0LI nzpw==
X-Gm-Message-State: AOAM533Inw75c3xEe30eHOVUIAeywFHIcgrKZwzeCuANP8SS3qFbNQV9 tPhPgvWygMCrA1QC1txfbUSD4vO8wjF952EjJMo=
X-Google-Smtp-Source: ABdhPJx51wmV20JS7PqXIoNXylgn4nodomW3b50Mi+wwsVZO5GZLPDabyb4ak5KGlx69K/CTF2HPGMdpJYADJbm5NMc=
X-Received: by 2002:a67:eb42:: with SMTP id x2mr7032869vso.41.1605757432054; Wed, 18 Nov 2020 19:43:52 -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> <CAHPuVdWOF-7LU3BxKsqpbVhkO5Dz-76dx741D0+JDbnZ4C38wg@mail.gmail.com>
In-Reply-To: <CAHPuVdWOF-7LU3BxKsqpbVhkO5Dz-76dx741D0+JDbnZ4C38wg@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 18 Nov 2020 19:43:40 -0800
Message-ID: <CAH1iCirb6cPGq0fa_Uuqg-VciCPPqoKkXg9tCgQvswixD-X5ZA@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
Cc: Peter van Dijk <peter.van.dijk@powerdns.com>, "dprive@ietf.org" <dprive@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000055469105b46d8954"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/CcLTvBTUQMAxsPHsH5MqZairqOQ>
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 03:43:55 -0000
On Wed, Nov 18, 2020 at 6:29 PM Shumon Huque <shuque@gmail.com> wrote: > 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. > At the same Workshop, in our presentation I mentioned that we (GoDaddy) are intent on providing CDS/CDNSKEY support. This is to work around the logjam which is the RRR system and its structural limitations. Specifically, we will support our Registrar customers who are not DNS customers, by polling them for CDS/CDNSKEY records no matter who hosts their DNS. We will then submit those via EPP (which we can do only because we are their Registrar). Nothing about this is rocket science, nor is it anything any other Registrar cannot do. It's a hack, but it moves the DNSSEC ball forward, and doesn't require any new DNS "stuff" or Registry changes. Brian
- [dns-privacy] Revised opportunistic encryption dr… Paul Hoffman
- Re: [dns-privacy] Revised opportunistic encryptio… Paul Wouters
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Paul Hoffman
- Re: [dns-privacy] Revised opportunistic encryptio… John Levine
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Eric Rescorla
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Paul Hoffman
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Paul Hoffman
- Re: [dns-privacy] [Ext] Revised opportunistic enc… John R Levine
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Hollenbeck, Scott
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Eric Rescorla
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Brian Dickson
- Re: [dns-privacy] Revised opportunistic encryptio… Tony Finch
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Tony Finch
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Peter van Dijk
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Paul Hoffman
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Brian Dickson
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Peter van Dijk
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Brian Dickson
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Peter van Dijk
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Tony Finch
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Paul Wouters
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Paul Wouters
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Tony Finch
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Brian Dickson
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Tony Finch
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Peter van Dijk
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Peter van Dijk
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Tony Finch
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Shumon Huque
- Re: [dns-privacy] [Ext] Revised opportunistic enc… Brian Dickson