On Thu, 30 Jul 2020, Joe Abley wrote:
My sense is that this is a nice idea in theory but doesn't solve a problem that anybody actually has, and the camel is starting to look a little bit fraught. But I don't think any proposal should succeed or fail based on anybody's uninformed sense, hence the request for more data.
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. 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. As for the DNS camel, we are talking about 1 bit and many 20 lines of code in the resolver. Looking at the rest of the current drafts in DNSOP, I think this isn't going to break the camel's back. As for your single issue, the glue issue, you could also change your take down system. You could bring up a take-downXXX.org. zone and update the NS glue for the GOODDOMAINS.org to use that, give out the original IP and sign it with take-downXXX.org's key. It would even work with resolvers that insist on hardening and confirming glue, so you would actually improve your .org deployment independently of this draft. What I'm trying to avoid is adding complexity to support this already unstable "run on glue" domains. Sure, we could add an exception for A/AAAA since these records are of low value to protect because onpath attacks can just NAT/route it to them anyway, but doing so would actually increase the complexity of the code and muddle the expectation of the protetion of "delegation only" zone. Paul _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
