On Sun, 30 Jul 2017, Evan Hunt wrote:
It's clearly helpful for human debugging.
But, yes, you're correct -- diagnostic information included with a
SERVFAIL is about as trustworthy as the AD bit, and in the absence of an
authentication mechanism such as TSIG, clients should not rely on it or
base policy on it.
But we know people are already building software and systems that DO
trust the AD bit, even with non-localhost resolv.conf entries. This
saves them the overhead of adding a dnssec library to their application,
and saves them from running a system resolving understanding dnssec.
So I'm pretty worried that people will treat new unprotected error
codes exactly the same. They'll handwave and say that's the system
administrator's issue to solve, not the application's responsibility.
Some of the error codes might be trustworthy enough if you're using COOKIE
or TCP; that would enusre at least that it wasn't an off-path forgery.
That's a very small use case with pervasive monitoring and
coffeeshop and hotel wifi.
This should be spelled out in more detail in the security considerations.
I'm seriously afraid that's not going to matter at all when people
implement this.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
