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

Brian Dickson <> Wed, 30 March 2022 03:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B6D13A08AE for <>; Tue, 29 Mar 2022 20:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NAMr6AIJB0o9 for <>; Tue, 29 Mar 2022 20:29:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 400673A08A1 for <>; Tue, 29 Mar 2022 20:29:19 -0700 (PDT)
Received: by with SMTP id yy13so38884450ejb.2 for <>; Tue, 29 Mar 2022 20:29:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=86hRmCQl6AG+5WAHvh2oRM9I/V6R3rGmsP4aeMK4GXE=; b=HpDixofs1JPWEqZq0c2cGJN+ArBEGqliUXHbz29x1EtUooV6z5ll7D12GMdCk5ud4b tflUfhRlaTPnkYJ+5ZT72etB8jt1mk2QWDwEs7davKE0OsXHer9Nz68+FXXf3PdvaD+Z D2kxvGZoPuAwtFa8l8BnPbFwPpsW5IoaI9rx2dLKswd3HhxvPihun6RiJGCon/Kg1tSA k0guP8sNi0J/eukpb3TtMOhNkiPnGB6bfWCOGpr/IXd1ziYwELC6PnWdjc+iR1DbmsR0 IoCzqzhc+GcGva+tWqITOppvcHPrylS113VC6o4i8CfRqSxCCK9Ku//U+nkCn3vIUizL 1vvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=86hRmCQl6AG+5WAHvh2oRM9I/V6R3rGmsP4aeMK4GXE=; b=RGLzmBIRXeY8w0wOuXmXaqxlhFYY7CA13T9NmuEG8p2tmKHhCVv33hlWNbbY4Q3fad MEda/K2zG4Pksq//7bkxxEsxMT4JwcmsMa7TT3I8Kh58er6GwEA1mZ7rVuaJ/H6/7tuM 9DcHJ2VnkBz3lJx95V6BvM/lUxKLoXxKGBKxNza3BJ4UNkzBsgtuguMfJsyPbwVq7x9r H6ZPqZkkb3LiHrB/gLVJWraYvVhf1Kh4jSC/jAoL6eokrGHwZ6x5Y4l4eWgVqBShGOUp i6Z3fDrn8k0LhgMusabb5XiPBmJNx2fGajQ/TWqIMc5EYkK2Ujhmm+oO29OPLpJoGJhm 1Low==
X-Gm-Message-State: AOAM533k1nTNUjMuVYepFyyL1EA+bD5/SfISWJILp2b/IJPHbUVcWDJ5 eiy9gzR12+f4Rr4T7l0xR44Y9q5mNWg9KyelLbXt7MiN
X-Google-Smtp-Source: ABdhPJx41wnpWeRK7gAbPUELSfD4v9m6OLRdi4AXPmc1UHum+ZDFgnLOB8tv3AQlxu4RrfhHnErxfD1mobxBTEyGmcg=
X-Received: by 2002:a17:906:7316:b0:6d7:16be:b584 with SMTP id di22-20020a170906731600b006d716beb584mr37682166ejc.759.1648610957426; Tue, 29 Mar 2022 20:29:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Tue, 29 Mar 2022 20:29:06 -0700
Message-ID: <>
To: Mark Andrews <>
Cc: Peter Thomassen <>, Paul Hoffman <>, dnsop WG <>
Content-Type: multipart/alternative; boundary="0000000000007d835b05db67266c"
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: Wed, 30 Mar 2022 03:29:25 -0000

On Tue, Mar 29, 2022 at 1:31 PM Mark Andrews <> wrote:

> > 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.

You (Mark) are arguing that any experimentation would turn 253 in to a MUST
I think the other arguments (about having multiple algorithms allocated for
experimental usage) is more persuasive, including the nature of multiple
algorithms when experimentation is done.

This also keeps the 253 use case (actual private production use) distinct
from experimentation usage, thus preventing any negative interaction
between experiments and production zones.

(It's not about whether the behavior is correct, it's about whether there
is value added in selecting the 253 mechanism rather than reserving
experiment-only code points, IMHO.)

> > 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.

This presupposes that only 253 is used, rather than what Paul H has
proposed in his very small draft. It's a moot point and not contradictory
to the proposal, to not want or need to do the peeking bit (i.e. not
supporting 253).

> > 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.

>   You can’t
> reliably clean up experimental code points, especially if there are a lot
> of implementations.  DNS has a long tail.
> > 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.

Everyone else is saying, we don't want this to be the way of doing
experiments (with lots of good reasoning behind that).
The "once you implemented" is a conditional that is not mandatory to
implement. There is also guidance now that sub-typing is not a good idea
for anything new in DNS.

I'd suggest that your argument is in fact suggesting the use of sub-typing
for something new (experiments rather than just private use) in DNS.

> > 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.

I think it is sufficient to reword Paul's proposal, so that the 7 new code
points are labeled "experimental" rather than "private use".

A few words about expected behavior of implementers ("Don't release
production code with these code points in use", along with "ship production
code to explicitly disallow use of these code points".)

DNS hasn't previously had explicitly allocated experimental code points for
algorithms, so how those do and do not get used probably needs some minimal

I don't know if that belongs in this document, or as a separate document.
My instinct is "separate", and also that such a document doesn't need to be
a blocker on Paul H's document.

Maybe it is necessary to add some sort of explicit signaling about use of
experimental code points and that software involved in a particular
conversation (server or client) is in experimental mode.

The (potentially really bad) idea that occurred to me was, there's a
currently unused bit in the header, "Z", which is a vestigial remnant of
the larger Z field of "must be zero" from 103[345]. Perhaps that bit could
be re-labeled "X" (for experimental)?

Experimentation, including interoperability is a good thing. Leaving past
experiments' code assignments (from the experimental range) is a bad
practice, which should be self-limiting in nature.

As long as production software knows to ignore that range, and treat those
code points as "unknown", the only time a problem can occur is if a client
and server in production BOTH have made the error of shipping production
code that understood specific code points.

Unit tests and regression tests for this should be the first thing
implementers write, before they write a single line of code to implement
experimental functionality, IMNSHO.

Putting the correct sorts of "SHOULD NOT" and/or "MUST NOT" advice in the
short document is probably all that is required.

The shorter and simpler the doc, the easier it is to point implementers at
it and say, "fix your code".


P.S. If I haven't already said it yet, I support use of new code points for
experimentation.. They should be labeled "experimental" with guidance that
the experiments are themselves private in nature, and that no production
code should ever treat those code points as known or valid.