[DNSOP] Looking for panelists for DNSSEC provisioning session at Cancún ICANN meeting in March

Steve Crocker <steve@shinkuro.com> Mon, 27 January 2020 15:22 UTC

Return-Path: <steve@shinkuro.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA81120271 for <dnsop@ietfa.amsl.com>; Mon, 27 Jan 2020 07:22:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=shinkuro-com.20150623.gappssmtp.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 4wArG2MGuTOh for <dnsop@ietfa.amsl.com>; Mon, 27 Jan 2020 07:22:23 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 4D426120836 for <DNSOP@ietf.org>; Mon, 27 Jan 2020 07:22:23 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id cy15so11175898edb.4 for <DNSOP@ietf.org>; Mon, 27 Jan 2020 07:22:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=oYBlPvyllNAe/ooEz4oclHiQvnUUL5Wa60eDdy8RJHE=; b=IDrWkBvXXhlfAe118tNNdvPE+Syt+mkZeJMi6dTZAs27tAIo7XmVvZ1lckPUbzDaGs vYEGmAgav8PYWQLqD1G0RIW3YXk3Bgfd9gf2M5gJkmXwbcZcY4nqsXLOCt/vcUs0HTEM X1YBChU9pkU3ObEi2MW1f0Yreoxo4d7gFvXukXtFngoDFPCOr3SoAgWvd5HJCyiO2ZE6 LKrqCdPHYoMzf21EC3KYfxeAxVQfnVNTnkUomhloqTF0RJtWwvMvuAF9UCLBDt6Np5XW +qGaYnWx+2dsAIF65LRnjrd7/uAaWb9COjsnpZA7Qiqjks5tlt4OBix0JKgTtVJsGLhd Poqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oYBlPvyllNAe/ooEz4oclHiQvnUUL5Wa60eDdy8RJHE=; b=npFg5RBK5u6YW8O7dxV5ORUSqFa9sTUxO7UiU+176P/X98R8KDgpNGECou/aE/jCVX cPvqPiY8jKOKn177m6KR+u6BGyTJhqq+tm2sWEpNS2vHtDmiULKBr+y+Un2YM5Vu0Gkj UXPBw8bch55sbhGpIIghlxlAerBxCsLWVAyY8uPaCVcbhRuTPg8UvgEEU+BEH9Q/f9OX hjA1EL35E9F6dPf2zsT/kaohuSSjQwwTcCFPXwttP4dnnFqCY8OYzpkW2h58Af1AywxO hXio4MNL72aSjFwyxMy4HbaFzcuOkBfWZRvpL2//cEe4Gw/NGP8UDEFTwvWp3l/JPRB8 zZ0Q==
X-Gm-Message-State: APjAAAUjdEWZjsO2FNLmotbGjC4cOgmImKeZPgvFgXaxCVAu+/VFtAiu EI68aWUo8/b9hU2JxHtrg2nyn6SGJPD9Qgz9nl896FwSY0k=
X-Google-Smtp-Source: APXvYqwZ7fbdP2QFvjWEX91MrGtNHnXHwmbQq2h5OAnOjmAEDXd85JuOZvPdcQDN9Q7zzMGY306bBT/JgLokMYyPMlc=
X-Received: by 2002:aa7:d853:: with SMTP id f19mr14335748eds.319.1580138541354; Mon, 27 Jan 2020 07:22:21 -0800 (PST)
MIME-Version: 1.0
From: Steve Crocker <steve@shinkuro.com>
Date: Mon, 27 Jan 2020 10:22:10 -0500
Message-ID: <CABf5zvLpW6MYR-oeAEw9wjxg9AmUGh3hRN3=8NuCRezamGXCRg@mail.gmail.com>
To: dnsop <DNSOP@ietf.org>, DNSSEC Provisioning <dnssec-provisioning@shinkuro.com>, DNSSEC Coordination <dnssec-coord@elists.isoc.org>, "dns-operations@lists.dns-oarc.net" <dns-operations@dns-oarc.net>
Content-Type: multipart/alternative; boundary="000000000000741d1e059d20ac87"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_TeBWxYw0755Rd0VCpKiCV_pfHw>
Subject: [DNSOP] Looking for panelists for DNSSEC provisioning session at Cancún ICANN meeting in March
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2020 15:22:25 -0000

Folks,


I am organizing a panel session within the DNSSEC Workshop during
the upcoming ICANN meeting in Cancún in March on the subject of DNSSEC
provisioning.  There are two related but somewhat distinct topics.  One is
the update of the DS record when the DNS provider rolls the key.  The other
is how multiple DNS providers coordinate when each is signing the zone.
Various proposals exist to solve each of these problems, but none has been
fully accepted, and each suffers from a gap in the provisioning process.


Depending on who is on the panel and we can cover either both topics or
just the first topic.  I also intend to organize a session on these topics
in Paris in May at the ICANN Global Domains Division Summitt and/or the DNS
Symposium.  Also, the dnssec-provisioning@shinkuro.com mailing list is
specific devoted to these two topics.


Please let me know if you're interested in participating and if you have a
position on how to address these problems.


*Details*


What is the path forward for automating solutions to these two provisioning
problems?  Are new protocols needed?  What changes are required of
registrars, DNS providers and/or registries?



With respect to updating DS records, the solution space is basically a two
by two matrix, with a subordinate third dimension:

   - Are new DS records pushed upward, i.e. is the transmission initiated
   by the DNS provider, or are new DS records pulled upward by the registry or
   registrar?

   - Is the registry or the registrar involved on the upper end of the
   transmission?


The subordinate third dimension is whether the KSK, DS or both are
communicated.


The solution in RFC 8078 is the pull/registry solution with support for
both KSK and DS.  It was developed by a couple of DNS providers and is on
the IETF standards track, but, so far as I can tell, is being adopted by a
relatively few ccTLDs and is not gaining any traction within the gTLD
community.  In contrast, GoDaddy has suggested its Domain Connect software
could be extended to allow a push/registrar solution for DS updates.



With respect to coordination among multiple DNS providers, Shumon Huque, et
al's Internet-Draft
https://tools.ietf.org/html/draft-ietf-dnsop-multi-provider-dnssec-01
[tools.ietf.org]
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddnsop-2Dmulti-2Dprovider-2Ddnssec-2D01&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=_qSa12UaM5Nl6sbpmBZnYyeUu-qJt2ubgQJechcqldM&m=zQDYr_jJSOyuDOEF5tU7f-JhexPBRkY5Clkb6Rn9m3s&s=eH4Q6Yxg9dNg2IRqEmEWewca-7dYhKmHKbAZyCP7yHg&e=>
sets
for a scheme for multiple DNS providers to coordinate cross-signing of the
same zone when it's served from multiple providers.



I have both a general and a specific interest in this.  The general
interest is in seeing some sort of solution be adopted in order to
facilitate smoother operation and greater adoption of DNSSEC.  My specific
interest is a guess that if the registrant could add the names of his DNS
providers into the registration details, it would make both of these
coordination processes much easier.


Thanks,


Steve Crocker