On Thu, 30 Jul 2020, Joe Abley wrote:
This proposal is meant to increase the amount of trust people can place in
DNSSEC by decreasing the hard trust that is currently required of ICANN,
Verisign and the TLD operators. I understand in our community, we do
not see this as a big problem. Unfortunately outside our community it is.
Can you provide some information about that? I think it would be helpful to
understand the problem that people are bothered by.
The amount of times people quote Thomas Ptacek's article on this issue
is really high.
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
It doesn't matter how much we debunk it and say this is an enigma
problem, or that ICANN or rootservers can be trusted and it is
just a conspiracy theory.
We can eliminate this entire discussion by setting 1 bit. It's easy and
cheap to do. And it signals good intensions by TLDs and ICANN/Root for
transparency in general. And might even prevent some governments from
cooercing TLDs because well, they won't be able to anymore.
It is further interesting that you raise your point of "the risk analysis
shows we can never afford to deploy this" when a few months ago you
raised the reverse point that "we dont want to be forced to have to use
this to be seen trustworthy". Both arguments cannot be true.
Well, I didn't say that we can never afford to deploy anything. Clearly we can
deploy lots of things all the time. I think I've explained why we couldn't just
turn this on in ORG right now, and so a requirement to do so would be a problem.
This is quote the more nuanced phrasing you use now. Now you are saying
that yes, with some changes to your infrastructure, you can support
this. Where as before you said "we can never ever support this". I
think that is good to have clarified.
The lines of code to be added to particular implementations are not the only
measure of complexity in deployment, however. We don't have a good handle on
all the software that exists between application and authority server, nor how
it interacts. There are costs in resolution failures that appear intermittent
because they happen with some applications, networks or hosts but not others,
assuming that it is deployed anywhere.
I don't understand this. Let's say example.org has:
example.org. IN NS ns1.deleted-domain.org.
ns1.deleted-domain.org. IN A a.b.c.d
Currently, .org would serve the 'glue' A record that it would sign. with the
.org ZSK.
You create a new zone, broken-nameservers.org, and you change the above to:
example.org IN NS ns1.deleted-domain.org.broken-nameservers.org.
ns1.deleted-domain.org.broken-nameservers.org. IN A a.b.c.d
You run and sign broken-nameservers.org. without the DELEGATION_ONLY flag.
The existing broken glue keeps working. And you even gain a new
indicator and could inform people on www.broken-nameservers.org that
their domain is in purgatory and they better start fixing it.
And now you can run your .org as DELEGATION_ONLY zone.
If the technical difficulties for particular registries like ORG can be
circumvented but the benefits are not obviously compelling, then there's the
question of why any commercial registry would implement this proposal. If it
needs to happen as a contractual obligation, then that means contract changes
and although that's very much not my area, my sense is that that's a fairly
heavy ball that needs to be rolled up a steep and tall hill. That sounds like a
cost to me.
Without widespread implementation, I'm not sure how the problems (admittedly,
problems that I don't really understand) will actually be addressed. The costs
will remain, however. And right now I haven't heard a single example of a TLD
that might be in a position to implement this (not saying there isn't one, just
that I haven't heard an example).
I think this argument is the same as for IPv6, DNSSEC, and many other
new protocols. It's like saying there is no reason to add signaling to
wifi hotspots because no one will implement it because they have some
interception method that works now. Still, we are trying to improve the
protocols there too so we can at some point in the future enhance and
improve those protocols. Maybe for .org that will only be after the
market pressure that you explained you feared earlier in this
discussion. To me, that would be a success of IETF increasing the
trust in DNSSEC - even if we ourselves believe root servers or TLD
servers would never be coerced into a position of provding maliciously
signed data to third parties.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
