On Thu, 12 Aug 2021, Joe Abley wrote:
This would have been excellent to do when we did DS. It would still be
good to do this now, I agree. But it would be too late for some of the
things discussed now.
Can you talk more about why you think so?
I did a small presentation during IETF 111 DPRIVE. You can find the
presentation deck and the recording on the IETF site.
Support for novel interpretations of particular DS algorithms will require
support on both the provisioning and consumer side. Is it really that much more
work to specify new DS-like RRTypes?
It does not neccessarilly require support on the provisioning side, as
it is "just another DS record" from the provisioning point of view
unless lawyers insisted the TLD somehow verifies the pubkey is
pre-published or in an algorithm they 'support' (allow).
There's truck-roll in both cases. Neither path is really going to make these
features generally available any time soon.
There is a huge difference between "support for a DS record with
unknown or unexpected content at the RRR level" and "change all
DNS and EPP software on the planet". The first one has like 1500
actors. The second has millions or billions.
And as I argued, even if we do this by overloading DS or NS, is that
overloading really something we need? As it is only required for
privacy to nameservers that are in-bailiwick to the domain, which in
itself is already pretty much a dead give away even when you only
can observe encrypted TLS traffic to an IP address of a well known
published nameserver.
So my own order of preference is likely something like:
1) Forget about protecting in-bailiwick nameservers
2) Do it securely using DS at parent
(only requires new code for validating nameservers that don't exist yet)
3) Do it insecurely using NS at parent
(only requires new code for validating nameservers that don't exist yet)
4) Wait for SVCB at parent near universal deployment
(requires widepsread recursive and authoritative updates, EPP updates,
webgui updates)
5) do 3) until 4)
(I can't even)
I guess somewhere between 2) and 5) would be "another out of band hack"
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
