Re: [dns-privacy] Next steps for draft-rescorla-dprive-adox

Paul Wouters <paul@nohats.ca> Wed, 12 May 2021 01:36 UTC

Return-Path: <paul@nohats.ca>
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 569E43A2E41 for <dns-privacy@ietfa.amsl.com>; Tue, 11 May 2021 18:36:52 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca
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 Ky941utCVrD1 for <dns-privacy@ietfa.amsl.com>; Tue, 11 May 2021 18:36:47 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 928A63A2E45 for <dprive@ietf.org>; Tue, 11 May 2021 18:36:47 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Ffy7V64ZDzWh; Wed, 12 May 2021 03:36:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1620783398; bh=i/yooGEJF8SSr+or9rFqMIYGf/S52NFGQbe6/nL/vd0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XT9OtzxguOaNe/XhqLamnfab9GXLBoyYkhvGbbH0MvjKHuGEVLgdBEWe9BvoPBjJ7 4VHIvwA3TT6dHob1ZR1o9CK4DOE8gWkFaPhfUgJI7X/djVQNcWbSR1+xrRnotOY+oQ 3L+5TqRrzk4JeF3hGndDqU5WFcpmBZkfJLEC8xcs=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 0_rFQGLFPJTP; Wed, 12 May 2021 03:36:37 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 12 May 2021 03:36:37 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6550357CF0; Tue, 11 May 2021 21:36:36 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5E60557CEF; Tue, 11 May 2021 21:36:36 -0400 (EDT)
Date: Tue, 11 May 2021 21:36:36 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Eric Rescorla <ekr@rtfm.com>
cc: dprive@ietf.org
In-Reply-To: <CABcZeBOKv66-SOqYZDG0=v=X6tQOAobz4DZx9sD3-ppTE+wGOg@mail.gmail.com>
Message-ID: <b8e6cf4e-58d5-f173-f7cc-c41ca626c@nohats.ca>
References: <CABcZeBOKv66-SOqYZDG0=v=X6tQOAobz4DZx9sD3-ppTE+wGOg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/qO88IuvqevrPlKp3p2OiiBqH5lQ>
Subject: Re: [dns-privacy] Next steps for draft-rescorla-dprive-adox
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, 12 May 2021 01:36:53 -0000

On Tue, 11 May 2021, Eric Rescorla wrote:

> From my perspective, the primary open question is the wisdom of having
> some kind of record in the parent domain.

> While I understand that there are people who have reservations about
> whether it will be practical to popuate the parent

This is not about some people having reservations. As I explained
before, you are talking about:

- Updating DNS resolvers understand a new DS-like record on the 'wrong'
   end of the zone cut (incompatible with RFC 3597)
- Updating DNS auth server code to serve a new DS-like on the 'wrong'
   end of the zone cut (incompatible with RFC 3597)
- Update all the DNS servers run these new DNS resolvers
- Adding a new EPP extension to transport the new record to the
   Registrar
- Adding a new EPP extension to transport the new record from the
   Registrar to the Registry
- Registrars updating their code (libraries and webgui)
- Registries updating their code (libraries)
- Updating ICANN contracts about allowed RR types
- Writing CDS/CDNSKEY style auto-updating for this new record
- Updating zone file verification tools to not barf on record being
   out of bailiwick

Last time, I recommended you talk to people at the REGEXT working
group, Registries/Registrars and DNS hosters, our ICANN liaison or SSAC.

Did you contact any of these people to ask about the feasability of
your proposal?

> 2. Is this proposal a plausible starting point for that?

No it is not. If a TLD that falls under ICANN policues would suggest
running software that supports this proposed record, it would surely
trigger an RSTEP review, and wearing my ICANN RSTEP reviewer hat, I
would strongly advise not reject the TLDs technical proposal.

This has nothing to do with what I want. I _want_ this record or similar
solution to work, but it just realistically cannot work. That is also why
people (including me) who are normally very strict against overloading
have suggested the only way to signal something at the parent is via
overloading the NS or DS record in some way. And using DS is better
because it is signed and can be verified at the child.

Paul