On Mon, 1 Mar 2021, Eric Rescorla wrote:
Rephrased: TLSA might work, but given that SVCB is designed for this purpose,
my prior is to favor it.
Thanks, that clarified it for me.
> +1. I used TLSA because PaulW had proposed it and no one objected to
the proposal, but a new purpose-built
signal seems fine.
Note that I did not object to TLSA. I prefer it over SVCB. I don't think
it is realistiv for any new kind of glue record to be invented and that
seemed to have been the reason in the proposal to use SVCB? To serve
it at the parent side of the zone cut?
I do think serving this at the parent side of the zone cut is a good idea,
but that's not the reason for SVCB.
You would need to write an RFC for the EPP extension. You would need to wait
for most TLD's EPP systems to support this new record. Then you need to
wait for Registrars to update their EPP software. Then you need to wait
for Resellers like OpenSRS to update their software to resellers.
Then you need to write an RFC on adding SVCB records to a parent zone so
that current DNS software doesn't immediately reject it as out-of-zone
data. Then you need to push opensource implementors. Then you need to
push TLDs to deploy, and the big DNS appliance vendors. Then you have to
wait for old DNS products to be updated or replaced at the enterprise.
That's a 5-10 year time line. You would need an interim solution. If you
have such a solution, there is even less incentive to get this work done.
As has been discussed extensively, the general feeling among people who work
with
the WebPKI is that pinning has turned out to be a bad idea. For this reason,
it's
important to be able to have an available way to say "just use the WebPKI", even
if it's also possible to be more specific.
DNS is not the web. DNSSEC already "pins" via the DS record in a
hierarchical way with DNSKEYs. Adding another public key here is
not that different.
Reducing the hierarchical security of DNS (with or without DNSSEC) by
replacing it with what is defacto the LetsEncrypt Root CA seems a bad
idea. If you plan to use this new sentinel without any kind of public
key, then this proposal is yet another workaround to hack WwebPKI into
somewhere where it doesn't belong or fit, and I must object.
I don't know what (cc)TLD operator's opinions and rules are on having
their nameserver public key verification operation subjected to a single
California non-profit organization. And all the anti-DNSSEC people who
objected to a single root key would have a similar problem here as well.
So I guess we might be looking at two different standards then. One that
uses the advantage of the DNS hierarchy with DNSSEC based on TLSA, and
one that flattens the DNS hierarchy using an SVCB for WebPKI.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
