> On 30 Mar 2022, at 14:29, Brian Dickson <brian.peter.dick...@gmail.com> wrote:
>
>
>
> On Tue, Mar 29, 2022 at 1:31 PM Mark Andrews <ma...@isc.org> wrote:
>
>
> > On 30 Mar 2022, at 00:28, Peter Thomassen <pe...@desec.io> 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
> 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.
> > 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.
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.
> > 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".
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.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
