Subject: [DNSOP] More private algorithms for DNSSEC

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Mar 2022 22:21:16 +0000

Greetings again. I have created a new, very short draft to add more private use algorithms to DNSSEC.
   https://datatracker.ietf.org/doc/draft-hoffman-more-private-algs/
The abstract says:
   RFC 4034 allocates one value in the IANA registry for DNSSEC
   algorithm numbers for private algorithms.  That may be too few for
   experimentation where multiple yet-to-be-assigned algorithms are
   used.  This document assigns seven more values for this use case.

That's about it. This is quite low priority for now, but might become more important as people start to experiment with multiple pre-standard post-quantum algorithms at the same time.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2022 03:43:31 -0400 (EDT)

> That's about it. This is quite low priority for now, but might become more important as people start to experiment with multiple pre-standard post-quantum algorithms at the same time.

I agree with the draft that this is a good idea and will become a
requirement in the near future.

I would like to see some more clarity in the IANA Considerations
section that just lists the value there and the values requested,
with a link to the actual Registry discussed.

Paul

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 21 Mar 2022 18:34:41 +0000

Hi Paul,

I think this is good.

Is it in response to the DNS-OARC talk we saw about implementing PQC Falcon in PowerDNS, and they used the next unused algorithm number rather than a private algorithm? If the authors of that work are on this list I would be interested to hear from them about that decision. In particular, would just having more private algorithms change their thinking or is something else needed?

DW

> On Mar 20, 2022, at 3:21 PM, Paul Hoffman <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://secure-web.cisco.com/1wTYBJPegvx-YY8FDLO4TQmd85aR-2DI2pH_1yIk3I-B-ciRbwVZA6lKWr8oR6DqFfDGQLetyrXiOoMYiaYP8Yq8Q4gcSU2Hc-8LodoRKdJJHe-HQVLmzoxZ5DA7ylHe7nq6YVxOdY7neqDUld-hghmdGrPdfphyHU-6A_hzotHSoBty51v7xZlLXMBELLIKZcFz2RHNnUuPZ8_PK4i1TyAjxPC0ToQwd56ffht4GgL8oeK95bNv7jZ43kpyp_yZj/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Mar 2022 19:32:03 +0000

On Mar 21, 2022, at 11:34 AM, Wessels, Duane <dwessels=[email-masked]> wrote:
> Is it in response to the DNS-OARC talk we saw about implementing PQC Falcon in PowerDNS, and they used the next unused algorithm number rather than a private algorithm?

Nils could have picked 253 but probably didn't even think of looking down to the bottom of the list. He was just following the time-honored pattern in the IETF. :-)

> If the authors of that work are on this list I would be interested to hear from them about that decision. In particular, would just having more private algorithms change their thinking or is something else needed?

They only needed one. This draft is for experimenters who need many at the same time. NIST has said that they are likely to later standardize on multiple post-quantum signature algorithms which will create larger payloads, and the DNSSEC community will have to decide if it wants just one of those, or many. Having a bit of experimental space for authoritative and recursive developers would be good, given that basically the entire range will be empty for centuries.

--Paul Hoffman

---

From: Nils Wisiol <[email-masked]>
Date: Tue, 22 Mar 2022 09:56:27 +0100

There was some internal discussion about using 17 vs 253, with the main
argument for 253 being that this is the intended use case for 253 and
the main argument for 17 being that worry that some resolver
implementations could have special treatment for private algorithm
numbers. As we are interested in how FALCON-512 would behave in the
existing DNSSEC infrastructure, I pushed for using 17. I have to admit
though that I did not do research whether there exists special
treatment for private algorithms.

To settle this, I would like to ask the resolver vendors on this list:
is your treatment of private DNSSEC algorithms (253) any different from
unknown algorithms (such as 17)?

In any event, we shall make our implementation flexible wrt to the used
algorithm number(s). The intent was explicitly not to make any claims
on unused numbers.

Best,
Nils

On Mon, 2022-03-21 at 19:32 +0000, Paul Hoffman wrote:
> On Mar 21, 2022, at 11:34 AM, Wessels, Duane <
> dwessels=[email-masked]> wrote:
> > Is it in response to the DNS-OARC talk we saw about implementing
> > PQC Falcon in PowerDNS, and they used the next unused algorithm
> > number rather than a private algorithm?
> 
> Nils could have picked 253 but probably didn't even think of looking
> down to the bottom of the list. He was just following the time-
> honored pattern in the IETF. :-)
> 
> > If the authors of that work are on this list I would be interested
> > to hear from them about that decision. In particular, would just
> > having more private algorithms change their thinking or is
> > something else needed?
> 
> They only needed one. This draft is for experimenters who need many
> at the same time. NIST has said that they are likely to later
> standardize on multiple post-quantum signature algorithms which will
> create larger payloads, and the DNSSEC community will have to decide
> if it wants just one of those, or many. Having a bit of experimental
> space for authoritative and recursive developers would be good, given
> that basically the entire range will be empty for centuries.
> 
> --Paul Hoffman
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Mar 2022 22:03:04 +1100

BIND currently treats 253 as unknown

> On 22 Mar 2022, at 19:56, Nils Wisiol <[email-masked]> wrote:
> 

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

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 23 Mar 2022 10:45:29 +0100

> Nils could have picked 253 but probably didn't even think of looking down to the bottom of the list. He was just following the time-honored pattern in the IETF. :-)

(I am not speaking for Nils, to be clear.)

253 is not for experiments - it is for private production. It requires
(as most of you might know) prefixing DNSKEY content with a private
algorithm specifier that looks like a domain name (or, for 254, with a
OID). This means if you were to use it for an experiment, your DNSKEY
content, and thus signer and validation code, would need to be changed
when you get a number assigned.

So, Paul, I support the idea behind your draft, but not the current
wording. While more 253-like points might be somewhat useful, what we
really need are experimental code points with non-253 semantics.

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

---

From: Petr Špaček <[email-masked]>
Date: Thu, 24 Mar 2022 11:27:57 +0100

> really need are experimental code points with non-253 semantics.
I agree. IMHO experiment codepoint which does not get any special 
treatment would be good enough.

-- 
Petr Špaček

---

From: Nils Wisiol <[email-masked]>
Date: Thu, 24 Mar 2022 12:25:54 +0100

> treatment would be good enough.

Agreed.

It's important for researchers to be able to argue that using those to-
be-assigned code points will produce the same results as using the free
code points that would likely be assigned when whatever is tested
becomes a standard. If this is cannot be argued with certainty, valid
predictions of future behavior could only be produced by using the free
code points instead.

Best,
Nils

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 24 Mar 2022 12:49:04 +0100

On 22/03/2022 09.56, Nils Wisiol wrote:
> numbers.

17 seems a little risky in the sense that it might get officially 
allocated in the next couple of years, even if you don't care about 
colliding with other experiments.

Knot Resolver does not have any special-casing here, I believe. Anything 
above 16 should always be unsupported algorithm, so downgraded to 
insecure (if no other supported combination is in the DS set).

--Vladimir | knot-resolver.cz

---

From: Mark Andrews <[email-masked]>
Date: Mon, 28 Mar 2022 12:23:10 +1100

> On 23 Mar 2022, at 20:45, Peter van Dijk <[email-masked]> wrote:
> 

Please quote where it is stated that “private is not for experimentation”.

Private is private.  Do what you want with it as long as you identify the
the algorithm uniquely and that includes experimental implementations.

Also while it is nice to be able to just change a number to go from
experimental to production, in reality removing code that add / checks
the algorithm name at the same time is not a lot to ask vendors to do and
is unlikely to cause real problems. If you want you can actually keep the
name DNSKEY and DS records as a constant if you are too scared that vendors
will muck up the minor change of removing an identifying name.

There is zero reason to reserve any ADDITIONAL space for experimentation.

Domain names are cheap as are OIDs.

I do not support reserving more space.

Mark

---

From: Nils Wisiol <[email-masked]>
Date: Mon, 28 Mar 2022 10:50:01 +0200

> the algorithm uniquely and that includes experimental

Hi Mark,

my understanding of 'private' is that I cannot have any expectations on
how the resolver will treat it. Hence, when experimenting with new
DNSSEC algorithms, 'private' is not the behavior I am interested in.
Instead, I am interested how the resolver would treat my new algorithm
if it was assigned a (regular, non-private) code point.

Arguing that resolvers would behave the same on unknown code points and
private code points is difficult, as a large portion of users use
closed-source implementations. You said yourself that BIND "currently"
treats 253 as unknown; so different behavior is conceivable? This
uncertainty can be partially addressed by reserving some code points
for "unknown algorithms" behavior (rather than the semantics of 253).

While this will not solve all concerns with such studies, I'm not aware
of significant downsides to reserving more code points. (Other than
running out of numbers, do you have any other concern?)

Alternatively, people can just used unassigned numbers. I did that
recently, and my impression was that people read that as me trying to
create facts for a future official number assignment -- an impression
that I did not intend to make and would like to avoid in the future.

Best,
Nils

---

From: Mark Andrews <[email-masked]>
Date: Mon, 28 Mar 2022 22:00:27 +1100

Bind treats it as unknown as there are no private types yet. If one decides to add support for a private type then you add the code to check the identifier of the private type and differentiate that from other private types. 

This behaviour is specified but not yet implemented. 

The same applies to OIDs. 

-- 
Mark Andrews

> On 28 Mar 2022, at 19:49, Nils Wisiol <[email-masked]> wrote:
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Mar 2022 14:34:10 +0000

> There is zero reason to reserve any ADDITIONAL space for experimentation.

Assume that you want to experiment with creating responses that have multiple as-yet-undefined algorithms. How would you do that today? Differentiating in the RRdata, as is done today, would create a single RRset in the response.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Mar 2022 05:34:15 +1100

> On 29 Mar 2022, at 01:34, Paul Hoffman <[email-masked]> wrote:
> 

You would add records of type 253 with “alg1.example.org” as the first algorithm name, “alg2.example.org” as the second algorithm name where example.org is a domain you control. If someone else is running another experiment they add 253 with the algorithm name specified as “alg1.example.net” where example.net is a domain they control.

When you are checking if you support a particular instance of PRIVATEDNS you check the algorithm name as well as the algorithm number (253).

For working out if the DS record indicates support for your PRIVATEDNS algorithm you need to find the matching DNSKEY based on the hash and extract the PRIVATEDNS algorithm name.  If you can’t find a matching DNSKEY the DNSKEY RRset is bogus as the DS record says that the DNSKEY record exists.

If you want to see how this would work add “PRIVATE-RSASHA256” using RSASHA256.ICANN.ORG as the first algorithm name and “PRIVATE-ECDSAP256SHA256” with ECDSAP256SHA256.ICANN.ORG as the second name as a starting point where they are reimplementations of RSASHA256 and ECDSAP256SHA256 respectively.  Throw in “UNKNOWN.ICANN.ORG” with some random data as the rest of the key.

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.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Mar 2022 08:08:03 +1100

Note you can’t prepublish a DS to roll keys  you need to publish the DNSKEY first. 

-- 
Mark Andrews

> On 29 Mar 2022, at 05:33, Mark Andrews <[email-masked]> wrote:
> 
> 
>

---

From: Peter Thomassen <[email-masked]>
Date: Tue, 29 Mar 2022 15:28:15 +0200

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

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.

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.

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.

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

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.

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.

Best,
Peter

-- 
https://desec.io/

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Mar 2022 07:30:52 +1100

> On 30 Mar 2022, at 00:28, Peter Thomassen <[email-masked]> wrote:
> 
> 
> 

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, t…

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 algori…

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 conf…

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.

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Mar 2022 08:45:31 +1100

To fix this we need to extend DS to say that for any newly allocated digest types that they must include
the matching DNS name for algorithm 253 and the match IOD for algorithm 254 before actual digest in the digest
field.  Then allocate PRIVATE SHA256, PRIVATE SHA-384 and PRIVATE GOST R 34.11-94 which are replacements for
SHA256, SHA-384 and GOST R 34.11-94 respectively that support pre-publishing DS for PRIVATEDNS and PRIVATEOID.

> On 29 Mar 2022, at 08:08, Mark Andrews <[email-masked]> wrote:
>

---

From: Brian Dickson <[email-masked]>
Date: Tue, 29 Mar 2022 20:29:06 -0700

On Tue, Mar 29, 2022 at 1:31 PM Mark Andrews <[email-masked]> 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.
> >
> > 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.
>

You (Mark) are arguing that any experimentation would turn 253 in to a MUST
IMPLEMENT.
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.
>

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

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

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

Brian

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.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Mar 2022 15:23:20 +1100

> On 30 Mar 2022, at 14:29, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> You (Mark) are arguing that any experimentation would turn 253 in to a MUST IMPLEMENT.

No, its experimenters need to implement.  Everyone else doesn’t have to touch any code.

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

Where did private (not needed to be documented) morph into not for use in experimentation?  We documented how to
avoid negative interactions by specifying that you MUST use a DNS namespace you control or use a OID which you have
been allocated (which are free from IANA).  There are no restrictions about publishing PRIVATEDNS or PRIVATEOID keys
to the world.  Anyone one can publish them at anytime anywhere in the DNS tree.

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

We only have a restricted number of code points that don’t require the use of an OID or a DNS name and once they have
been used for an algorithm they are burned for use with any other algorithm.

> 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).
>  
> So rather than that you want to have to deal with potential colliding use of code points without identifiers.  
>  
>   You can’t
> 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.

Bumpkin. If I’d thought that PRIVATEDNS or PRIVATEOID couldn’t be used for experimentation I would have argued for
reservations myself 20+ years ago.  Below are the ONLY restrictions applied to PRIVATEDNS or PRIVATEOID.  Please
highlight where it says “not for experimental use” or “can only be used for production” or “never to be published
to the world”.  None of those restrictions are there.  They are figments of your imagination.

A.1.1.  Private Algorithm Types

   Algorithm number 253 is reserved for private use and will never be
   assigned to a specific algorithm.  The public key area in the DNSKEY
   RR and the signature area in the RRSIG RR begin with a wire encoded
   domain name, which MUST NOT be compressed.  The domain name indicates
   the private algorithm to use, and the remainder of the public key
   area is determined by that algorithm.  Entities should only use
   domain names they control to designate their private algorithms.

   Algorithm number 254 is reserved for private use and will never be
   assigned to a specific algorithm.  The public key area in the DNSKEY
   RR and the signature area in the RRSIG RR begin with an unsigned
   length byte followed by a BER encoded Object Identifier (ISO OID) of
   that length.  The OID indicates the private algorithm in use, and the
   remainder of the area is whatever is required by that algorithm.
   Entities should only use OIDs they control to designate their private
   algorithms.

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

Private use includes experimental 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".)

Does not work in practice.

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

253 + unknown name is “unknown” if you implement PRIVATEDNS.  Similarly 254 + unknown OID is “unknown" if you implement
PRIVATEOID.  If you don’t implement PRIVATEDNS or PRIVATEOID then 253 and 254 alone indicate unknown.

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