Re: [dns-privacy] DOTPIN, TLSA, and DiS

Peter van Dijk <peter.van.dijk@powerdns.com> Mon, 23 November 2020 11:56 UTC

Return-Path: <peter.van.dijk@powerdns.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 0E1D73A097F for <dns-privacy@ietfa.amsl.com>; Mon, 23 Nov 2020 03:56:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.402
X-Spam-Level:
X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 dDwjE1JgrSBT for <dns-privacy@ietfa.amsl.com>; Mon, 23 Nov 2020 03:56:21 -0800 (PST)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 513183A097E for <dprive@ietf.org>; Mon, 23 Nov 2020 03:56:21 -0800 (PST)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPS id E27156A307; Mon, 23 Nov 2020 12:56:19 +0100 (CET)
Received: from plato (84-81-54-175.fixed.kpn.net [84.81.54.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id C16083C024B; Mon, 23 Nov 2020 12:56:19 +0100 (CET)
Message-ID: <6ed04ef18e91a5379cb064f9658bf7b2586d00e8.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dprive@ietf.org
Date: Mon, 23 Nov 2020 12:56:19 +0100
In-Reply-To: <CAH1iCipHHUDp3RBO4zaYCpcqyx6GQcLxTW4Fj8-psFpYmYf81g@mail.gmail.com>
References: <196c57a1f39d73fdbf0e7ee0c597bec2bec94148.camel@powerdns.com> <a4e2f776-91b6-f825-03f9-8287e7b29509@nic.cz> <CAH1iCipHHUDp3RBO4zaYCpcqyx6GQcLxTW4Fj8-psFpYmYf81g@mail.gmail.com>
Organization: PowerDNS.COM B.V.
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/S-DX9mv5cKxUtbGX0AcyQTQWFUE>
Subject: Re: [dns-privacy] DOTPIN, TLSA, and DiS
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: Mon, 23 Nov 2020 11:56:23 -0000

On Fri, 2020-11-20 at 12:14 -0800, Brian Dickson wrote:
> 
> I think we (the three of us and maybe Tony Finch, if not the whole DNS community) may be converging on a design that will, I believe, work.

This is not the first time that design has been proposed. It is the
first time it was not met with only criticism, however!

> I just checked on something that was nagging at me: 
> Is there a way to secure the NS set without requiring the delegated zone to be signed?
> I believe the answer is "yes", at least assuming implementers follow RFC 4035 correctly.
> In section 5.2, the Nth paragraph reads:
>     " If the validator does not support any of the algorithms listed in an
>    authenticated DS RRset, then the resolver has no supported
>    authentication path leading from the parent to the child.  The
>    resolver should treat this case as it would the case of an
>    authenticated NSEC RRset proving that no DS RRset exists, as
>    described above."
> 
> So, using a new algorithm for whatever we do, should be 100% backward compatible.
> The assumption is any resolver supporting the new algorithm does so correctly, and
> that any resolver that does not support the new algorithm does the right thing (treat like unsigned).

In early 2019, Knot Resolver and 8.8.8.8 had trouble with this. They've
both been fixed a long time ago now. < 
https://mailarchive.ietf.org/arch/msg/dns-privacy/HiqLSzeWRgwseOh6JiNBkScSq_o/
>

> This means the design can be as simple as "put stuff in an apex DNSKEY record with a new algorithm)",
> plus put the corresponding DS (hash of DNSKEY elements that DS uses) in the parent zone, is sufficient.
> Note that for TLDs, the mechanism for this would be EPP sending of DS (or DNSKEY), and/or using
> the CDS/CDNSKEY mechanisms.

Yes - I don't think the data functionally needs to even appear in the
child's apex DNSKEY, it just needs a delivery mechanism into the
parent.

(In DiS, the delivery mechanism is "the parent's zone signer software";
that would just leave open the question of delivering the policy flag
that Vladimir mentioned).

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/