Re: [DNSOP] [Ext] More private algorithms for DNSSEC

Mark Andrews <> Tue, 29 March 2022 20:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19B563A1C11 for <>; Tue, 29 Mar 2022 13:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Status: No, score=-2.109 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_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=OO0F3Lri; dkim=pass (1024-bit key) header.b=PAvt0Q4e
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W2CSQia3zADi for <>; Tue, 29 Mar 2022 13:30:59 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD1B83A1C0D for <>; Tue, 29 Mar 2022 13:30:59 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by (Postfix) with ESMTPS id C07B23AB007; Tue, 29 Mar 2022 20:30:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 C07B23AB007
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=ostpay; t=1648585857; bh=wVv4gRmPeQ75l0m5/ClmzDIsJE/Fayt5wcAwEE8x1es=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OO0F3LridwUHUGvwPSP8293bfLQxXGelpZ4Tw905fLbBCyLz8SEndDoqLPHQ8D9ik Inp/bZHq0EgEgLaA47461rKj6khkNriPx5nWBb5wiLh24IAV+JkiqNxOY3kwDr9O+6 c8gsDqWpPA+kiRpAJb4p8GpOPOoMbUkNttj0oFk8=
Received: from (localhost.localdomain []) by (Postfix) with ESMTPS id 208A2110553B; Tue, 29 Mar 2022 20:29:54 +0000 (UTC)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id EB9F4110553D; Tue, 29 Mar 2022 20:29:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 EB9F4110553D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1648585794; bh=FQbJ+8pwZsaz+effBTIjYakF98xQfJ8nedMrp8S91Gw=; h=Mime-Version:From:Date:Message-Id:To; b=PAvt0Q4e5OiMsLeNUnUqRgBjCjOXxWLQ7fgJ9rxsyUYNkv2tNTv61EShglUxwO/+L TdA+jGEVzYoJ0OuvVTzYqDwzQDGqrrFFmTCftiZYDNr8IuIw7VTmur1uE7V4uM1vGG f8umEwGIBNSgSTdoC7sUPYjtDh3AhjFrC5muFf9s=
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id jdvwdOYUTKiC; Tue, 29 Mar 2022 20:29:53 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPSA id 240C2110553B; Tue, 29 Mar 2022 20:29:52 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Mark Andrews <>
In-Reply-To: <>
Date: Wed, 30 Mar 2022 07:30:52 +1100
Cc: Paul Hoffman <>, dnsop WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Peter Thomassen <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [DNSOP] [Ext] More private algorithms for DNSSEC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Mar 2022 20:31:06 -0000

> On 30 Mar 2022, at 00:28, Peter Thomassen <> wrote:
> On 3/28/22 20:34, Mark Andrews wrote:
>> About the only part not already specified is matching DS to DNSKEY using PRIVATEDNS but as you can see it is obvious to anyone with a little bit of cryptographic understanding.
> That creates problems plus complexity, which I find very undesirable. Orthogonality trumps complexity.
> For example, zones need to have a DNSKEY for each signing algorithm given in the DS record set. I would expect most implementations to currently only look at the algorithm number in this context, and not at the 253/254 algorithm identifier.

And if they don’t implement any PRIVATEDNS or PRIVATEOID algorithm this is EXACTLY the correct behaviour.

> Of course, a dedicated document may clarify this, but I don't see how this is less complex than assigning experimental algorithm numbers. All DNSSEC software out there would have to implement it, test/maintain it etc. This does not only apply to resolver software; think of application-level libraries like dnspython etc.

This is like all the cries of “think of the children”.  Adding support to look for a domain names at the start of the
key data in code that already extract domain names from packets should be a no brainer for any piece of DNSSEC software.

> There will also be implementations which don't care to implement such "private algorithm peeking". For those, algorithm handling would not be ensured in the same way as it is for non-253/254 algorithms.

Then they would be broken which by the way is why you run experiment.  

> Further, if someone actually *is* using private 253/254 algorithms in production, any experiments would not be structurally independent from potential such private use cases. Giving the little confidence that all DNS software would implement "253/254 algorithm disentanglement" correctly, private-algo zone owners may be hesitant to run any experiments at all.

If someone is using PRIVATEDNS or PRIVATEOID then they should be following rules for using that code point.  Are the experiments that use deliberately broken DNSSEC zone “structurally” independent?  

> Last, I'm not convinced that running a PQ algorithm (or other) experiment to test (non-supporting) resolvers' behavior should require controlling a domain name or OID (as is required for 253/254).

So rather than that you want to have to deal with potential colliding use of code points without identifiers.  That is
far worse than having to deal with PRIVATEDNS and PRIVATEOID as then you do get false validation failures.  You can’t
reliably clean up experimental code points, especially if there are a lot of implementations.  DNS has a long tail.
With PRIVATEDNS and PRIVATEOID you don’t need to cleanup the old code when the experiment is over, you just choose a
new name / OID for the next experiment.

To reliably run the experiments one is going to have to have a magic number for each algorithm embedded in the key data
and check it.  We have two code points that this do this already.  We don’t need anymore.

> These concerns bring us back to Nils' comment that 253/254 is not a good basis for performing research and doing real-life experiments.
> The above headaches would be in addition to the effort of writing the clarification document, whereas Paul's proposal requires just the document.

DNSSEC RFC say check the algorithm for a match.  They do not say check the number.  PRIVATEDNS and PRIVATEOID are sub typed
and checking of those fields was always required once you implemented an algorithm in those spaces.

> I therefore support the assignment of experimental algorithm numbers, and I think the text should mandate that they MUST be treated as unknown and have no special processing, unlike private ones.

Stop calling for polluting of the commons.  We can’t properly cleanup after using experimental code points.  We have 2
mechanisms that contain the pollution to a point (name/oid) for each experimental algorithim and we should use them.
This is good engineering.

> Best,
> Peter
> -- 

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: