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

[Mark Andrews <[e-mail]>]

> On 30 Mar 2022, at 00:28, Peter Thomassen <[e-mail]> 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
> 
> -- 
> https://desec.io/

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]