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.
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
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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
